GSoC Report #1

For the past few weeks I’ve been working on the first part of my project which consisted in getting rid of the deprecated GtkAction API (with the related GtkActionGroup, GtkUIManager) and port everything to GAction. This blog post is long overdue as I hoped I could finish the task before reporting on my project’s progress, considering the port one of the milestones of my project. However, without much knowledge about the specifics of GtkAction and GAction, I greatly underestimated the time I will spend on finishing my task, and therefore, I delayed my post up to this very moment, when my task is nearing completion. I will submit the patch after passing the patch by Michael for a final review.

Due to the nature of GtkAction, except working on the more difficult problems, I spent most of the time trying to figure out the best ways of replacing entire files consisting of mostly boilerplate code with only one or two functions using the new GAction API. The resulted patch is pretty big (41 files changed, 2848 insertions, 3541 deletions), but reordering code and renaming functions to increase consistency accounts for most of the changes.

One of the bigger problems I encountered was related to WebKitContextMenu, the menu that pops up when right clicking the page content rendered by WebKit. The way GNOME Web handles this menu can be summarized in a few steps:

  • connect a callback to the “context-menu” signal, which is emitted right before the menu is about to be displayed
  • save the relevant items from the menu for later use
  • remove everything with webkit_context_menu_remove_all()
  • create new items from stock actions or GtkAction’s
  • populate the menu item by item, using the items previously saved and the newly created items, taking into account the position of the cursor when right click button was pressed (different actions if the user right-clicked on a link, an image, a video etc.)

My problem consisted in WebKit not having an API that I can use to create a context item from a GAction, the default constructer, webkit_context_menu_item_new(), taking a GtkAction as parameter. The way I handled this was by creating a new proxy function, that takes a GAction and a label as parameters, webkit_context_menu_item_new_from_gaction_with_label(), and creates a GtkAction that in turn is used to create a WebKitContextMenu item with the existing API. Before creating the menu item, a callback is connected to the “activate” signal of the GtkAction and a binding is created between the ‘enabled’ property of the GAction and the ‘sensitive’ property of the GtkAction, so by clicking the item or changing the action’s state, a response is triggered. Currently, the function can only be found inside the GNOME Web’s source code, but I’m already preparing a patch that I will submit to WebKit.

Another problem was related to the fact that GtkAction’s are heavily used for the bookmarks subsystem. After consulting with my mentor, Michael, I chose not to port that code yet, as with the next part of my project most of that code will wind up being rewritten or completely removed.

The goal of the port was to make my work easier while working on the second part of my project. While working towards achieving my goal, I also fixed some smaller bugs, achieved a better separation between different kinds of actions (window actions, app actions, toolbar actions etc) and greatly simplified some parts of the code.


Google Summer of Code 2016

Hello everyone! I am participating in the Google Summer of Code program for the second time with GNOME, this year working on Epiphany. I will be mentored by Michael Catanzaro, who was also my mentor for my last summer’s project. I am one of the two students working on this product, the other person being a friend of mine. We are both excited to leave our mark with some serious contributions.

The goal of my proposal is updating the bookmarks subsystem by refactoring the current code and implementing a new bookmarks menu design proposed by the designers.

Browsers evolve extremely quickly, but if there’s one browsing feature that’s stood the test of time, it’s browser bookmarks. The current dialog has lots of problems, giving the browser an unfinished look and the impression that everything is about to crash at any moment. The code is old and spread amongst too many files, making it hard to manage and refactor.

Upon completion, the current problems should be fixed not by patching different parts of the code for specific bugs, but by having code work properly regardless of the processed data or user requests. The new design is also more minimalistic, making bookmarks easier to use and manage.

Moreover, there are increased benefits to a bookmarks refactoring considering there is the other project that plans to touch on bookmarks by allowing Epiphany to use a storage server to sync bookmarks (and more) between multiple instances of Epiphany on different computers. Having bookmarks work as intended is of great help to Web’s users, gives the browser a more solid look and it’s a step forward towards a complete, modern browser.

