Re: GNOME Summary, June 7-14

[jg pa dec com (Jim Gettys)]

> From: Havoc Pennington <rhp@zirx.pair.com>
> Resent-From: gnome-list@gnome.org
> Date: Thu, 17 Jun 1999 17:36:44 -0400 (EDT)
> To: Tony.Lill@ajlc.waterloo.on.ca
> Cc: gnome-list@gnome.org
> Subject: Re: GNOME Summary, June 7-14
> -----
> On Thu, 17 Jun 1999 Tony.Lill@ajlc.waterloo.on.ca wrote:
> >
> > Here's a question, how does one go about changeing the SM interface?
> > The problem that lead me into looking at the session manager is that
> > the session manager has no idea what host the client is running on.
> >
> 
> I guess you'd have to try to convince the X people to change it. It would
> be better to find a solution that doesn't involve changing it, or maybe
> add a KDE/Gnome extension (we've already added "priorities" so apps can be
> started in a certain order). If someone was serious about making SM work
> well they'd probably maintain a joint KDE/Gnome SM spec in addition to the
> gnome-session implementation, to describe any changes.
> 
> > IMHO, there should be an SM property that tells you the client
> > host. It would take about 6 lines of code to add it to libXt.a.
> > Now there is a function call, SMClientHost, that the spec claims will
> > give you the info. However, as implemented, it just gives you the
> > thing at the other end of the SM connection, which is always the X
> > server. The only way I can think of getting the client host is from
> > the window manager.
> >
> > Then there's the UserId property. The spec also says "On POSIX-based
> > systems this will contain the the user's name (the pw_name field of
> > struct passwd)." In reality,  on a local linux box it works, but on a
> > remote one, you get the uid number, making it useless for doing
> > something like "rsh -l username host cmd".
> >
> 
> Perhaps the SM spec people expected clients to track this info, and maybe
> register an rsh or ssh restart command if necessary? This is just a guess.
> 
> > Even more unfortunately, the window manager is the only thing that
> > could possibly do it properly. Think, for instance, if you login on a
> > display with a different geometry, or enlightenment, where, near as I
> > can tell, there is no way to start a client on any desktop but the
> > root one.
> >
> 
> The other problem is that even if WMs were doing things right, few apps
> set the class, name, and role hints properly to allow them to work.
> 

>From talking to Ralph Swick yesterday, I believe it likely there may be
some issues in the existing ICCCM session management specification.  As
gnome and kde are the first desktops to be pushing this hard, this isn't
too surprising.

At the X.org bof at LinuxExpo, I raised the flag that the ICCCM needed
work; they were receptive that that document needed work more urgently
than they had understood.  The first things to do are to understand what
problems remain with the exisiting specifications, and how to get them
resolved (and the specification  updated) in an interoperable fashion.
				- Jim Gettys