On Monday, 3 April 2017 06:56:39 UTC+1, Jean-Philippe Ouellet wrote: > > First, note that we prefer plain-text emails over HTML on the mailing > lists. > > My apologies.
> On Sun, Apr 2, 2017 at 10:23 PM, John Casey <[email protected] > <javascript:>> 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. > > I must have misinterpreted this. Thanks! > > 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/ > <https://www.google.com/url?q=https%3A%2F%2Fglade.gnome.org%2F&sa=D&sntz=1&usg=AFQjCNErRBIuee37WgcIwxLhsqBS6Bs-fQ> > > Sorry, by wire-frames I meant the screenshots he had added to #1870. Wrong terminology on my part. I had intended to say that they could be used as a frame to build on. > > > 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/ > <https://www.google.com/url?q=https%3A%2F%2Fqubes-core-admin.readthedocs.io%2Fen%2Flatest%2F&sa=D&sntz=1&usg=AFQjCNGfGlOCV_qmhYmarScUdZdkvE_Bhg> > > > Thanks, that's a very in depth read. > 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 > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FQubesOS%2Fqubes-issues%2Fissues%2F2132%23issuecomment-255106656&sa=D&sntz=1&usg=AFQjCNE_i0O8MDwfcGNXr7dl5KiTLh8TiQ> > > [4]: https://github.com/kalkin/manager-new > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fkalkin%2Fmanager-new&sa=D&sntz=1&usg=AFQjCNF1GSld7VHPXE-xhlAo42omlKBq7Q> Thanks. Makes sense that if this has moved to GTK, I should also use GTK. > > > > 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). > Understood. I'm going the move things around to be able to dive in much more quickly. I should have this done by now, but as I'm sure you guys know, real life happens sometimes and some things need to take priority. I will make up for this before coding begins. > > > 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. > Naturally, I just believe that once I have become comfortable contributing, I see no reason that I wouldn't continue after GSOC. > > > 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! ;) > https://xkcd.com/323/ > > > 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 > > Understood. I'll fix this. > > 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. Absolutely, I've already installed it on my laptop, but will be switching my desktop to Qubes alongside Windows. > > > 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. > I had no particular fondness for my laptop (soft) system, but require GPU pass though on my Windows box, which I suspect will be a more complex installation. I'm currently considering installing Qubes under unRaid. Security issues aside, as this will not have access to sensitive data, is this feasible or a pipedream? I know that Qubes does not play well with Type 2 hypervisors, but would be interested in your opinion. > > > 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. > Moved. > > > 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. > By this, I simply meant the API that the QM would be using. In hindsight, that phrasing is bizarre. > > 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. > While I agree with you, I'm under the impression that I need to read anything I can to familiarise myself with the design choices made for the previous QM, so as to improve my implementation of the new. > > > 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. > Understood and moved. > > > 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. > Cool, sorry for misinterpreting. > > > 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. > Perhaps I over emphasized the time required for this particular step. I had intended to build a list of what actions belonged to the persistent config of the QM, rather than the ephemeral state. If this has already been completed I haven't come across it. The comments under #1870 seem to cover a lot of it, but seem focused on features to be added. Additionally, #2132 seems more focused on what should fall under kalkin's widget. (Is widget the correct term? Perhaps toolbar item.) Perhaps this is more blatant than I realise, and it can be completed in an afternoon. But I feel that it is important to have a concrete list of items before starting. > > > 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. > Done. > > > 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 > Previous to your feedback, I felt that this would be a functional implementation of bnvk's work that emcompasses current functionality of the QM. However, I now realise how far along bnvk is with the GTK implementation. Thus I intend to modify this step accordingly. Perhaps instead this should be > > > 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/ > Deserved. > > 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. > Given that I overestimated the previous step. I believe I should be able allocate more time to this step. I have no doubt overlooked simplified edge cases and unplanned tasks. As a result, I will have to begin attempting to find these earlier in the summer to be prepared to implement them at this point. Does that make sense? --- Many thanks for your input, it is extremely appreciated. -- 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/2c5031aa-9c1d-4c31-a708-02820df3df96%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
