Accéder au contenu principal

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 Collection

Games 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 represent no games and some games may require multiple files, a typical case of multi-resources game is a multi-disc PlayStation games. Depending on the files and the kind of games they may represent, we may have to reject them, parse them, store them and gather them into a single game.

We also have to be particularly careful when games are represented by files with a generic MIME type such as application/zip — i.e. MAME games — or application/x-cue as most of the search results for these will probably be invalid.

To these are added more exotic game sources such a Steam games or so called desktop games — the games from your applications menu and represented by .desktop files. These add another layer of complexity as gathering the resources representing these games has to be done in a slightly different way than for your typical game files. For example, Steam is a video game store and launcher giving a unique ID it each of its games: a number starting from 10 with Counter Strike.

How Games 3.24 Builds your Collection

Games 3.24 handles no game types directly, it relies on plugins for that. Plugins are providing a GameSource, these game sources are iterable and produce Game objects in the way they please. Most of them find the game resources by querying Tracker for URIs of files of specific MIME types and by parsing these files to build the Game objects; others handle the resulting URIs in a more complex way to support multi-disc games, while others are querying the URIs of the .desktop files of the registered applications or are parsing the Steam library.

This works well but it led to some code duplication and adding support for a simple type was done by copying some other plugin and tweaking one or two strings. Copying the plugin is fastidious for an actually very small change. Some refactoring is needed.

How Games 3.26 Will Do It

For Games 3.26 the way the games collection is built has been completely refactored, GameSource’s role has been split into several parts: UriSource objects output URIs from whichever way they want, UriGameFactory objects take URIs and output games in an asynchronous way — giving them URIs may result or not in the creation of a Game object or in the improvement of an existing one — and GameCollection act as a glue in-between them. A UriGameFactory declares the URI schemes it can handle and the MIME types of the files it can handle — the file URI scheme is implicit —, allowing GameCollection to send URIs only to the relevant UriGameFactory objects.

Plugins don’t declare GameSource objects anymore but instead UriSource and UriGameFactory ones. An interesting new change is that plugins now also declare MIME types of files to search, avoiding the need to declare a UriSource for a very common search case: they all will be given to a specific UriSource which will perform the corresponding Tracker queries; this also solves the problem of searching multiple times for the same MIME type in different plugins. It doesn’t make sense to declared MIME types to search that are not handled by an UriGameFactory, but it can make sense not to search for all the handled MIME types, more on that later.

Many very simple types have been reduced to the RetroSimpleType type: a simple declaration of the MIME type corresponding to the simple game type, whether this game type should be searched and the name of the corresponding gaming platform.

{ "application/x-gameboy-rom", true, "GameBoy", "game-boy" }

Example of a SimpleType declaration.

All the supported game types were successfully ported to this mechanism and it is expected to support any future game type.

Adding More Games

Thanks to all these changes, it is now possible to give any URI to GameCollection and it will handle it properly, which means we can now have external game URI sources and properly use their results! This allows us to handle opening files with Games: the users can double click on their game file and if all goes well, Games will automatically run them! Another source of games that has been added is a “Add game files” button on the games collection view: the user can select game files to be added to the collection, given they are valid.

Opening a game file with Games.

All the game resources you added to Games are saved and will be loaded when starting the application again: if for some reason searching game files doesn’t work, you will still be able to use Games. This also allows you to manually add games that can be handled by Games but which it doesn’t know how to search for right now, either because of the lack of a clear MIME type representing the game type or for the lack of ability to know if a URI represents a game or something else.

Games Support

Games 3.26 will list Atari Lynx, MS-DOS, WonderSwan and WonderSwan Color games and, given you have the corresponding Libretro core installed properly, you will be able to run them too. Unfortunately as it can’t make a difference between regular MS-DOS executables and MS-DOS games, Games can’t automatically look for your MS-DOS games and you will have to manually add them to your collection. Games doesn’t support the mouse for Libretro cores right now, so you won’t be able to run MD-DOS games requiring one right now.

The detection of PlayStation discs has been reworked and the disc images are now parsed properly, which should greatly expand the number of detected discs and games. If you still have PlayStation games not showing up in your games collection or if games used to show up but don’t anymore, please file a bug!

Games was displaying desktop games that were asking not to be displayed or to be hidden, this is now fixed.

Gamepad Support

The gamepad handling has been ported from Vala to C. This change is a solution to the problem of our usage of the Vala preprocessor which was poorly handled by the Autotools, resulting in broken tarballs. Another solution would have been to not use make dist.

