XfceSMClient design

[Brian J. Tarricone]

On 08/20/2009 12:24 AM, Nick Schermer wrote:
> I think the implementation in Gtk with be close to QT (and IIRC apple
> too): an application class [1] with signals to save the state and quit
> and an object for more session specific actions (if there will be
> one). So whatever we do with a single session object, it will most
> likely never be close to the implementation in gtk.

Ah, duh, I totally forgot about that.  They'll probably do a
GtkApplication class or similar and make session management/state saving
work semi-transparently through that.

> So I'd say, make a gboject that works for us and don't bother about
> Gtk. We can keep the implementation in a private library for as long
> as we want.

Well, I was hoping that we wouldn't make it private.  Apps like mousepad
would probably want to use it, for example.

> A good start would be a wiki page with the
> session-requirements of various applications (ranging from the window
> manger, panel, file-manager and terminal), we can most likely split
> those in 2 or 3 groups. Then we can figure out which signals/functions
> are needed. From that point we can design an api and if we all agree
> on that, write the code and use it for as long as possible until the
> world decided how session management will look like and maybe they
> will even look at our implementation.

Or I can just write it and we can change the API before we release it if
there are issues.  I want to get this done by the middle of next week,
and all this planning and design crap for something relatively simple
and throw-away is excessive.  The lack of this is blocking libxfce4ui
porting in xfdesktop, which I was hoping to have done *last* week.

	-b