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
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!
Yes, GNOME 3.0 is out, congratulations to everyone involved. Watch the videos of GNOME 3 made by Jason Clinton, or even better, try it out now with the live CD/USB.
But there’s more:
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.
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.
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.
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.
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.
I’ll be on vacation for the whole week
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.