This session was run by Pierre-Luc Beaudoin. Pierre-Luc said that this has feature been wanted for a long time and is just now coming to fruition. Emerillon is now available and in GNOME git. However, hostip just changed their API and, currently, the patch to fix geoclue's support for hostip's API hasn't been reviewed yet. (So geoclue is broken at the moment.)

Someone raised the issue of how security is managed in browsers and websites that request your Geolocation. Pierre-Luc said that a dialog will prompt you to send your location to the requester.

There was a question about what uses Pierre-Luc envisions. He said that the Contacts on a Map and geolocating Photos were immediate uses. Someone threw out that, later when social networking apps. are on the desktop, updating your geotag on, for example, Twitter, would be possible in an interactive fashion. (Mojito on Moblin was pointed to.)

Someone wondered what the format that comes from OpenStreetMaps is. Pierre-Luc said that it's currently tiles but there was a GSoC project to download the meta-data in raw XML format and render it via Cairo, locally.

There was a question about integrating with Google Latitude. Robert McQueen said that the Google API is rather backwards: you must constantly poke Latitude to get updates on your contacts.

A concern was raised about bandwidth needed and request sizes. Pierre-Luc said that OSM's servers are rather overloaded at the moment. Ted Gould from Canonical suggested pre-seeding the cache with all North American data, for example, for a netbook. There was a tangent about how much data you could download from OSM at once.

There was a question about letting Emerillon submit edits to OSM. Right now, a menu lets you open OSM in a browser and then edit the data.

Pierre-Luc demonstrated some some comparisons of OpenStreetMap to other online maps. There are lots of clear cases where the data in OSM is better. He demonstrated the integration of geographical data as well as public transit (mostly in Europe, right now).

