First, note that we prefer plain-text emails over HTML on the mailing lists.
On Sun, Apr 2, 2017 at 10:23 PM, John Casey <[email protected]> wrote: > The Qubes development team have decided that the Qubes Manager is in need of > a radical overhaul (#1870 [1], #2132 [2]). Specifically they intend to split > the QM into two separate interfaces. One which displays current information > about the system and allows control of same: currently running VMs, resource > usage, starting and stopping VMs, etc. The second is concerned with the > persistent attributes of the system. This covers creation and management of > AppVMs, as well as Qube specific actions. > > > It is the latter of these that is the focus of my proposal. Discussing this > with Marek and Jean on the mailing list has revealed to me that the Qubes > team have not completely settled on a graphical framework for this project. > As a result, further discussion will be required to determine whether to > proceed with the Qt framework or to port the project to GTK. However, I feel > the technology used is relatively independent of the design of the manager > itself, and so I proceed. It's resolved. GTK is preferred. > The development of this can be broken up into three distinct phases. > > > Analysis of the existing wireframes written by bnvk [3] > > If necessary, port this code to GTK. He did not create wireframes, he designed the GUI in Glade [1] whose whole purpose is to already plug in easily with GTK. [1]: https://glade.gnome.org/ > Expand upon this codebase, so as to deliver a QM manager that allows users > access to persistent configurations as in the current manager. This will require using the new "core3" API [2], which is still a moving target and ongoing area of work. Woju (CC'd) and Marmarek can give you a better idea of the state of this code. It's possible that the API has not stabilized and is not ready to be used yet. I have not personally been following this work very closely. [2]: https://qubes-core-admin.readthedocs.io/en/latest/ In addition to bvnk's work which I see you've already found, there is also Kalkin's work on the "domain state" component of the split manager. Screenshots here [3], code here [4]. This is also already in GTK. [3]: https://github.com/QubesOS/qubes-issues/issues/2132#issuecomment-255106656 [4]: https://github.com/kalkin/manager-new > Particular attention will be paid > to ensure that existing functionality is not lost, such as accessibility for > keyboard-only power users. +1 :) > Once complete, I will bring a list of suggested features and enhancements to > the development team, and perhaps to the community at large if this is > deemed appropriate by my mentor. We can then discuss which of these features > are suitable for me to undertake. Ideally this would already have been done and included in your proposal, but... it is what it is. IMO you should have a clear idea of what to do and how to do it by the start of the coding period (May 30th). > 3 Road Map > > Qubes will be my focus this summer, with continued contributions afterwards. Note that for the purposes of evaluating your proposal, we are only allowed to consider things being promised during the summer. Planned future contributions are of course encouraged, but do not increase the chances of your proposal being accepted. > Because it is the Summer of Code I do intend to take a couple weekends > hiking and camping in the mountains local to me, but I do not anticipate > that this will conflict with my Qubes schedule. Time for design reflection! ;) > Below I have detailed a possible plan for delivering on the promises I have > made above: > > Timeline Compare yours to the actual GSoC timeline. [5] I think you are beginning things too late. You should be reading documentation and bootstrapping your familiarity with our workflows for contributing code as soon as possible. Keep in mind that June 26th is the first evaluation deadline, at which point you are expected to have made reasonable progress towards the stated goals of your actual proposal, not only (allegedly) read docs. The general GSoC expectation is that the familiarizing happens before the coding period begins, and during the coding period you really write code. [5]: https://developers.google.com/open-source/gsoc/timeline > 3.0 - Installation and Familiarisation with Qubes, Setup qubes-builder > > April 3rd - May 30th > > As I am not currently intimately familiar with Qubes, I will reinstall it > and transition to it as my day-to-day OS. Ideally I will build the OS from > source, but I believe using Qubes will be the most effective resource when > designing UX improvements. Yes. Experiencing the Qubes UX yourself is a hard requirement for working on it :) I'd strongly recommend not taking a month just to install Qubes if you can avoid it. The best way to learn is to just jump right in and force yourself to use it for everything you do. I think you'll find the qubes-users mailing list a welcoming and helpful place if you run into any issues in doing so. I'd say switch entirely to Qubes ASAP. One trick I've used for several friends to ease the migration is to throw your existing system into an HVM so you can continue to use it as-is while getting used to the Qubes way of doing things. This requires you have another (larger) disk on hand though which you can swap with your existing one. Not sure if this would help in your case, but it's worth a thought. > 3.1 - Reading Documentation, Identifying Skills, Trivial Contribution > > May 30th - June 6th > > Qubes has a plethora of user and developer feedback, and future plans. My > first step to contributing to Qubes will be to immerse myself in this > documentation. IMO you should be doing this as soon as possible. Perhaps this should be your first timeline section. Definitely don't wait until May 30th (when Google wants you to be writing code) to begin reading docs! Also, do not expect this to only take a week! Reading docs is very much an ongoing process. > A beautiful interface is useless if it is ineffective. Understanding and > using the various system calls and configurations used by the QM will be > crucial to improving it. No system calls here! Well... there are of course, but not that you need be concerned with. Not quite sure what you mean by configurations either. Anyway, I'm not sure you need to be too concerned with the implementation details of the existing qubes-manager. Much is changing, and for good reason. Much of the current internals (PyQt, old-core-API) are not at all applicable to the intended future version. > In order to ensure that my environment is setup correctly and that I am > adhering to existing style practices I should submit a trivial contribution > to Qubes. An example of this would be the revising of the “DispVM” name > across Qubes as documented in #2671 [4]. Definitely don't wait until May/June to do this. > 3.2 - Learning GTK/Qt, Contribute a Bug Fix to Qubes, Compile Report on QM > Requirements > > June 6th - 20th > > At this point, with guidance from Jean and Marek, the GTK/Qt decision will > have been made Already been made. It's GTK. I was the only person considering otherwise, and Joanna convinced me that GTK is the way to go. > and I will have begun implementing trivial UI components in > Qubes. Using this knowledge, I will be able to contribute to one or more of > the issues that have been pain points for users (e.g #1117) [5]. > > > Next, I will analyse the current QM and report on what parts belong in the > new QM, and what should instead be included with the “current state” display > widget. These findings will be taken to the team for feedback and will form > the basis for the design of the new QM. It is my understanding that this has for the most part already been done. > 3.3 - Expand on QM Design by bnvk, Draft Design, Discuss with Development > Team and Amend Proposal. > > June 20th - 27th > > Based on this report, I will draft UI mockups and design the specific tabs > and menus of the new interface. This can be taken to the team for feature > suggestions and improvements. > > > I will compile a memo on my planned approach to the development of a new QM > and discuss this with my mentor. As I receive feedback, the planned approach > will be amended and improved. IMO you have way too much planning and proposing (which duplicates the planning and proposing which has already been done by others) and not enough implementing. I'd suggest moving all this earlier and getting started much sooner. > 3.4 - Implement Proposed QM Core Functionality > > June 27th - July 11th > > Taking the memo and groundwork laid by bnvk, I will begin creating the new > QM interface and porting features. Deliverables will take the form of a > commit of a basic interface for the new QM, with the basic functionality > implemented. Can you elaborate on how this is different from the current state of [6]? [6]: https://github.com/bnvk/qubes-manager-new > 3.5 - Complete Core QM > > July 11th - 25th > > Complete the QM, including all features related to the persistent attributes > of the system. Deliverable will take the form of a commit that can be > installed and tested by the community at large. https://www.reddit.com/r/restofthefuckingowl/ I guarantee this will take longer than you expect. This is the whole essence of the project and will have many sub-tasks and unforeseen surprises (perhaps such as "hmm... it seems we actually need X in the core management API to implement this") which could each set you back a week on their own. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CABQWM_DnG89_NXCPogrgkGCOpwzdV5A16rzib-7bkXxk9NUv8g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
