blog/2008

Recent window managers have a feature called "focus stealing prevention", which is wonderful in theory. But in practice... well, do a Google search, and see how many people don't like it. The problem is that it's a whole bunch of guesswork, and so it may cause problems when it guesses wrong.

Take, for example, GNUstep applications. GNUstep applications have their menu in a separate window (like on MacOS X), and the menu disappears when the application is inactive. If the application has no other windows, then it tries to give focus to the menu. But then focus stealing prevention kicks in and takes away the focus. The application then detects that it lost focus, deactivates itself, and hides the main menu, making it hard to interact further with the application.

That was the cause for one of the window focusing issues that I was looking at for my GSoC project.

So how do you steal focus and get away with it? Simple: ask nicely first, before you steal. The EWMH spec has an atom called _NET_ACTIVE_WINDOW, which allows windows to request focus. It turns out, if I use that, then steal focus, then the window manager will let me.

However, KWin/KDE (or at least some versions of it) needs a bit more coercing, and we need to set _NET_USER_TIME, while _NET_ACTIVE_WINDOW doesn't seem to do anything.

The final solution:

• set _NET_USER_TIME property
• send _NET_ACTIVE_WINDOW message
• call XSetInputFocus

Finally, after prodding the release managers, we've received the go ahead to start the GNUstep transition. GNUstep gui is still stuck in the NEW queue, after originally being REJECTED due to a silly licensing issue. So, hopefully the Debian ftp-masters will ACCEPT gnustep-gui soon, all the GNUstep packages will get rebuilt quickly, and maybe we'll have a GNUstep release in Lenny that's less than a year old. <crosses fingers> The freeze for libraries was supposed to happen already. I hope they'll hold off until GNUstep goes through.

Almost all the packages have been uploaded. Now we're just waiting...

P.S. We promise that this transition will be much less painful than the last GNUstep transition.

update: gnustep-gui has just been ACCEPTED.

As part of my GSoC project, I've been tracing through GNUstep's event handling to see how events from the X window system become OpenStep-style events. Here is a brief outline. (Non-technical readers will want to stop reading around here, if they haven't stopped already.)

First of all, the X window system communicates with applications using a socket (just like pretty much everything else in UNIX-land). GNUstep's X11 backend opens the socket, and transforms the socket into an NSFileHandle, and registers it with the GNUstep runloop. When new data is available on the socket, the runloop calls the backend's callback function, the -[XGServer processEvent:] (private) method in XGServerEvent.m. The -processEvent: method has a huge switch statement to determine what type of X event it received. It then (if necessary) creates a NSEvent, and sticks it on the GNUstep event queue.

GNUstep's runloop then picks up the event from the event queue, and then dispatches it to NSApplication through its -sendEvent: method, which basically forwards it to the window's -sendEvent: method. -[NSWindow sendEvent:] method also has big switch statement depending on what type of event it is. But this time, it uses NSEventTypes instead of XEvent types.

Aside from some simple filtering, -[NSApplication sendEvent:] doesn't modify the NSEvent at all. So, to figure out how an XEvent is handled by GNUstep, look for the appropriate branch in -[XGServer processEvent:], and then figure out what type of NSEvent (if any) is generated. Then look at -[NSWindow sendEvent:], to see how it gets handled (unless it's an NSKeyDown event, which may get sent to the main menu or the key window first).

My application for Google's Summer of Code 2008 has been accepted. Basically, this means that Google will be paying me to program for the summer. (It also means that I better have my thesis more-or-less done soon, so that I'll have time to work on it.) Guess which tan line I will have at the end of the summer.

According to the official timeline, I'm supposed to start working on May 26. I'll probably do some setup and background work before then, though.

While I had been interested in Google's Summer of Code since it began, my school schedule (grad school at Waterloo means no summer break) prevented me from participating. This year, though, it seems like perfect timing for me, since I should be finishing up most of my work on my Ph.D. soon, but won't have a job yet (anyone want to hire me?).

The project that I'll be working on is improving GNUstep's integration with other desktop environment. GNUstep is an implementation of the OpenStep API, which is what is used by Apple's MacOS X. GNUstep doesn't (yet) have the glitz of MacOS X (although hopefully that will change, maybe with the aid of another GSoC project) but it is a very powerful and flexible system.

One of the problems of GNUstep, though, is that it doesn't quite cooperate as well with other *nix-based desktops, such as GNOME or KDE as it should. freedesktop.org was created to create standards and software for the *nix-based desktops so that they would all be able to cooperate. My project will focus on getting GNUstep to adhere to as many of the standards as I can.

A preliminary list of the ones that I'll be looking at (in approximate order that I'll be working on them) is:

• there are some window focusing issues that need to be fixed
• EWMH hints
• XDND
• startup notification
• XEmbed client support (so that GNUstep windows that are embedded in other apps follow the XEmbed spec — XEmbed embedder support would probably go in an extension)
• System Tray (requires XEmbed client support)
• gstreamer (for NSMovie, NSSound?, and related classes)
• avahi (implementing Apple's NSNetService API)
• .desktop file support (reading, and improved writing)
• icon naming (so that GNUstep can share icon themes with other desktop environments)

Of course, this list is subject to change. There are a lot of other standards that I could work on. It will all depend on discussions with my mentor.

Stay tuned for more updates.