Accéder au contenu principal

GSoC 2014 report 1

Week #1

I started my work on Boxes on June's 2nd. This first week served as a transition from my examinaton period to the GSoC.

I had some unfinished work from my application period: two bugs to solve.

The first one was #726252 - Refactor topbar's children into separate classes/modules

The patches were pretty much finished but they were not perfect, all they required was some love.
It took me time to transition my mind from the student mindset to a more engineering one, but hopefully, the patches were accepted at the end of the week.

The second one was #692383 - Allow editing of box name in the tite

Just as for the first bug, I had patches ready but not perfect, and they were dependent on work done for the first bug.
As it took me time to correct the patches for the first bug, I let this one aside.

My project is to add multi-monitor support to Boxes, so I also took time to read Boxes' code, especially the App, AppWindow, Display and Machine classes as they seem to be the one I'll hack the most, and to think about how I can implement multi-monitor support on top of this.

Week #2

I updated my patches for bug #692383 but let them aside to focus on my project.

While discussing the project with several persons like Zeeshan Ali, Christophe Fergeau, Jakub Steiner and Lasse Schuirmann, a problem came up: everybody have a different idea of what "adding multi-monitor support" means.

The main ideas where:
  • multiple monitors for one machine
  • multiple monitors for one machine only on fullscreen
  • multiple machines with one monitor
  • multiple machines with multiple monitors 
What will finaly be done will be decided by the maintainers and the designers (mainly Zeeshan Ali and Jakub Steiner).

I continued to read Boxes' code and understand its design.

Currently the Display listen to the App's state and set the state in response (via a static instance).
The App handles the window's state, wich is not problematic since they both are singleton.

This design works well for a single machine and a single window but is too static for multiple ones, so a deep rewrite may be needed and will take more time.

What needs to be done will be done but don't expect results soon.
Libellés :

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Moving the Blog

I am moving this blog to greener lands: https://fediverse.blog/~/AdrienPlazas . The existing articles will remain here on Blogger, and new articles will land on the fediverse.blog Plume instance.
1 commentaire
Lire la suite

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
7 commentaires
Lire la suite

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
5 commentaires
Lire la suite