Re: session manager help

[Mark McLoughlin <mark skynet ie>]

Hey Havoc, 
	I agree with your analysis of the problem, and at one point I was going
to try and seriously start working at some of those issues. Reality is,
though, I don't have the time either - gnome-session works "barely well
enough" that I couldn't really justify making it a priority.

	Anyway, don't let my purported "maintenance" of gnome-session stop
anyone. If someone else with the interest appeared I'd be absolutely
delighted.

	FWIW, it is actually a very interesting project ...

Good Luck,
Mark.

On Thu, 2003-04-03 at 15:05, Havoc Pennington wrote:
> Hi,
> 
> Some people are valiantly nursing gnome-session along, but we need
> some broader-scope session management love.
> 
> Some of the problems:
> 
>  - an absolutely essential feature we don't have is checking that the
>    user has a panel, desktop manager, and window manager, and making
>    sure they click all kinds of safety dialogs before we let them be
>    disabled permanently. A persistent issue seen on user mailing lists 
>    is "I lost my panel!" or worse, "I lost my window manager!"
> 
>  - gnome-session is simply flaky, and not robust against broken apps.
>    An example is
>    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=79829
> 
>    Another example is that it times out and kills apps if they take
>    too long to start up (currently that timeout is long, but then the
>    long timeout slows down login). I don't think we've had a Red Hat
>    release in recent memory without mysterious gnome-session bugs.
> 
>  - the startup programs / session management control panel sucks
>    mightily. "startup programs" is legitimate functionality but this
>    UI for it is awful. A nicer UI for it might even let you change
>    your window manager, desktop manager, etc.
> 
>  - the protocol between the control panel and the session manager is
>    plain old crackrock.
> 
>  - gnome-session doesn't provide adequate feedback about what's going 
>    on in various cases, e.g. if taking forever to log out it 
>    doesn't indicate which app it's waiting for.
> 
>  - gnome-session needs to be updated for standards compliance, e.g.  I
>    don't think the SaveYourself message is interpreted in the way that
>    Matthias Ettrich and I agreed to interpret it.
> 
>  - we need to be extending the SM properties to support things like a
>    human-readable application name and nice icon set as application
>    properties. This should be done correctly. ;-)
> 
>  - one of the properties to add is "I am the window manager" or "I am
>    the panel" so that we can generically check that you have a WM, 
>    instead of doing "if (strcmp (metacity))" type of stuff.
> 
>  - the login and logout effects could be more cool, and even
>    themeable. ;-) (OK, it's bloat, but it's the only fun feature in
>    here... ;-)
> 
>  - gnome-session is basically a nightmare to debug. e.g. xmms 
>    was broken and causing hangs on logout; using msm's logging
>    feature, I figured this out in 5 minutes, with gnome-session I
>    would have been inserting printfs for hours.
> 
>  - GnomeClient is kind of showing its age; we'd like to get an SM API
>    in GTK, and maybe simplify the API some and add some nice features 
>    in the process.
> 
> At one point I started the project "msm" in CVS to try to address some
> of this; gnome-session has come to suck somewhat less since I started
> msm, though the gnome-session code is still, well, not great.  msm has
> a TODO file that is a pretty accurate (and fairly short) list of what
> work remains to be done in order to try deploying it. msm also comes
> with a client-side API called "GsmClient"
> 
> I could probably finish up msm bulletpoints given a couple weeks. But
> what we really need is someone to babysit the session management
> problem for the long term, and I am trying to avoid owning more
> modules.
> 
> We don't need a lot of features here, or anything flashy; but it does
> need to work somewhat better than it does today.  We'd need someone
> who's willing to carefully read the XSMP spec and SM-related bits of
> the ICCCM and document any clarifications/extensions they make to
> those.
> 
> Don't think it matters if we base the work on gnome-session or msm or
> if someone wants to start over, as long as it gets the job done.
> 
> Anyhow: if you feel like you're careful and conscientous enough to
> work on a module that crashes the whole desktop when it crashes, and
> that needs to be standards compliant, race-condition-safe,
> asynchronous, handle all errors, do the right thing UI-wise, and
> generally done capital-C Correctly, this is a problem that's begging
> for you to step up and come to the aid of GNOME users everywhere. ;-)
> 
> If you aren't really the hard core Correctness type, there's a good
> chance of making gnome-session worse - the session manager is easy to
> get mostly working and hard to make robust enough to keep users from
> breaking it or seeing bugs "in the wild" with lots of random crappy
> apps doing broken things.
> 
> On the plus side, once the SM is working well I don't think it's *too*
> much ongoing effort. Featuritis would not be a virtue here.
> 
> Any takers? I'd suggest starting by reading the specs and looking
> through the gnome-session/msm code and either trying to fix some of
> the gnome-session issues or work on some of the msm TODO.
> 
> Havoc
> 
> 
> 
> 
>    
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list