Sunday was dominated by informal discussions in the hallway. Among other things, I got to see a demonstration of bonds, vlans and other ‘exotic’ network configurations in the network panel and the shell network indicator.

But we also had number of breakout sessions on individual topics: GTK+, epiphany, multi-monitor, sandboxing, and maybe one or two more that I can’t remember now. I’ve participated in the GTK+ and multi-monitor sessions.

GTK+

This session was focused on discussing features that people would like to see in GLib and GTK+, with sometimes extensive discussion about the pros and cons and implementation details.

For GLib, Ryan presented a long list of things that he would like to see

• ‘Native’ thread operations: This is about reimplementing GMutex and GCond on Linux with futexes and atomic operations instead of relying pthreads. The hope is to end up with a faster and more performant implementation.  Targeted for 2.36
• epoll support: Using epoll in the GLib mainloop is a long-term goal. As a step towards that goal, we may introduce api in 2.36 that lets  sources forego the prepare() and check() stages and instead use a precomputed timestamp.
• Remove dynamic types: Unloading types when a module is unloaded is a nice idea in theory, but has never worked well enough to justify the complication it forces on GType. In practice, everybody makes their modules resident. Not clear if we will do something about this for 2.36.
• Remove dynamic interfaces: It is generally considered a mis-feature of GType that one can add interfaces to a class after class_init. Removing this feature would again allow us to simplify gtype.c, and it is not something that is actually used. The plan we’ve agreed on is to add an assertion in this code path for this development cycle (it will be reduced to a warning in the stable 2.36 release), and remove the feature in 2.38.
• Fix g_signal_connect_object(): We will finally fix this 10 year old bug this cycle.
• Reversible: Ryan explained this idea that he already outlined on the mailing list. The discussion was inconclusive; both Dan and Stef pointed out the problems with such implicit, context-based APIs, and cited default thread contexts as an example that has caused problems in practice.
• Implicit g_type_init: We are already doing an implicit g_thread_init(), using constructors. Ryan wants to extend this to also call g_type_init() automatically when a program is linked against libgobject. Not much discussion around this; nobody could come up with an example where you would need to delay g_type_init() to do something else first.
• Cleanup at exit: Freeing all memory allocated by GLib would benefit people who are using valgrind to find memory leaks in their applications. Stef pointed out that a common desire is to run test suites under valgrind. The reason that we’ve not done this so far is that it is a hard problem. This became clear as wediscussed the possible approaches. It will be easy to get this done for libglib; libgobject is much harder. One thing Owen mentioned is that in the meantime, we could just improve our documentation about memory management and write up some best practices for dealing with memory leaks.
• GTask: This is #661767. Dan will land it this weekend.
•  GProperty: This is currently stuck; somebody to pick it up again since Emmanuele doesn’t seem to have the time to finish it.
• GDateTimeSource: Ryan explained this as a special-purpose GSource that gets dispatched at fixed intervals (e.g. every full minute), and also takes discontinuities (such as clock changes, timezone changes, DST) into account. This functionality is currently provided by GWallclock in libgnome-desktop. It be too specialized for GLib, we didn’t reach a conclusion about it.
• GSettings list: We have a branch that has the necessary API, and would really like to get this in 3.8. It needs to be landed in sync with dconf, since it requires changes of the GSettingsBackend API. This currently holds up the merge, since we also need to update the OS X and Win32 backends. It would be fantastic if we could find volunteers to do this work (and maybe maintain these backends, going forward). As Ryan said, having native backends for all major platforms is a selling point for GSettings, and we should not regress here.
• GSubprocess: This is in the final stages of review between Ryan and Colin, and will land soon.
• Unicode 6.2 support: Ready to land.

For GTK+, the list of discussed features wasn’t quite as impressive (we were over the 2 hour mark at this point).

• Paint clock: Owen is fairly confident that we can sort out api questions; we need at least some proof-of-concept implementations for Windows and OS X, Wayland should be easier. Owen mentioned ‘a month’ as an estimate for merging this.
• Actors: Benjamin explained his plans for this:
  • add a lookalike of ClutterActor to GTK+
  • keep it private for now
  • start converting widgets one-by-one. The progressbar is good starting point, since it has no event handling, and its drawing is complicated enough to make it interesting
• Accessibility: API brought up that people have been asking for a way to subclass gtks accessible implementations. We had kept these private because we wanted to make more changes such as porting the iconview accessible to use cell accessibles, and moving away from atk and instead implement D-Bus interfaces directly in widgets. The outcome of the discussion was that these changes are likely never going to happen (the current a11y seems to work well enough that nobody is willing to invest into these larger-scale refactorings). Therefore, we should clean up the gtk a11y headers, and expose them. Before running out for lunch, the discussion moved on to one other cleanup task in the a11y area that hasn’t happened: getting rid of key snooping. Joanie explained why orca needs to filter key events (to add useful extra navigation, such as ‘h’ to go to the next heading in a browser). We discussed possible ways to implement this outside the client, using passive grabs – but of course you don’t want to grab the ‘h’ key, that would make it hard to write text… I pointed out that input methods currently also use key snoopers, because they want to get at all key events. This is bug 90082.

Multi-monitor

The multi-monitor session was quite different. I brought an external monitor, and we huddled around my laptop, taking lots of notes about issues we saw. All those notes are with Allan, who can hopefully put them on the wiki soon. Until then, here’s what stuck in my memory:

• The transition from plymouth to the login screen is really bad. This is not specific to multiple monitors, it is always bad 🙁 The progress in plymouth is not really useful nowadays, since the part of the boot that is covered by it has gotten so fast that it is dominated by the wait for the login screen – and we have no progress there, except for the ugly wait cursor. The pointer should be hidden until it is moved.
• On the lock screen, monitors should have independent shields, so that lifting it on one monitor does not cause activity on the other one.
• The on-screen keyboard needs to appear on the monitor where the focus is. Currently, it just always appears on the primary monitor.
• Windows should be centered if there is not enough free space to place them.
•  Side-tiling should work differently at the shared edge between two monitors.
• The difference between maximized and fullscreen is not very clear on non-primary monitor. We should have more uniform behaviour and controls for fullscreen windows.
• In the overview, starting a drag on one monitor makes windows jump on the other monitor, which is unexpected.
• The display panel needs lots of love:
  • we should drop the confirmation dialog; nowadays, we can find out if a configuration changed worked or not, and can revert without asking the user.
  • dragging monitors needs to be keyboard navigatable
  • there should be a non-DND way to change where your top bar appears
  • no need to show monitor labels when cloned
  • monitor labels did not update when un-cloning
  • ‘Laptop’ is not a good name to use here

We also briefly talked about how multiple regular monitors are different from laptop+projector.

Today we’re going to talk about authentication, CIFS and other enterprisey stuff.