Category Archives: GNOME

by carlos garcia campos

WebKitGTK+ 2.0 for GNOME 3.6?

That’s the plan! But, what’s exactly WebKitGTK+ 2.0? It will be the first stable release of WebKit2 GTK+ API, leaving the current WebKit GTK+ API in a maintenance mode. WebKit2 GTK+ is not just about multi-process architecture, robustness, stability and all other great things the new WebKit2 model brings, it’s also a redesign of the current WebKitGTK API to make it even more convenient and easier to use.

In the Igalia WebKit team,  we have planned a Roadmap of the tasks we will be actively working on to release WebKitGTK+ 2.0 for GNOME 3.6. Even though unit tests play a very important role in the WebKit2 GTK+ API development, we know that real applications using the API usually reveal issues that the unit tests or test programs like MiniBrowser don’t catch. For that reason, we have set milestones consisting of porting real applications to the new API.

  • GNOME 3.4: Applications using a small part of the API. We will focus on porting Devhelp.
  • GNOME 3.5: With the first unstable releases of the 3.5 cycle we should be able to port applications using the API more extensively. We will focus on porting Yelp.
  • GNOME 3.6: We should be able to port any application using WebKitGTK+ without major regressions. We will focus on porting Epiphany.

This is, of course, a plan, if we eventually don’t manage to achieve the milestones, we will release WebKitGTK+ 1.10 for GNOME 3.6 and current plan will be postponed to GNOME 3.8. Needless to say that any help would be more than welcome 🙂

by carlos garcia campos

libgxps 0.2.0

More than a month ago I released libgxps 0.1.0, the first release of libgxps, but for several reasons I ended up not announcing it. I’ve just released a new version that includes a small API break and a lot of new features and improvements, see the release notes for further details. I’ll release evince 3.3.2 next week depending on this new libgxps version (when building with –enable-xps).

by carlos garcia campos

WebKit2 GTK+ MiniBrowser ported to GTK+ API!

MiniBrowser is a small web browser application for testing WebKit2. MiniBrowser for the GTK+ port has been working for some time now, but it was implemented using the C-based WebKit2 API. WebKitGTK+ 1.7.1 introduced an initial high level GTK+ API for WebKit2 more similar to the current WebKit1 GTK+ API. This week, Igalia‘s WebKit team started to port the MiniBrowser code to use the new GTK+ API.

MiniBrowser running
MiniBrowser running

This new GTK+ API is far from complete compared to the WebKit1 API, but it’s already possible to implement a small application with basic features, and we have plans to create a webkit2 branch for epiphany soon. API is already documented in the code, but the html generation is not available yet. We are already working on it so that WebKitGTK+ 1.7.2 will generate the API documentation when compiled with –enable-gtk-doc and –enable-webkit2 and it will be available on the WebKitGTK+ website too.

Thanks to the multiprocess architecture, WebKit2GTK+ solves the problem of using flash (or any other plugin using GTK+2) with GTK+3. The UI process depends unconditonally on GTK+3 and the plugin process is always built with GTK+2. And of course, flash will never crash or block your web browser. Plugins are broken in WebKitGTK+ 1.7.1 due to a bug that has already been fixed, so in order to try it out you need to either wait until 1.7.2 is released or build WebKit from current git master.

MiniBrowser showing a youtube video
MiniBrowser showing a youtube video
by carlos garcia campos

GNOME Panel Dock

When GNOME 3.0 was released some weeks ago, I finally switched to gnome-shell by default. Performance is quite good in my laptop, so the only problem was getting used to the new user experience. After several weeks using it, there are only a few things I really miss:

  • Real launchers: I use a lot of gnome terminals, and when I click on the gnome-terminal launcher I really want a new terminal.
  • Window list applet: ALT+TAB is a mess when you have several gnome terminal windows because all thumbnails look pretty similar. Window list applet allowed you to see all your windows in the current workspace and select any of them by a single click. It’s true that window list applet buttons don’t help to identify your terminal windows either, but you can reorder them and I usually identify a terminal window by its position in the panel.
  • Workspace switcher applet: similar to window list applet, I want to be able see all my workspaces and swtich to any of them by a single click. I always use the same workspace for the same kind of activity (mail, web browsing, devel, irc, im), so it’s very annoying when a workspace dissapears just because I’ve removed all the windows.

I still don’t have a workaround for all my use cases, but I’ve managed to make my life a bit easier by using a gnome-panel inside the shell. The only thing I had to change in gnome-panel was the D-Bus service name. And here is the result:

