Accéder au contenu principal

GSoC 2014 report 2

What an eventful month! Lots of code have been read, produced, reviewed and refused, several code designs have been proposed, but as everything was work in progress, I didn't fell it was exciting enough to blog about it at that time.

But here it is! The blog post that explains it all.

Multiple displays per machine

I mostly spent the third week trying to have multiple displays for a SPICE machine, which implied reading a lot virt-manager's code and some of spice-gtk's code.

I achieved to get the maximum number of displays available for a machine and, with Christophe Fergeau's help, to get some good results: we were able to have multiple displays each in its own window, but we were not able to open them up from Boxes yet (the session had to have them already opened).

Multiples machines

Jakub Steiner proposed a design focusing mainly on having multiple machines running side by side in different windows:
It settled what idea would be implemented, and a new bug report have been created to reflect that.

The window singleton

The main problem that have been encountered is that Boxes uses a static window instance that is accessed directly by a huge number of classes.

It is very problematic, as if you summon a second instance of this window's class, any action in the second window will have its reactions produced not on itself but on the static window instance, which is conceivably problematic who you want to implement a multi window feature.

Zeeshan proposed not to change the app's design to allow having multiple windows but to have multiple one window instances communicating via D-Bus.
It have its pros, as it would make Boxes more resistant to crashes, to slowdowns and to be be naturally more parallelized, but the design would most certainly have ended up being a gigantic mishmash.

This idea have been abandoned in favor of a code refactoring.

Getting rid of the window singleton

In Boxes' design, the app's controller is scattered over all the classes.
In my opinion it is problematic:
  • you can't use a class in any different way without changing the class' code
  • changing a simple behaviour may require modifying lots of classes
  • you can't have a good overview of the application's behaviour  which may confuse newcomers
I spent several weeks refactoring the app, trying to move the controller closer to the root of the composition tree by using signals to make the leaf classes dumber but more modular.
It worked preety well and Lasse, which reviewed my patches, and I  were preety proud of the newly produced code and design.


At the time when the code started to take shape, unfortunately, Zeeshan had harware failures which made him not able to check out our work.
Because of that, we knew quite lately that he preferred the code to stay as close as possible from the actual design, changing as less code as possible in the process.
It is pretty wise, as he haves to maintain the application, and so I started over with these considerations.

So far the last set of refactoring patches are well received, all they need is a little bit of polish to fully shine!

What's next

It's now the time of GUADEC, here I'll be able to chat with my colleagues and to meet other gnomes!
If everything go as planned, the patches will be merged during this period, and I'll be able to actually implement the multi window feature after that!

Commentaires

  1. "Zeeshan proposed not to change the app's design to allow having multiple windows but to have multiple one window instances communicating via D-Bus."

    He actually was more like thinking aloud and attempting to keep the number of changes less intrusive. :)

    RépondreSupprimer

Enregistrer un commentaire

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…