RE: Display option in multiscreen (session management)

["JAYARAJ P R" <jayaraj rajappan wipro com>]

Hi,

Some of my thoughts are present inline.

> 
> 
> Here's one idea:
> 
> Have every application save its host name and $DISPLAY in new
> properties.  *Don't* use the environment.  (As I recall the list of
> properties for a client is extensible; we would simply define two
> more.)

I believe, we can change the environment itself to modify the DISPLAY
variable if required. For example, this would be needed when one particular
screen of the previously saved session is not available at the next login.

> 
> gnome-session would massage this data a bit before saving.  It would
> need to know how to parse all $DISPLAY values correctly.  We could
> then record whether an application was running on some remote machine
> (to address [1], at least eventually) and also what screen is used for
> display.  For instance, if gnome-session knows about "host:0.0" and
> the application sends ":0.1" and host "host", we would record that the
> client was running on screen 1.

I guess DisplayString(GDK_DISPLAY()) takes care of saving the remote "host"
and the DISPLAY.

> 
> When restarting a session, gnome-session would use the above
> information to set DISPLAY properly before launching each client.  (It
> would also eventually use ssh to launch in some situations.)  So in
> the above example if we restarted the session on host "foo", we would
> set DISPLAY=foo:0.1 before starting the client.

If we start a GNOME application on a remote "host" and do a logout after
saving the session, the application gets restored on the remote "host" at
the next login. This is taken care by the change to gnome-client.c proposed
in my previous mail.

> 
> If the saved session used multiple screens but only one screen is
> available now, gnome-session will start all applications on the same
> screen.  (Generalize this for the case where both are multi-head but
> the number of screens differ.)  In the above example this would mean
> we would use DISPLAY=foo:0.0 if foo had a single-screen display.

Agreed. All the applications previously present on the unavailable
screen should come up on screen 0.

> 
> gnome-session would also keep the old screen information around for
> when the session is saved.  That way we could keep round-trip
> capability.  So if we started a client using DISPLAY=foo:0.0
> (originally it ran on screen 1 though), and the client was still alive
> at the end of the session, we would save it as running on screen 1.
> Then if we went back to the multi-headed host, we would still remember
> to set DISPLAY=host:0.1.

If the user does a logout without saving the session, this would be
taken care since we do not update the session file. But, if the user
saves the current session, then i would assume he wants the current
setup to be restored at the next login. So i think remembering the
old DISPLAY wouldn't help if the user explicitly saves the current session.

> 
> If we see a client that doesn't set the hostname or $DISPLAY, we would
> just restart it on the default $DISPLAY.  This provides some support
> for non-aware (legacy) applications.
> 
> One open question is what to do when the $DISPLAY of an application
> has no relationship to what gnome-session sees.  E.g., gnome-session
> knows about "host:0.0", "host:0.1", etc, but the client is using
> "remotehost:0.0".  In this case we could simply preserve the
> application's $DISPLAY and hope for the best.
> 
> I don't think this is really that complicated to implement, and it
> preserves some nice properties, namely the ability to move a session
> around.  I know of at least one situation where this is actually
> useful: if you are a student and you want to use some machine in a lab
> full of machines, you can't predict which machine you might use on any
> given day.
> 
> Comments?
> 
> Tom
> 
> 
> [1] For instance, suppose I log into some remote machine and start an
> application there (say the application must run on the remote box).
> Right now we can't handle this, in part because we don't know the
> appropriate access method.  Assuming ssh is probably reasonable[2];
> the deprecated gnome-remote stuff was supposed to help us here (but
> never did).  (The various remote-program scenarios are probably not
> very important.  I don't remember ever seeing complaints about this,
> or actually wanting it myself.)
> 
> [2] BTW, right now I run ssh-agent in my .Xclients.  It would be
> convenient if this were just a config tweak somewhere in Gnome.

Please let me know if i'm mistaken.

Thanks,
Jayaraj