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.

Commentaires

Posts les plus consultés de ce blog

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…

GNOME Games 3.24

GNOME 3.24 will be out in a few weeks and with it will come Games 3.24. This new version will offer a few new features and many refinements, some of which have been implemented by new contributors theawless and Radhika Dua, kudos to them!Find how to get the latest nightly and (soon) stable Flatpak versions of Games on its web page.A Libretro Core Descriptor SpecificationIn its version 3.22, Games stopped using a hardcoded list of well known Libretro cores and instead looked for the right one to run a game by parsing files describing their corresponding Libretro core's capabilities. These files came from the libretro-super repository and were slightly modified to better suit Games' needs.The concept was great but the format of these files proved to be not very well suited for the job: many information were not useful to Games, some information it needed were lacking, the syntax wasn't specified, complex cases like firmwares were implemented in a messy way, some useful infor…

GNOME Gaming Handheld

Recently I got myself a GPD Win, to make it simple it's a PC in a Nintendo 3DS XL form factor, with a keyboard and a game controller. It comes with Windows 10 and many not too demanding games work perfectly on it: it's perfect to run indie games from Steam and for retro consoles emulation.But who simply want to play video games, let's make it fun, let's put a penguin in it! On this GNOME wiki page I'll report all my findings on Linux support on this machine, focusing mainly on OpenSUSE for the moment. Wouldn't it be awesome to have a fully working and easily installable GNOME desktop running Games and Steam on this machine? 😃