GTK+/MeeGo Handset integration: Week 4

GtkWidget::press-and-hold signal

Last week I submitted a work in progress patch just to show my idea of using a new style class to implement the animation instead of changing the cursor. This week I completed the patch creating a new style class GTK_STYLE_CLASS_PRESS_AND_HOLD and implementing the animation in the theming engine using a variation of the current spinner animation. Also fixed the animation to work when there’s no composite manager running. I haven’t plan to continue working on this patch unless it’s reviewed and it needs more work, of course. Matthias already commented about the general approach.

GtkEntry:hint-text

I started to work on this bug this week. Like with press-and-hold, this bug had a working patch attached, so I simply ported it to GTK+3 and updated to apply to current git master. It requires some more work though.

GtkScrolledWindow

Submitted a new patch to add a new auto-hide-scrollbars style property, to hide the scrollbars after a timeout when kinetic scrolling mode is enabled.

GtkLiveSearch

With the idea of splitting it into a general purpose entry widget and an object for the search, I have started to write a new widget, based on EmpathyLiveSearch, GtkTreeView and Evince code, that shows a popup window with an entry when typing on a hook widget. I have nothing to show yet, but I plan to finish it during the following week with patches for GtkTreeView and Evince too. Regarding the search part, Benjamin has the idea to add a GtkSearchable interface.

GTK+/MeeGo Handset integration: Week 3

The initial plan for this week was continue working on kinetic scrolling support for GtkScrolledWindow, however I decided to take a look at the other bugs to give some more time to get review/feedback of the kinetic scrolling work in progress patch.

GtkWidget::press-and-hold signal

This looked easier, since it already had a working patch attached to to the bug. I started porting the patch to GTK+ 3 to make it work with current git master. The signal is quite simple, it’s emitted when the mouse button is pressed for a given amount of time. If the mouse pointer is moved (beyond the drag threshold) during the long-press, the operation is cancelled. The tricky part is the animation that should be shown during the long-press to provide visual feedback to the user that something is going to happen when the mouse button is released. The patch, based on hildon code, implemented the animation by changing the current mouse cursor to an animated one. I didn’t like this approach. Talking with Carlos, he suggested to use a transparent popup window with a custom animation similar to the one implemented in the locate pointer plugin of gnome-settings-daemon. I thought we could even leave the animation to the theme engine and implement a popup window that simply calls gtk_render_activity(). So I wrote a new patch that uses the spinner style class to render the animation just to show how it would work. If we agree on this approach we’ll add a new style class and implement a custom animation in the theme engine so that it could be override by themes.

GtkLiveSearch

This is a widget already used by empathy, based on hildon code too, to show a search entry when typing on a given widget. It provides both, the UI to show the search entry, and a match function that implements the search algorithm. I think they are actually two different things. The widget that connects to key-press signal on a hook-widget to show an entry is implemented in other places like GtkTreeView, and even for other purposes than searching like the goto window used by evince to jump to a random page in presentation mode. The search algorithm might be used by other applications that use another UI like a find bar or a dialog.

GtkScrolledWindow

When kinetic scrolling mode is enabled, the scrollbars don’t make sense anymore as a control since the whole view is a scrolling control, however they still make sense as an indicator. HildonPannableArea has its own scrollbars, smaller and without stepper buttons, that are shown when scrolling starts and dissapear (with a fade animation) after a while when the scrolling operation has finished. Playing with the GTK+ theme I realized that we don’t need to implement our own scrollbars, we can just use a custom css to get something similar to the HildonPannableArea scrollbars. The only thing we would need is a way to show/hide the scrollbars that might be just a GtkScrolledWindow style property so that everything depends on the theme.

GDK API removed from poppler-glib

GDK dependency has been optional since poppler 0.8 and the API was deprecated in 0.16. I’ve just removed the GDK dependency in current git master so poppler 0.18 will only depend on glib and cairo.

If you are still using the GDK API, please port it to cairo before 0.18 (scheduled for June 27). GDK API in poppler 0.16 is just a wrapper around the cairo one, so you can even copy and paste the code if you still need to render into a GdkPixbuf.

If you need help, feel free to ask anything in poppler mailing list or #poppler channel in freenode.

GTK+/MeeGo Handset integration: Week 2

First of all, thank you very much to all the people who gave me so useful feedback after my previous post.

The idea for this week was to start integrating the HildonPanneableArea code into GtkScrolledWindow, however both Chris and Karl emailed me suggesting to use a time based approach rather than the one used by hildon. Chris pointed me to MxKineticScrollView, which is the evolution of HildonPanneableArea. The code is much easier and cleaner than the hildon one, so I decided to use it instead.

One of the things that caught my attention was that MxKineticScrollView doesn’t need to synthesize events. This is because clutter implements capture and bubble event handling. GTK+ does always bubble so that events are propagated from child to parent. Having support for capture event handling makes the kinetic scrolling implementation easier and simpler, so following the same approach than clutter, I wrote an initial patch to add GtkWidget::captured-event signal.

Using the new captured-event signal, integrate the MxKineticScrollView code into GtkScrolledWindow was a bit easier. I still had to use an input-only event window, and grab the device on button press to make sure that motion and button release events were received on the scrolled window. It’s still far from finished but I have already published a work in progress patch and a new test to try it out.

During the next week I plan to continue working on kinetic scrolling, fixing issues and completing the implementation with the missing features.

GTK+/MeeGo Handset integration: Week 1

