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

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 an element from t…

One Widget to Adapt Them All and to The Librem 5 Port Them

In my previous article I shared my plans to help porting existing GTK+ applications to Purism's upcoming Librem 5 phone without having to fork them. This article will present the GTK+ widget I developed for Purism to make this happen.For more information on what Purism is working on for the Librem 5, please check Nicole Faerber's latest article.C'est pas sorcierThe underlying idea is to allow applications to dynamically switch between the two main GNOME application layouts: a row of panels — each panel being the view of an element from the previous one — and a stack of panels. The goal isn't to changes applications using the stack paradigm but the ones using the row one, allowing them to reach smaller sizes and to be usable on constrained sizes while keeping their initial paradigm and design when the screen space is sufficient. The development cost to port the applications to this adaptive design should be as low as possible.To achieve that, I wrote a GTK+ widget which…

The Path to GNOME Games 3.26

Games received a non-negligible amount of changes that you will find in 3.26. These changes can be big as much small, and more are to come!Building the Games CollectionGames presents your games collection and if everything goes as expected, it does so without the need of any input from you. From an implementation point of view it sounds simple to do, just ask Tracker “Hey, gimme all the games” and it’s done. If only it was that simple! 😃 The system has no idea which files represent games and which doesn’t, but it can associate a MIME type to each file thanks to shared-mime-info. shared-mime-info already had a few video game related MIME types and we added a lot more such as application/x-genesis-rom.That done, we can query Tracker for files having specific MIME types that we know to often represent video game files. Unfortunately, each of these files doesn’t necessarily represent a game and a game isn’t necessarily represented by a single file: some files may be invalid and hence rep…