GNOME Shell getting involved, tech and Web Browser Integration
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!