Accéder au contenu principal

Boxes' hardening sprint: two weeks in

Finishing my 4th year of CS studies

I spent the last two weeks working hard on the report and the presentation of the project my colleagues and I worked on all the semester long: creating the Stibbons multi-agent system programming language and development environment.

I am very proud of what we accomplished and I’ll probably present it to you in the upcoming weeks. =)

Planning the port of Boxes' installation wizard to GtkAssistant

All this work unfortunately let me little time to work on Boxes, but I nonetheless took some time to look at how its installation wizard is implemented and planned how to port it to GtkAssistant.

Boxes' installation wizard

Currently, the wizard is ordered that way:

  • WizardWindow
    • WizardToolbar: the toolbar containing the navigation buttons
    • Wizard: the stack of pages

Most of the wizard’s intelligence seems to lie in Wizard and its pages, I’ll have to dig further into Boxes' code in order to fully understand how the wizard work.

GtkAssistant

A GtkAssistant is a window which allow a developer to guide the end users through complex configuration processes by splitting them into several steps represented by pages that can be completed.

GtkAssistant’s API is pretty simple, you can:

  • add or remove pages to the assistant
  • navigate through them
  • set the title of a page
  • set the type of a page
  • set whether a page has been completed or not

If a page has been completed, the toolbar allow the end user to move to the next page, except if it is the last page in which case it will allow him to complete the whole configuration process.

The plan

Despite a similar behaviour from the end user’s perspective, the wizard’s behaviour differ significantly from the one of GtkAssistant. Some tailoring will be required to make them match.

To smoothly pass from the current wizard to a new one using GtkAssistant, I plan to follow these steps:

  • implement one by one the needed components (understand “logical sets of public methods”) of GtkAssistant into WizardWindow:
    • setting and getting the current page
    • setting and getting a page’s title
    • setting and getting whether a page have been completed or not
  • once all the necessary components have been implemented, make WizardWindow inherit from GtkAssistant and remove the custom method implementations
  • remove the now unneeded WizardToolbar and Wizard classes.

Hopefully, next week will be enough to implement such a change!

Commentaires

Posts les plus consultés de ce blog

GTK+ Apps on Phones

As some of you may already know, I recently joined Purism to help developing GTK+ apps for the upcoming Librem 5 phone . Purism and GNOME share a lot of ideas and values, so the GNOME HIG and GNOME apps are what we will focus on primarily: we will do all we can to not fork nor to reinvent the wheel but to help allowing existing GTK+ applications to work on phones. How Fit are Existing GTK+ Apps? Phones are very different from laptops and even tablets: their screen is very small and their main input method is a single thumb on a touchscreen. Luckily, many GNOME applications are touch-friendly and are fit for small screens. Many applications present you a tree of information you can browse and I see two main layouts used by for GNOME applications to let you navigate it. A first kind of layout is found in applications like Documents, I'll call it stack UI : it uses all the available space to display the collection of information sources (in that case, documents), clicking a...

libhandy 0.0.10

libhandy 0.0.10 just got released, and it comes with a few new adaptive widgets for your GTK app. You can get this new version here . The View Switcher GNOME applications typically use a GtkStackSwitcher to switch between their views. This design works fine on a desktop, but not so well on really narrow devices like mobile phones, so Tobias Bernard designed a more modern and adaptive replacement — now available in libhandy as the HdyViewSwitcher . In many ways, the HdyViewSwitcher functions very similarly to a GtkStackSwitcher : you assign it a GtkStack containing your application's pages, and it will display a row of side-by-side, homogeneously-sized buttons, each representing a page. It differs in that it can display both the title and the icon of your pages, and that the layout of the buttons automatically adapts to a narrower version, depending on the available width. We have also added a view switcher bar, designed to be used at he bottom of the window: HdyView...

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 Rows A 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 . HdyActionRow The action row is a simple and flexible row, it lets...