David Zeuthen wrote:
[...]
>>interface GdkSession {
>> signal "online-changed"
>> signal "screensaver-changed"
>> signal "idleness-changed"
>> signal "logging-out"
>>
>> /* plus getters for all those states */
>>}
>>
>>GdkSession* gdk_display_get_session(GdkDisplay *display);
>>
>>This seems to cover lots of the issues raised. It would obviously have
>>platform-specific backend, which could be dbus, or anything else that works.
[...]
> Some history though; the existing interfaces have evolved a bit from
> their initial conception - there are (good or bad) reasons they are a
> bit more complicated (e.g. cookie passing) than the simple interface you
> outlined above, Havoc.
>
> For example, while it's cute just having the "logging-out" signal it's
> racy as hell... if you're interested in the user logging out, it means
> you are interested in saving some state or whatever. Thus, you need a
> mechanism for delaying (up to a certain amount of time) the logout
> procedure. There's also stuff like priorities - you don't want your
> per-session VPN connection to go down before your word processor have
> saved the document to the corporate file share. Things like that, doing
> things correctly without races is just hard.
While inter-application dependancies might be harder to track, I would
assume that a "logging-out" signal would simply block, for examlpe - whoever
is responsable for closing the session (window manager I guess ?) must
broadcast _blocking_ messages to all applications - internally gtk+ can catch
this and emit a "logging-out" signal on all GtkSession objects and only
return from the blocking call /after/ emitting the signal - no races in sight.
Whether the ipc is passing cookies or using fancy techniques to implement
a simple blocking IPC routine is an implementation detail I wouldnt expect
to show through the gtk+ api.
Cheers,
-Tristan
_______________________________________________
desktop-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