Similarly to last year, I plan to start working in the community bonding period (any day now) to account for my exams session that takes place somewhere at the start of the coding period.

These being said, expect another blog post soon where I will talk about the first steps I’m taking towards completing this project successfuly.


Short introduction and my progress so far

I’ve been using the GNOME Desktop Environment ever since I first laid my eyes on it. Being an ardent supporter of open source and volunteering, I made some contributions to GNOME before even thinking of applying to Google Summer of Code. Imagine how happy I was when finding out that I had been accepted to the program under GNOME.

The ultimate goal of my project is the modernization of GNOME Nibbles. It’s one of the few games that have not been yet revamped as part of the Games Modernization Initiative. The idea is to port as much of the game as possible to Vala, using the same MVC design pattern that stands at the base of the rest of GNOME’s games. I will be mentored by Michael Catanzaro, a very involved and helpful person, who also helped me out with my first contributions, giving valuable feedback and thorough patch reviews.

Due to having my exam session after the official start of the “Students coding” period, I have decided to begin working on my project earlier, to make up for any time I will lose by focusing on studying. Even if I was not that active during this period, I have managed to get things going, making some progress and entirely respecting the previously designed timeline.

In the first few days, I spent some of my time analyzing most of the GNOME games, trying to understand how everything ties together, how are the projects structured and what similarities exist between each of them. With this information, my implementation of the game will have some common elements with the other games, making it easier to maintain and also allowing developers that are willing to contribute to more than one game to spend less time trying to get familiar with the code base and more time solving problems and implementing features.

Next, after setting up a project directory with all the required configuration files and makefiles, I worked on creating a very basic window, as seen below.


Even if it may not look special at all, there was some effort involved in setting it up. The window is being loaded using Gtk.Builder from an .ui file, together with its Gtk.HeaderBar which we’ll be putting to good use. Besides that, I have also added a GSettings instance which provides a convenient API for storing and retrieving application settings (in our case, the user preferences – everything from window size and state to more specific things like keyboard controls and tiles size).

After some more fiddling around with the source code, I have also added a “new game menu”, one that the C version seems to lack. For now, it only contains a new game button which will switch to the game view when clicked. It’s not much, but having this will make it very easy later in the development process for adding more buttons and switches.

Screenshot from 2015-05-26 02:31:30

The more interesting part was reading up on Clutter and starting the implementation of the actual game view, which is based on a GtkClutter.Embed. First step was loading the texture file (we are using the old assets for now) and filling the background with it.

Screenshot from 2015-05-26 02:43:57

This part worked out pretty smoothly so I moved onto the next one. Based on the already existent level files, I had set up the coordinates of each wall and loaded the corresponding pixmaps which resulted in displaying the beautiful designs we had from the C version of the game.

Screenshot from 2015-05-26 02:54:32

The last part I had worked on was implementing the ability to resize the game window while maintaining the desired aspect ratio and having everything scale accordingly (the walls and the background for now). For that, my mentor suggested I use a GamesGridFrame, which was also was a small library designed for the C version of the game. Considering the code was in good shape and having no reason to reinvent the wheel, I wrote a Vala API file with some help from Lethalman (Luca Bruno) and flo over at #vala on IRC, which allowed me to access the existing C library without the need for runtime bindings (Yey Vala!). With minimum effort, I achieved the desired result while also having some of the texture/drawing bugs fixed which plagued the C version of the game.

For the next few days before my end of semester exams, I will begin implementing the Worm class which requires some careful planning and some special attention. Even if I will be mostly busy studying after that, I will still try to work on some of the more minor stuff and hopefully manage to make another blog post sometimes soon.

I hope this post put some light on what I’m actually doing for my GSoC project and I’m very excited of what has yet to come.

Iulian Radu