***This proposal's final 2 milestones are being repurposed for Feather wallet***

What

32 hours a week for 3 months. My last proposal was the first where I was able to dedicate fulltime attention to Monero. Thus, past 3 months has seen substantial improvements to the GUI. For example, all points from this issue have been resolved or at least improved upon.

Who

I'm dsc, familiar with Monero GUI internals and contributed to the GUI codebase since fall 2017.

My contributions/experience:

https://github.com/monero-project/monero-gui/commits?author=xmrdsc

https://github.com/xmrdsc/py-levin/commits?author=xmrdsc (autonode.xmr.pm)

https://github.com/wownero/wownero-funding-system/commits?author=xmrdsc

https://github.com/wownero/Wownero-Light-Wallet/commits?author=xmrdsc

https://github.com/monero-ecosystem/qml-xmr/commits?author=xmrdsc

https://github.com/monero-ecosystem/moneriote-python/commits?author=xmrdsc (moneroworld)

Free VPS Hosting for XMR i2p workgroup, Noncense Research Lab and a Gitea backup git instance.

The fan-favourite & glorious IRC bot xmr-pr - making everyones life more managable

Report on the previous 3 months

In addition I 'cleaned up' QML components and reviewed/rewrote existing QML/js logic. Good QML components lead to a more stable/clean UX. This is time consuming, as QML is not intuitive or easy to work with (compared to, say, HTML + CSS). These efforts are a balance between "needing to clean up the codebase before we can continue" versus "delivering tangible results the community benefits from".

Proposal

32 hours per week at 50 USD/hour rate for a total of 282 XMR. XMR/USD rate is roughly based on the average of the past 2 weeks.

I'd rather not post bi-weekly updates in this PR/Reddit, rather wish to have a weekly meeting on Tuesday in #monero-gui on Freenode. This will be an opportunity where the GUI workgroup discusses recent developments, open issues/PRs, and to-do's.

What I want to focus on

Or rather, what I could choose to focus on. Following list is unordered in terms of prioritization.

Tor/i2p integration

Due to knaccc/jgrassie's efforts (et al.), Monero now has support for tor/i2p. GUI should implement this. Challenges ahead:

Come up with a design that works in terms of UX How to present tor/i2p options to the user? Where can the user switch between connection types? tiny-i2p/tor binaries will not be included in the GUI release, how to deal with this?

Android/Purism

Purism has shown interest in having Monero GUI natively and included by default on their Librem 5 (phone). This idea has overlap with a long standing wish of having an Android GUI release, as both would require a new QML application.

Time estimates for both Android/librem support would most likely result in at least 50% of this CCS's time allocation. As such, I'm not commiting to this task before the community prioritizes this goal and/or someone wants to partially fund this mobile adventure :-o)

Support database pruning

More info here.

GUI has functionality to check if a newer version of the GUI is available, via DNS. I believe this was disabled some time ago. We should get this functionality working.

Current GUI popups can be improved. Kneuffeulbund made new designs I'd like to implement.

Monerod as a service on Linux/MacOS

The ability to register/create a monerod service from within the GUI, and add it to system startup using systemd (linux), LaunchAgent (MacOS) + system tray. For Windows, such registration should take place in rbrunner's installer. I will not work on a Windows service.

This should also support Automatic mining.

User testing session GUI feedback

Take user feedback from an IRL GUI testing session and implement them.

Integrate the Monero GUI guide

Integrate the Monero GUI guide from the translations workgroup inside the GUI, using a markdown to HTML renderer, inside QML, using QtWebView.

Tooltips, context menus

Right-click->copy/paste would be nice to have for input boxes. Also help tooltips.

moneroseed://

Support for moneroseed:// URIs. More info here.

CMake build recipe

A CMake recipe, replacing qmake, will be a requirement to create reproducible builds. Currently I'm experimenting with one, it may be finished soon. Might also not be. Would like to work with TheCharlatan on this.

Misc. GUI development

Manage issue tracker

Bugfixes

Improving QML components where fit

Code review PRs