It has been refactored a bit to make Gamepad objects emit events very similar to GdkEvent, using Linux event codes instead of custom gamepad event types. This makes the gamepad support simpler and more flexible by improving the definition of events and by avoiding a layer of conversion for what is our only gamepad backend anyway.

UI Improvements

The GtkDialog objects used when resuming or quitting a game are replaced by GtkMessageDialog ones, as this type is more fitted to the messages they convey.

The look of the media selector has been improved, using checkmarks to denote the currently used media.

MediaSelector in 3.24 (left) and what will become 3.26 (right).

The games collection now use theme relative colors instead of ones set by the application, making it work better with any theme or with the light theme variant.

A useless sorting invalidation in CollectionIconView has been dropped, making the games collection load a bit faster.

Thanks to changes in retro-gtk, the logging of messages from Libretro cores has been improved: their log domain is now the core’s name instead of Games’ one, which should greatly help debugging.

Evolution of retro-gtk

retro-gtk is an important dependency of Games as it allows it to use Libretro cores. In what will become retro-gtk 0.12 a demo application has been added, it should help to develop and test retro-gtk without relying on Games.

So far, to load the games to use with a Core object, Core.load_game() or Core.prepare() had to be called just after Core.init() and the complex disk interface may had to be used if the Libretro core required it. Now the users of retro-gtk just have to use Core.set_medias() before calling Core.init() if any game has to be passed to the core, the games will then be loaded during the call to Core.init() and the user doesn’t have to take care of the disk interface. If multiple medias were passed to the Core, they can be changed with a call to Core.set_current_media().

As previously said, logging has been improved.

The CoreView widget has been added, it can handle the video output and some inputs — like keyboard and mouse inputs — for the core. It is still in an early stage and its design is expected to evolve, its goal is to be the simplest way possible to handle a Core. It is used by the demo application.

retro-gtk is slowly being ported to C and its API is being simplified in the hope to make the library as simple to use and as stable as possible.

Other Ongoing Works

Other works are ongoing too! Abhinav is working on allowing you to configure your gamepads in case Games doesn’t support them yet and Yasitha is working on supporting the multiple features of the Nintendo DS so you can run its games perfectly!


  1. Cool, any updates for the Nightly flatpak version?

    1. All of these should already be available on the nighlty Flatpak version, if they are not then it's a bug.

    2. I install nightly version from and it continues in 3.24 version...I reinstalled everything again and still follow the same version, it must be a bug (fedora 26 64bit)

    3. Uninstall the version you have and reinstall it, the link from somehow was pointing to the stable version until a few days ago.

    4. Actually now I have the nightly version. I appreciate much the improvements and although I still cann't use all my gamepads that is work in progress. The only real problem I see is that the games do not play well using Wayland (gnome-shell), especially the sound is cut consecutively, so I had to use the Xorg session.

    5. That's strange that sound is a problem on Wayland… which version of GNOME are you running and on which OS and OS version? I found Games to run very badly on Wayland before GNOME 3.24 but way better than on Xorg since then.

    6. Fedora 26 64 bit with gnome 3.24.2. Gnome games flatpak stable and nightly.
      In both versions of gnome-games the problems are only manifested using gnome-shell in wayland. I made a small recording, however, easyscreencast tool added a slight pause in the version with xorg, however, the difference between both videos is enough to notice the problem.

    7. I have no idea what may cause this right now, don't hesitate to file a bug and to attach your videos here so we keep track of the problem:

  2. The plug and play, zero configuration and zero hassle experience is what we are trying to reach even though it's a very complex problem, which explains our slow progress.

    If you expect some games to be work with Games but they don't, don't hesitate to file a bug! :)

  3. What are the keys that represent a gamepad if the keyboard is used? I am trying to use Antimicro. Thank you.

    1. Using Antimicro you can generate a game controller mapping string, see here:

      Once you have the mapping string, add it to `~/.config/gnome-games/gamecontrollerdb.txt`, if the file doesn't exist, just create it. Restart Games and it should work.

      If that doesn't work, then check here for the currently hardcoded keys:

    2. The first thing I mention had already tried to generate a string with Steam, however it didn't work. I tried again with Antimicro but it doesn't work. Just add that line without adding anything else?

      Now I was trying to get gnome-games to recognize the gamepad as the keyboard, but it doesn't seem to be possible either. When I open gnome-games and use the keyboard everything seems to work fine, but when I use the gamepad some buttons are not recognized.

  4. That's a great article post on this blog page thanks for sharing it. click here forcall center dialer System Price in India and Best Predictive Dialer Software


Enregistrer un commentaire

Posts les plus consultés de ce blog

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

Moving the Blog

I am moving this blog to greener lands: . The existing articles will remain here on Blogger, and new articles will land on the Plume instance.

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