He requests that everyone give Emerillon (http://www.novopia.com/emerillon) a try.

Colin Walters ran the session with a short introduction to what GOI is. He said that GObject was ripe for doing this to: the type system already had a lot of what was needed to reach the goal of making it a lot easier to script our C libraries. A few things were needed to get there, though, mostly annotations.

Colin demonstrated how to annotate your C libraries to make them accessible from GOI. This annotation data contains simple declarations of what, for example, containers are being passed around by your pointers and whether you, the consumer, need to unref. it when done. (Take ownership.)

When running the annotation parser, an XML file is written to a .gir; the gir is then compiled to a .typelib which is an efficient binary format containing the same information. These are the two parts work together to make a language binding work without any additional work on the part of the language binding.

GJS is already ready. PyBank is the GOI-based Python binding. It's fairly complete at this point--some call conventions had to be worked out for compatibility. Colin is of the opinion that the legacy bindings shouldn't be replaced: where the work was done by hand, it should stay. New bindings should use PyBank and PyBank was developed in a way that makes sure that calls compatibility is preserved between the old and new bindings.

There was a question about using GOI to make bindings to objects creating in another language: Gtk# objects, for example. Colin said this is really, really hard. There's the issue of two GC engines per process and memory management issues that seem unsolvable in a sane way.

Shaun asked about rebasing gtkdoc on top of GOI to better extract the metadata from these annotations. Colin is looking forward to this but some work remains to get to that point.

A tangent took off about moving the scanning in to a proper GCC compiler plugin related to GCC annotations. Colin was a little worried about what would happen when people try to use other languages.

Someone wondered about best-practices for writing an application to be prepared for polyglot programming: for example a game that wants to add a Lua engine for scripting. Colin said that you're 85% of the way there just by using GObject. Other than that, you don't need to do anything else: there's no need to break out in to a shared library.

Ryan Lortie began the session by giving everyone an update on the hallway-track discussion regarding the availability of DBUS access inside Glib.

He began with a brief history of some precursors: gbus (from two different people), eggdbus, and now gdbus. There's a lot of problems with these versions including leaking implementation details through the API.

The first step to sanity and what was agreed upon was to merge GVariant in to Glib. GVariant provides support for DBUS's data types. Second, libgio will link to libdbus1, possibly via a GIO module extension point. Third, some of the best parts of gbus and gdbus will be picked and merged in to GIO.

There was a tangent about implementation details regarding which pieces of each of the DBUS binding precursors to take implementation ideas from. Another tangent shot off of this between Robert McQueen and Ryan Lortie regarding the features that would be needed to obsolete all of the custom DBUS solutions out there. (This lasted a very long time without much conclusion.)

A critical feature was requested by Colin and Ryan agreed: this new binding needs filtering and path registration.

Emmanuele pointed out that a tangent related to this work would be to put libunique in GIO on top of this new binding since many applications will want that feature, anyway. There was agreement that this was a good idea.

Ryan then demonstrated writing code using GVariant. Much happiness ensued.

Ryan then switched the session to GSettings. He said that there is a lot of excitement about GSettings: there's a desire to also add it to GIO after GVariant is merged. He began the GSettings discussion by going over the GSettings API. Some highlights included atomic changed signals for all settings changed at once, rather than getting a bunch of signals for each setting. There is not yet a filter function that would allow inverting a value coming back from GSettings. (For example, allowing you to show the opposite value in a bound UI widget.)

There was a question from Colin about whether it would prevent recursion: it does.

Then, Ryan showed an example Vala program using GSettings. Mandatory setings are supported--during the widget binding step, sensitivity will be set to off if the key is mandatory.

He demonstrated the schema format underlying GSettings: it's a simple format supporting inheritance with a simple plain text format.

A side question was about how Sabayon could support this. Ryan replied that the method would be to monitor the root of dconf for events and capture them there.

Ryan switched to demonstrating dconf to replace gconf. He went over the API as it stands currently; it's simple.

There was a question about the case where a user has an UI open when a lock gets activated by a system administrator. There's no support for the notifying the UI that the lock has been activated while it's open. A tanget spawned about how a user could get admin. privileges from the UI; Ryan will be adding PolKit support soon.

Someone asked about performance. Ryan said it's 10-50x faster than gconf on reads. Ryan discussed some of the implementation details that made writes high-performance, as well.

There was a question about synchronization of writes to avoid a race in a reading application. The dbus writer process uses fsync() a lot but you don't care because it's not blocking your application.

There was some concern about multiple users using the same home directory (a coffee shop, for example). Ryan didn't think this would be an issue but it doesn't make sense to do this anyway; he couldn't think of any application that repositioned a window based on notification that the state stored in gconf had changed. But, he recommended doing what others are doing: clone the pristine home directory on login.

Someone asked about doing regression tests of applications by setting the proxy settings in gconf/dconf without affecting the user session. Ryan suggested doing a custom GSettings plugin that redirected the requests to a temporarily database.

There was a tangent about allowing launching applications via a dbus call. There was some thinking that this could be a good idea but that some work would have to be done to make sure that launching the application the traditional way would have the same kind of interface.

Ryan described the plumbing of the default database. A question related to this topic was about how to do distro. packager overrides of upstream defaults. Ryan suggested modifying the schema via a package patch rather than having vendor-specific defaults databases on the system aside from upstream's default database.

He returned to the benchmarks they've run. Another big win is that dconf is only running during the writing process--even then, the memory consumption versus gconf is an order of magnitude smaller.

There was a worry expressed about NFS home directories. Ryan replied that there is a bug because of fsync() but he's working on it, actively. It's going to be hard to fix but he's committed to finding a solution.

He's going to be putting the documentation on library.gnome.org. There will be some documentation on how to do module migration in the future.

Finally, he wanted everyone to know that they are working on a gconf to dbus bridge. It runs some simple applications right now but there are some serious problems to solve. Help is needed especially with this part.

Owen Taylor opened the session and then ceded the floor to Colin Walters to follow up on a point he made in the GObject Introspection session. He showed the internals inside of Mutter and how they become accessible to GJS/Javascript inside the GNOME Shell plug-in for Mutter. He then opened the interactive JavaScript console inside GNOME Shell and showed squishing the windows via global.get_windows(). He also showed using Looking Glass tool to inspect the stage, get a reference the the JS object associated with an actor and then change its properties.



Owen took over and showed how easy it is to take the property you just changed, change it in the code on-disk and then type 'restart' to reload the shell with your new code.

Jon McCann reminded Owen that they just landed CSS. Owen showed changing the CSS file for the calendar widget and then restarting the shell. Someone asked about theming; it will be supported in the future. Another person wanted to change the code on disk and then have that immediately reflected in UI. That's not going to really be possible and the complaints associated with restart taking too long will be addressed by speeding this up dramatically. The speed-up needs to happen for login time, anyway.

Someone wanted to know about Shell's CSS implementation and how the names are done. Owen stated that they wanted to stay as close to the behavior that you expect on the web to make it easier for new people to develop. In that regard inheritance of CSS properties is also supported in the Shell Toolkit.

Jason asked about encouraging web developers to come and develop widgets in the Shell and the possibility of them bringing their bad development habits with them. Owen replied that he doesn't really envision Shell as an application platform but for those who want to develop widgets that problem can be addressed with code style guidelines.

Accessibility was wondered about. Owen said that they are still at the state of really figuring things out. There are some core things that need to be addressed like, generally, making Clutter accessible. Once that's there--and the toolkit layer is there--there's really not that much going on in the Shell that a11y would need to be implemented for. Colin mentioned that a new magnifier inside Shell was being implemented.

Owen showed off using other units in CSS: em units instead of px. This is fully supported.

Someone expressed concern about using two toolkits in the same UI. Owen replied that there's only one example of that right now, the click menu for the Session menu. There's a hope that everything will be based on ST, in the long-run. A tangent to this discussion was how the notification tray works: it's a composite of GtkEmbed/XEmbed. Someone asked about Pidgin: in older versions of Shell it would show a gray background. They work around this Pidgin bug by setting the static background color to black.

Shaun McCance asked about using Shell Toolkit outside of Shell. Owen replied that he doesn't want ST used outside of Shell and really doesn't want to maintain a toolkit. Plus, ST is mostly NBT from Moblin. Some things will move down the stack in to Clutter, like layouts. He envisions a good toolkit for everyone to use in the future but didn't know what that would look like; he then looked to Emmanuele from Intel.

Emmanuele said that NBT is very specific to their user-interface guidelines for Moblin. When they see something generic enough for everyone, they intend to move that in to Clutter. Generally though, Clutter is going to remain very generic and not become a full toolkit.

The conclusion to this tangent was that--for now--use a mix and mash of Clutter when it makes sense. And there was a recommendation to not try to take ST out of Shell.

Someone asked about "Show the Desktop". That elicited a slightly sheepish response: they don't really know what to do about it yet. Right now, it sucks. If you accidentally click on the desktop and press delete, you delete a file. There's some thinking that showing the desktop at all is a bad idea. So, more discussion about this will have to take place.

The focus switched to web browser integration. Jon McCann took over, a critical point was how to manage tabs in applications at the window manager level. There's some application API needed to make this happen. And one problem to solve is how to make grouping makes sense. For example, GMail and the rest of your browsing don't really make sense to have in the same top level window together. There was some back and forth between Colin, Jon, and Xan (from Epiphany/Webkit) about how to make this work right.

Jon is aware that this is all a little in flux. Right now, Firefox 4 is considering making a "Home" tab that has a "journal" of your web activities. How would this fit at the top level window manager? There needs to be a more expressive API than just simply "a tab". Xan stated we also need to also find a way to handle people like himself that have as many as 50 tabs open at once. Jon agreed but also pointed out that--perhaps--there needs to be support for single-instance tabs. For example, you wouldn't want more than one instance of GMail open. Emmanuele described how Moblin handles this. Based on this discussion, it sounded like some of this should be solved by the browser.

Xan wanted to be able to filter all tabs at the level of the Shell to show and allow to pick the a tab from the Shell workspace overlay. Some thinking was that GtkNotebook could communicate this to the Shell. Owen describe a tangent design in which the search bar allows you to search window titles. This is a very early idea and it might be good to pursue.

There was a question about using Search integration with Tracker in parallel to the desire to allow tabs to be searched. Owen and Colin seemed to think that taking Tracker integration to that level is probably not something that they want to do in the Shell UI but they do think it's worth exploring how applications should behave when search results are selected. For example, whether it launches a new tab or brings the tab to the front that's already open.

Owen listed his short list of things to work on: messaging tray, application browsing in the "More" menu, recent documents is not optimal, more people-based results, fly-over pop-ups for more information, the sidebar, the application menu (on the top bar) and extensions.

Shaun said that a big prerequisite for a 3.0 release would be good documentation.

There was a question about what would be needed for 3.0-readiness. Owen replied that he sees the things that are needed are the short-list above, docs, and a11y. He sees a rocking experience as a major factor.

There was a question about moving a subset of the most critical panel applets over to Shell. Owen and Colin see this as a multi-faceted problem. Things like Keyboard Layout applet need to be first-class citizens. On the other hand, Deskbar could be solved by making the search field extensible. Other plugins, like a stock ticker, need to be sidebar things.

Shaun asked about Tomboy. Owen said that Tomboy could use the application menu in the application well as the entry point to provide a custom menu specific to Tomboy. Tomboy could also provide a search extension to display its notes in the search results.

That's it for GNOME Shell sessions!

Owen opened the session by demoing Splinter, the web UI for reviewing patches.

Owen went to Bugzilla, listed his open patches, opened the patch view, clicked a line of the patch, and added an annotation. The UI is intended to facilitate adding your own comments but also efficiently view other people's comments in-context.

It stores the results in a normal Bugzilla comment that's human readable but also parseable by the Bugzilla extension. While you are reviewing, it stores your work in DOM storage so that you don't lose it if your browser crashes.

Ryan Lortie said that this is totally awesome. Wide agreement. He also wondered if Owen intends to push it upstream. Owen replied that he doesn't intend to push it upstream but go about rather pushing it as an extension--especially to the Bugzillas he's forced to use.

Owen then switched to git bz, the git bridge to Bugzilla. This tool allows posting patches for review. It turned out that most people in the room had tried it and agreed it is awesome, so a demo was skipped. Owen wants to make it better at merging patches.

A side project that they were thinking of doing was creating a gnome-terminal plugin for a toolbar that displayed your git status, showing all branches and your status with regard to upstream.

Emmanuele was hoping for a branch-per-bug. Owen replied that Dan Williams was hoping for this, but this is hard because, for example, what happens when you `git bz pull` in this branch? Does it pull the current bug status?

Someone asked about pushing git bz upstream. Owen thought that this would never happen: git bz is in Python and upstream is C, Perl and lots of Shell.

And that's it for the Summit Sessions!

At this point, the rest of Summit is hacking with a Beer Summit at 8 PM. (Which I will not be giving the play-by-play of, hopefully. Okay, maybe on Twitter. Check out @gnomesummit!)