Accéder au contenu principal

Extracting Boxes' wizard's pages

A few days ago, Zeeshan suggested me to extract Boxes' wizard's pages out of the Wizard class and to make them full fledged widgets/classes. This idea is very welcome as it would move a lot of complexity out of the Wizard class (as it is currently implementing most of the pages) and, in the long run, make its port to GtkAssistant easier.

I spent the last few days playing with the pages, discovering how they are implemented and extracting some of them.

Boxes' wizard's page graph
Extracting pages, kind of

The current state of Boxes' installation wizard

Here is the wizard's page flow as presented to the user:

Boxes' wizard's page graph
The current page flow

The wizard is currently implemented with such a widget hierarchy:

  • the WizardWindow class
    • the WizardToolbar class
    • the Wizard class, a stack of pages
      • the WizardSource class
        • the source selection page
        • the URL entry page
      • the preparation page
      • the setup page
      • the review page
    • the file chooser page
    • the customization page

The wizard has three layers of pages, most of them behaving slightly differently: the WizardSource class is composed of the source selection page and of the URL entry page; the preparation, setup and review pages are directly implemented by the Wizard class; and the file chooser and customization pages are implemented by the WizardWindow class. Also, the URL entry page have its own back button and doesn't use the common one in the headerbar to go back to the source selection page, which is inconsistent with every other page's behaviour.

Most pages are directly implemented by the Wizard class, making of it a mishmash of intertwined behaviours and responsibilities, especially as every page is directly modifying the wizard's state. Some other are handled by the WizardWindow and WizardSource classes, but in the end, no page exist as a single class. All of this lead to a great complexity which should be corrected in order to make the wizard more maintainable and to port it to GtkAssistant.

Where to go

I want to keep the page flow the same while changing the implementation drastically: the Wizard should inherit GtkAssistant, each page should be a widget with its own class and no page should be nested. Here is what I want to achieve:

  • Wizard
    • WizardSourceSelectionPage
    • WizardFileChooserPage
    • WizardUrlEntryPage
    • WizardPreparationPage
    • WizardSetupPage
    • WizardCustomizationPage
    • WizardReviewPage

This refactoring has to be done properly: what's the point of moving from known code to something not inherently better and known only by the person who wrote it?

In order to untangle the pages from the wizard without changing their code too much, I want to use more event-driven programming so that the pages don't change the wizard's state directly but notify it of changes, letting it react accordingly. It will help to uncouple the wizard's behaviour from the implementations of the pages, hence making its code simpler and its porting to GtkAssistant easier.

Going there

What have been done:

  • spliting the model of the WizardSource class from the widget: patch submitted
  • renaming WizardSource as WizardSourcePage to keep the page names consistent
  • extracting the preparation page from the Wizard class: patch submitted
  • extracting the setup page from the Wizard class: patch submitted
  • extracting the review page from the Wizard class: patch submitted

What has to be done:

  • editing the Wizard class' API to mimick GtkAssistant's one: in progress
  • extracting the source selection page from the WizardSourcePage class
  • extracting the URL entry page from the WizardSourcePage class
  • removing the WizardSourcePage class
  • extracting the file chooser page from the WizardWindow
  • extracting the customization page from the WizardWindow
  • merging the Wizard, WizardToolbar and WizardWindow classes
  • making the Wizard class inherit from GtkAssistant

As pointed out in my last article, GtkAssistant forced a padding to its pages which was problematic as some of Boxes' wizard's pages need to take all the available space to display complex widgets or infobars. This bug have been solved pretty quickly by Matthias Classen who added a way to disable the padding for specific pages. Thanks Matthias, it will be useful. =)

Other stuff

I started working on other stuff too.

I tried to add support for the application/x-cd-image MIME type to Boxes but without success. Starting Boxes with a path or an URI pointing to an ISO file works perfectly, but trying to open one with Boxes via Nautilus or xdg-open didn't work. I need to investigate this.

Last march I started adding a list view to Boxes' collection view. It worked well except for a warning that I didn't understand and didn't have time to investigate. The warning was still present and I tracked it as coming from libgd, I then opened a ticket and submitted a patch, which so far are still waiting for reviews.

I have no time to get bored when working on Boxes! =D

Commentaires

Posts les plus consultés de ce blog

Librem 5 ❤️ GNOME 3.32

I am glad to announce that the tooling I am working on since the beginning of the year is ready to be used!Thanks to new features introduced into libhandy 0.0.3 and 0.0.4 and thanks to a few fixes to Adwaita in GTK+ 3.24.1, you can make GTK+ 3 apps adaptive to work both on the desktop and on the upcoming GNOME-based Librem 5 phone.We are early in the GNOME 3.32 release schedule and the Librem 5 will be released a bit after it, so if you want your apps to work on the Librem 5, now is the best time: use libhandy 0.0.4 and up, use GTK+ 3.24.1 and up and target GNOME 3.32! A few apps like Fractal, Podcasts, Calls and Chatty are already using libhandy's adaptive capabilities, and other apps are working on their adaptive transition like Contacts, Games, Geary and Settings (all are works in progress). libhandy is available in Debian Unstable and Arch's AUR repository, and I wish it would be in Fedora already to let GNOME Settings' CI pass.For the moment, libhandy is a GTK+ 3 widg…

My Name is Handy, Lib Handy

Libhandy 0.0.7 just got released! I didn't blog about this mobile and adaptive oriented GTK widget library since the release of its 0.0.4 version three months ago, so let's catch up on what has been added since.List RowsA common pattern in GNOME applications is lists, which are typically implemented via GtkListBox. More specific patterns arose, where rows have a title at the start, an optional subtitle below it, actions at the end and an icon or some other widget like a radio button as a prefix. These rows can also be expanded to reveal nested rows or anything else that fits the need.So far every application using these patterns implemented the rows by hand for each and every row. It made using these a bit cumbersome and it led to inconsistencies in sizing, even inside a single application. To make these patterns easier to use, we implemented HdyActionRow, HdyComboRow and HdyExpanderRow. HdyActionRowThe action row is a simple and flexible row, it lets you give it a title, a sub…

GNOME at Capitole du Libre 2018

Last Saturday and Sunday I went to the Capitole du Libre 2018 to animate the GNOME booth and help on the Purism one. It was my first time at the Capitole du Libre, and I really enjoyed the event even though I couldn't attend any talk but the closing keynote, which was really interesting as it was a round table with Tristan Nitot and Stéphane Bortzmeyer. The event is about free software and free culture in general, beside GNOME and Purism you could find associations as varied as Nos oignons, Framasoft, OSGeo, Dogmazic, Monnaie Libre Occitanie, Khaganat, ./play.it, 0 A.D., various distros you already all know and more. I was happy to note that the attending crowed was extremely diverse, ranging from persons barely knowing what free software is to Arnaud Bonatti or persons in their early 10s and already more involved into free culture than I am. I was also happy to recognize persons I already met at the JDLL, either animating booths or visiting the GNOME booth.The event welcomed (IIRC…