It’s been a while since I’ve written on this blog, and a lot of things have changed in my life in the meantime.
April 12 was my last day working at Red Hat. It has been an incredible ride in these two years and a half, and I can say I enjoyed every single day on the job. The Desktop Team of has some of the most talented and passionate people I’ve ever worked with, and I’m so thankful for having been part of it and having learned so much.
All good stories come to an end though and after a not so easy decision, on April 29 I started my new job at Endless Mobile. We’re building an operating system to power computers in the developing world, and it’s going to be based on GNOME. It’s a very exciting job, and I moved from Boston to San Francisco a couple of weeks ago!
This also means that after some period of settlement (I haven’t found an apartment yet!) I will still be around in the community and resume my GNOME duties in some capacity
I can’t really give too many details about my new job just yet, but stay tuned!
I’m writing this post back home after a week in Brussels. I feel it has been overall a very interesting week; the hackfest has been great, and I really enjoyed the intense weekend of FOSDEM.
Following from my first report, I kept working in the Toolkit group for the rest of the time.
Quite some time was spent in a couple of all-hands discussions about choosing a recommended language for application development in GNOME; I’m really glad we were able to make a decision, and looking back at some of the code I wrote for GNOME in the last year or so, I think it’s the right one, and couldn’t be happier about the choice of JS. Travis did an awesome job explaining the reasoning behind this in his post, and I suggest you read it if you want to know more.
The rest of the time, we dived into some of the topics from the list we made initially; there were lots of conversations, but I think we had a very good start on at least two important topics:
it was great to see people interested in helping with the new notification API for GTK. We spent a couple of hours with Ryan and Lars (can’t find your blog, sorry!) fleshing out some of the details, and Lars already started writing code for the GLib part of the implementation, for which we settled on a GLib 2.38/GNOME 3.10 timeframe. A follow-up summary will be posted to gtk-devel-list soon detailing the changes from the previous draft, and we ideally will start porting core applications and testing the API in real world usage early next cycle.
with Jon and Alex we took a closer look at Tristan‘s EggWrapBox, which looks like a great start towards having a GtkIconView-like container for widgets (i.e. that doesn’t use cell renderers). After putting together a quick patch to allow height-for-width-based scaling in GtkImage we were able to get to our goal of having centered icons dynamically changing size and rearranging themselves together with the window. More time was then spent looking at the current EggWrapBox API, cleaning it and bringing it up-to-date to the GTK3 align/expand container flags design, and drafting a set of methods that could consistently work on both the wrap box and EggListBox. There’s also a very interesting overlap with Alberto‘s libmodel project, since the good ol’ GtkTreeModel might not be the best fit for this; unfortunately we didn’t have enough time to dive too much into the details of how that would work.
Further work on the other features we identified as interesting the first day is basically up for grabs, so if you feel adventurous and want to help improving our toolkit please get in touch with us.
I also suggest reading these other posts by Colin, Allan, Alex and Meg to find out what was discussed in the other groups.
This was my second experience with this great conference (first one was 2009), and I had a great time overall. I especially enjoyed the beer ^W the fact that the conference was spread out among more buildings than I remembered, making it possible to walk around the hallways without feeling oppressed by all the people squeezed in a tiny space.
I liked a lot Vincent’s talk about the GNOME community, and it was refreshing to see a huge number of people in the auditorium raising their hands on Vincent’s questions “do you love GNOME 3?”.
It was of course nice to hang out with friends and colleagues you only see once or twice an year, I wish we had more of this
I want to thank again the GNOME Foundation and Red Hat for funding my trip, and the people at the beautiful Betagroup Cowork space for hosting (for free!) the hackfest, you guys rock!
This week I’m attending the Developer Experience hackfest in Brussels. Our goal is to make it easy for developers to write applications for GNOME, identifying the problems or roadblocks and make our platform and documentation nice and attractive.
We had a very productive first day yesterday; after an introduction from Alberto we split into four groups, each to address and analyze different areas: Application distribution and sandboxing, Documentation, Toolkit and Development tools. You can find some information about what the various teams worked on from the main page.
One of the most useful features of GNOME 3 is the awesome “just type” search system. Being a heavy keyboard user myself, I just love the ability to hit and type what I’m looking for.
The results returned by the system are not limited to what GNOME Shell handles internally; since GNOME 3.4 third-party applications have been able to have the search string be forwarded to them and provide additional results, by implementing the org.gnome.Shell.SearchProvider DBus API. The Shell then uses the provided information and displays results in a grid view, which I’m sure you’re familiar with if you used GNOME 3.
In GNOME 3.8, scheduled for March, we want to make a step forward in making search even more useful, and add some missing features and bling in the process.
As presented already by Allan, Matthias and Bastien, the first piece of news is we now have a settings panel to configure search options.
Here’s a screenshot of the panel in action
The panel allows to control the presence of each application individually among the returned results, as well as toggling on and off application results from the Shell entirely; it also makes it possible to configure the order in which they are presented by the Shell.
Search locations configuration
The little gear icon in the toolbar would ideally pop up a search configuration dialog provided by the application itself, but since the infrastructure to make that possible is not there yet, right now it displays the dialog above. The locations there are those that will be indexed by Tracker, and you can add and remove them individually.
Shell Search Layout
The panel is not the only new feature; last summer Tanner Doshier worked on a relayout of how results are displayed in the Shell, based on these awesome mockups from our design team. Unfortunately his work didn’t make it in time for the 3.6 release, so this cycle I picked up his patches and brought them up to speed for inclusion in git master.
As you can see from the design page, changes are both visual and functional:
search provider results are now displayed in a list, for a better distinction between them and the application launchers.
the icon of the application is now displayed close to its result section: this is useful to immediately identify it in the list. Clicking it will launch a full search in the application itself, if what you’re looking for is not amongst the top results.
there’s now space for the search provider to show a descriptive string for each result, which can give more context as to why a result matters for the search string.
Most of this design is already implemented in 3.7.4, including the infrastructure to make it possible, but there’s still a lot of visual details to figure out and polish before the final release. In order to support the new search features, we introduced an org.gnome.Shell.SearchProvider2 DBus API. The Shell still supports launching providers implementing the previous interface, but of course those won’t get to use the new features (e.g. passing the search down to the application).
Some work also still needs to be done to nicely support highlighting the search terms in descriptive texts returned from search results. If you’re interested to help, feel free to get in touch!
Finally, I made a short video to showcase this feature – that is all code already in GNOME git. Enjoy!
Other peoplealready wrote some reports about the event, whose central part was a day trip to the City of Largo; the administration of the city has one of the biggest public GNOME deployments, with hundreds of users daily doing their work from SUSE-powered thin clients. For me it was a very interesting experience, mostly because I’ve never seen such a big GNOME deployment in reality, and being a developer, I am pretty new to this sort of systematic user testing.
We put together some transcriptions and notes from the interviews we did at Largo, which I now made available on the GNOME Wiki. I look forward for these being useful in improving the pattern language we use to design user interaction in GNOME, and in helping shaping the new HIG people have been working on for a while.
My most sincere thanks go to the sponsors of the event, without which all of this woudldn’t have happened.
By the way, this weekend I’ll attend the GNOME Boston Summit, where we are also hosting a set of sessions specifically for people who want to start contributing to GNOME. See you there if you happen to be in town!
Following up from Bastien’spreviousreports, GNOME 3.6 will ship with another whole set of new features for Wacom tablets support, thanks to the work of my colleague Olivier Fourdan.
Olivier demonstrating the new features.
A lot of work has been put in making the user experience flawless and working as expected with complex and multihead monitor layouts. In particular:
Wacom input devices coordinates are now automatically translated according to the monitor layout reported by Xorg (using XRandr). In a nutshell, this means that if you change display configuration or layout, and one of the displays is a screen tablet (or a tablet bound to a specific display), such changes are automatically propagated to the tablet pen devices, which will keep reporting the right coordinates.
Screen rotation is now correctly mirrored in the input device coordinates. Again, this is all automatically taken care for the user; for bonus points, the left-handed orientation flipping of the tablet, as set by the option in the panel, will be taken into account when rotating the input.
Related to these, we now have an option that allows the users to change how the screen aspect ratio influences the active input area on the tablet. By default, we map the whole input pad to the screen area, even in case they differ in aspect ratio; the new option allows instead for the active area on input pad to be cropped to the same aspect ratio of the display.
Last but not least, it’s now possible to map a “Switch Monitor” action to a device button, that is, to change the output a tablet is bound to on the fly directly from the tablet itself! This will make it very easy to do complex operations involving multiple monitors without having to go to the settings panel every time.
GNOME 3.6 hasn’t been released yet, but we’re already planning features for the next 3.8 development cycle. In particular, a great feature demonstrated in the video, which I’m really looking forward to, is the introduction of an on-screen-display showing the layout of the tablet buttons, and all the action shortcuts associated with them. As you can see, the OSD itself is multihead and left-handed orientation aware.
Thanks a lot to Olivier and all the other developers who made all of this possible!
Since my last post on the topic, GTK 3.4 brought in a lot of improvements, including among the others, support for most of the properties of the CSS3 backgrounds and borders family, linear gradients and the long requested inactive windows theming feature, which is showcased in GNOME 3.4.
In the meanwhile, work didn’t stop on the development branch of GTK, and Benjamin, after improving the performance of our CSS parsing/caching engine by a factor of 10 or so, implemented support for transitions. CSS animations are around the corner too, and GNOME 3.6 will make use of all this goodness for a look cooler than ever!
Another feature that will be in GTK 3.6 is support for multiple layers of background images for a single element, as specified by CSS3; in other words, where you could only render a gradient or a solid color before, you can now render an unbounded set of images and patterns. If you combine this with the other CSS3 background properties, and transitions, the possibilities of what you can do are basically endless! Code for this is already in the GTK master branch, so go grab it and play with it while it’s hot!
This is a video I made to demonstrate these new features, enjoy
Many people asked me at Desktop Summit about the work I’ve been doing recently on implementing the awesome Documents designs from Jon and Jakub; so here it is, I am very happy to announce the first release of GNOME Documents. Here’s the obligatory screenshot.
Some of the design features are already in place: searching, grid and list view, the Favorites and Shared categories, document preview, and opening in browser for Google documents.
Of course, on the other hand this is just the very first release of the project, so there’s a lot still missing and rough edges to be fixed. If you want to help, feel free to reach me on IRC!
Back in the GNOME 2.x days, device hotplug management was done entirely by Nautilus; you know, those dialogs that pop up when you plug your photo camera or your USB drive. This worked fine, as Nautilus was always running in the session, being it also the process drawing the desktop. The desktop itself provided a way to eject the devices, by right clicking on their icon and selecting the appropriate menu action.
In the 3.0 era Nautilus moved away from being a central component of the user experience, and if you used GNOME 3, you will have seen we actually dropped the desktop metaphor by default already; that unfortunately left us with no place to access the list of devices plugged into our machine; in fact, in 3.0 you have to open Nautilus manually to eject an USB drive. Also, the code for handling autorun notifications was moved to gnome-settings-daemon, which will trigger the old-style GTK+ dialog when a device is plugged in.
Clearly, we could do a lot better. A while ago I started a design whiteboard page to analyse the current state of the art in this area, and last week I finally sat with Jon thinking about the user experience we want to achieve here. You can read more about it in the tentative design section of the whiteboard page.
We decided to implement the feature with using notifications in gnome-shell
When a new device is plugged, the shell will trigger a notification (after having consulted the settings from the ‘Removable Media’ panel in gnome-control-center) containing a list of applications suitable for handling that device. This is similar to what we used to have in 2.x; if you plug in a blank optical disc, you will find “CD/DVD Creator” (Brasero) in that list, if you plug an iPod we’ll show “Rhythmbox” or your default music player, if you plug your photo camera Shotwell will be shown…you get the idea; you can also eject the device directly from the notification.
After you dismiss the notification, you will be able to access the list of your devices from the message tray, which will grow a ‘Removable Devices’ item as long as there’s at least one device connected to the system.
From this menu you can still activate the default autorun action by clicking on the device name/icon, or you can eject it, by clicking on the button on the right hand side. If the device cannot unmount, due to a file still open on it, we will show a nice dialog from where you can get to the application directly, or force unmount if you prefer.
One problem the 2.x implementation didn’t really tackle is what to do when generic drives (like, say, an external hard disk, or a random USB pendrive) were attached. I believe the default was just to run Nautilus in those cases, or worse, we would show a meaningless autorun dialog with no choices inside it.
In my new implementation, I wrote a small crawler program that gets DBus-activated by the mounter process (in this case the shell) and tries to gather as much information as it can about the content type of the files in the device. Of course, we don’t want to hammer your 2TB drive with a full scan, so the crawler has a hard time-limit not to do I/O for more than a fixed amount of time (I empirically found 1.5 seconds is a good value for this). The crawler doesn’t care about the specific mime type of the files (say, FLAC vs OGG) but rather what the file is about (say, Music vs. Video), so it will return a list of up to three “generic” mimetypes for the drive content, ordered by relevance; applications that claim to handle those generic mimetypes will appear in the notification. As a last fallback, if we don’ t have any of these applications available, we will show an entry to open the drive in Nautilus from the notification. This aims to integrate with the upcoming application design for Finding and Reminding.
I need to post my current iteration of the patchset for review, but I already have some further improvements and polish planned in the pipeline:
we need to handle password-protected volumes (e.g. encrypted USB sticks) directly from the notification, e.g. having an entry there to unlock the device directly
we probably want to show an entry in the device list if the laptop is plugged into a docking station. Clicking the eject button there would be equivalent to pushing the hardware button on the dock itself.
we need to find a good story for fallback mode. I think we can just keep the current gnome-settings-daemon plugin in place, and activate it only if fallback mode is detected, but this is currently not implemented.