GNOME Panel running with GNOME Shell
GNOME Panel running with GNOME Shell
by carlos garcia campos

GTK+/MeeGo Handset integration: Week 10

GtkScrolledWindow: kinetic scrolling

The first time I tried to use the press-and-hold patch to allow selections and drag and drop operations in GtkScrolledWindow when kinetic mode is enabled, it didn’t work because press-and-hold patch uses some of the signals (motion event) consumed by GtkScrolledWindow using the captured-event. So, I thought I could make it work by using the captured-event for the press-and-hold implementation too. I reworked the press-and-hold patch to use the capured-event and the scrolled window patch to use the press-and-hold signal, and it indeed worked!

by carlos garcia campos

GTK+/MeeGo Handset integration: Week 8

GtkEntry:placeholder-text

Good news here, Matthias reviewed and approved my patches, so I committed them.

In the same bug report, Johannes Schmid proposed to add placeholder text to GtkCellrendererText too, and I think it makes even more sense than for entries since it’s not obvious when a treeview cell is editable. Glade has a custom implementation for the signal editor. I filed a new bug report and attached a patch.

GtkScrolledWindow: kinetic scrolling

While I was on vacation I had the opportunity to play with an Android phone for a while (thanks Roca!), I was very curious about how they solved the problem of selecting text in scrollable widgets and it turned out that they use press-and-hold. After a long press the current word is selected and two handles show up to extend the selection. I don’t like the handles, and I don’t think we need it, but the press-and-hold solution might work for us. We can simply wait after the long press to cancel the scrolling operation and propagate events to child widgets normally so that both selections and drag and drop operations will work as if kinetic scrolling mode were not enabled. I submitted a patch that uses press-and-hold to allow selections and drag and drop operations when kinetic scrolling mode is enabled in GtkScrolledWindow. However, I couldn’t use any of the solutions proposed for press-and-hold in bug #315645. As kris commented (thanks kris for your feedback in this and other bugs, by the way!), this press-and-hold use case changes the game a bit, so we’ll have to think a bit more about it.

GtkLiveEntry

I noticed my patch had a couple of regressions regarding GtkEntry popdown menu handling, corresponding to old bugs #169534 and #71868. Updated the patches (GtkLiveEntry and GtkTreeView) to apply on current git master and fix the regressions.

by carlos garcia campos

GTK+/MeeGo Handset integration: Week 6

GtkWidget::press-and-hold signal

It’s unclear to me whether we really need a new signal for this, or we can just synthesize right click events after the long press. So, I’ve reworked the patch to do the latter, showing the same animation and sending a right click event only when the toucscreen mode is enabled (GtkSettings:gtk-touchscreen-mode). Instead of using the touchscreen setting, we could get the source device of the button press event to enable press-and-hold only when it’s originated by a stylus or the finger, but there’s not a GdkInputSource for the finger yet.

GtkEntry:placeholder-text

Company reviewed my patch and pointed out that we could use a single pango layout instead of having one for the main entry text and another one for the hint text. Both texts are never shown at the same time, so it should be possible to use a single pango layout. He also proposed to rename it to placeholder-text, which is the name used in maemo indeed. So, I rewrote the patch addressing both issues.

API also commented on the bug regarding the GailEntry patch. In order to make sure the placeholder text is always available for the a11y system, no matter whether there’s a tooltip text or not, API suggested to use the AtkObject attributes instead of the description, adding a new attribute for the placeholder text. I reworked the GailEntry patch to do exactly that.

Gtk Meeting

During the GTK+ meeting I proposed to include all the bugs of this project into the list of bugs targeted for 3.2. Matthias has already branched so master branch is now open for new stuff.

Next week

I’ll be on vacation for the whole week 🙂

by carlos garcia campos

GTK+/MeeGo Handset integration: Week 5

GtkWidget::press-and-hold signal

I haven’t updated the patch this week, even though some interesting points were raised by garnacho, who tried the patch in a real touchscreen device, because the general approach is still under discussion.

GtkEntry:hint-text

I rewrote the patch to explicitely add the hint text instead of using the tooltip text as suggested by Matthias. Also wrote a patch for GailEntry to return the hint text as ATK object description only when there isn’t a description nor a tooltip text, as API proposed. However, Joanmarie thinks the hint text should always be exposed via the description.

GtkLiveSearch

I finished the patch to add the new widget GtkLiveEntry that works like the current search window used in GtkTreeView. I also wrote patches for GtkTreeView, Evince and Nautilus to use GtkLiveEntry instead of their own implementations. Now it’s time to think about the other part of GtkLiveSearch, the search stuff.