One of the main goals of the project is to improve the mobile experience in GTK+ by contribution upstream rather than creating another library. The Hildon library contains several widgets and features that could be ported or integrated into GTK+: HildonLiveSearch, HildonPannableArea, GtkEntry:hint-text property, GtkWidget::tap-and-hold signal.

HildonPannableArea

This is a scrollable widget, similar to GtkScrolledWindow, that allows the user to tap on any part of the widget and drag it. It also implements kinetic scrolling which is a feature currently present in most of the mobile platforms.

During this week I have focused on HildonPannableArea, trying to understand the code (there are several tricky parts) and thinking about how it could be integrated into GtkScrolledWindow. My initial idea was to port HildonPannableArea as a standalone widget deriving from GtkScrolledWindow, but there are use cases where switching between normal and touch mode makes sense, like with laptops that can work as tablets as Bastien pointed out. So, the idea is to integrate HildonPannableArea code into GtkScrolledWindow to add a kinetic mode. I started porting HildonPannableArea to GTK+3 and cleaning up the code a bit to make the integration easier. Next week I’ll focus on the real integration.

Cairo 1.10

Yes, it’s true, Cairo 1.10 has been finally released. Chris already summarized two years of development in 60 lines, so I’m going to talk about how this release affects to Evince/Poppler.

Blend Modes

Cairo 1.10 has some new operators inspired by PDF blend modes, that allowed us to easily implement PDF blend modes in the poppler cairo backend

PDF Blend Modes
PDF Blend Modes

Here is an example of a PDF document combining the use of Multiply blend mode with gradients

Scooby gradient rendered with Cairo 1.8
Scooby gradient rendered by poppler with Cairo 1.8
Scooby gradient rendered by poppler with Cairo 1.10
Scooby gradient rendered by poppler with Cairo 1.10
Scooby gradient rendered by xpdf
Scooby gradient rendered by xpdf

Blend modes are also important for annotations, since highlight annotations are usually implemented by using the Multiply blend mode

Performance

There were some PDF documents where the performance of the poppler cairo backend was really bad. It seems that, with such particular documents, poppler was clipping too much. Of course, Chris fixed it, see the screenshot:

Poppler with cairo 1.8 and 1.10
Poppler with cairo 1.8 and 1.10

Output file size when printing

Thanks to cairo_surface_set_mime_data now we can attach the original uncompressed image to the ps/pdf surface that will be used when creating the resulting ps/pdf file. It drastically reduces the size of the ps/pdf output files created when printing documents that contain images

Fit to contents/Trim margins

This hasn’t been implemented in Evince yet, but using the new recording surface we can get the page bounding box and use it to implement a new fit to contents zoom mode.

Thanks!

Thank you very much to everybody involved in this release

XPS Documents

I’d never heard about XPS format until someone filed a bug report asking to support it in Evince. It doesn’t seem to be commonly used, at least in the free software community, since there are just a few requests in bugzilla. However, I downloaded and read the XPS specification (thanks to Okular) just out of curiosity, and it sounded like something fun to implement. Taking advantage of the quiet summer days I started to write a library based on GLib/GObject and Cairo to render XPS documents.

Today, the library implements the minimum stuff to be able to read the XPS spec (rendering, outline and links) and I’ve added a new backend to Evince that uses it. There are still some known bugs and many things to do, but it’s possible to read quite a lot of XPS documents with Evince already.

XPS Specification in Evince
XPS Specification in Evince

Adding new annotations with Evince

I’ve finally added support for adding new annotations to Evince. At the moment only text annotations are supported and it requires poppler from current git master. There are still things to do, but the main functionality is working now. The idea is to add support for more annotation types (geometry, highlight, file attachments, …) during the next release cycle, since we are close to feature freeze. Click on the image to see a screencast showing how it currently works, you can add annotations from the side panel, change the default properties (author, color, transparency, icon, …), and save a copy that can be opened with any other document viewer that supports annotations like, of course, Acrobat Reader.

Evince annotations
(click to play back, ogg/theora, ~8,7M MBytes)

By the way

I'm attending GUADEC

libpanel-applet3

I’ve finally found some time to blog about this. The bonobo-less gnome-panel branch was merged into master, so since version 2.31.2 gnome-panel doesn’t depend on bonobo anymore. The API is mostly the same, but there are some minor changes since the old API exposed bonobo stuff. This of course means that applets need to be ported to the new API. There’s already a GNOME Goal with a porting guide, and I already ported most of the gnome-applets so there are a few examples too.

Why I can’t use GNOME Shell


GNOME Shell
GNOME Shell

This is GNOME Shell running without any other application running except GNOME System Monitor. The CPU usage is always around 60%, which makes the system unusable after a few minutes. I guess it’s actually an issue of the nvidia drivers, but the fact is that I can’t use GNOME Shell.

GNOME Panel
GNOME Panel

And this is GNOME Panel. Maybe I’m too used to it, but I really like the old panel approach, and my applets, specially the workspace switcher. I have never seen a better way to change between workspaces than the current workspace switcher applet, it’s fast and intuitive.

By the way, the screenshot shows a special GNOME Panel, it’s bonobo-free! A few years ago I already tried to port libpanel-panel from bonobo to D-Bus, but at that time breaking compatibility with bonobo applets was not accetable. Now we really want to get rid of bonobo in GNOME 3, and I’m not the only one who can’t use GNOME Shell, so GNOME Panel is not going to die in a near future. I’ve already proposed an updated patch for gnome-panel, the challenge now is porting all the applets which might be a new GNOME Goal.