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.

Advertisements

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.

Iulian