Re: Multi-head session management
- From: jacob berkman <jacob ximian com>
- To: Havoc Pennington <hp redhat com>
- Cc: balamurali viswanathan wipro com, "'desktop-devel-list'" <desktop-devel-list gnome org>
- Subject: Re: Multi-head session management
- Date: 02 May 2002 16:18:36 -0400
here is my proposal on how to handle multi-head session management for
GNOME 2.0. i think it makes sense.
i propose a '--screen' argument, parsed by the x11 gtk backend (or
libgnomeui, if we have to). this argument will override the screen
portion of the display name in --display or $DISPLAY. if XOpenDisplay()
fails with this screen, then the default --display or $DISPLAY is used.
gnome-client.c will automatically set this argument (like it does for
--sm-client-id) when you save your command line, so applications do not
need to worry about setting this; it will all be taken care of for them.
the session manager will not do any munging of $DISPLAY variables or
--display command line arguments.
we do not save/restore the whole display string, because this is a very
big can of worms. dealing (correctly) with things like network mounted
home directories and laptops moving between networks (home, office,
daily commute) are beyond the scope of what we can and want to get
working by GNOME 2.0.
this scheme also has the added benefit that it works out-of-the-box with
KDE, CDE, and xsm, on both the client and manager sides.
the key thing to remember here is that we are not breaking anything that
worked in 1.4, nor removing features. We are simply adding the ability
to work nicely with multi-head setups (which is originally what this
thread was about).
some (corner) cases and how we deal:
P1: user runs an app remotely, and it connects to our display using
an ssh tunnel (localhost:10.0) or normal tcp X connection
S1: the remote application can't connect to our session manager,
since we don't listen on TCP sockets by default (at least on linux -
might not be the case for solaris). Basically punt (this is the
same behaviour 1.4 has).
P2: user runs an app locally, displaying on a remote host.
S2: The app is added to the session, and will start up on the local
display next time. Basically punt (this is the same behaviour as
P3: user runs an app locally, with $DISPLAY set to :0.1
S3: gnome-client will add a --screen 1 argument to its restart
command. Even if it wasn't run with --screen it will know to
restart itself with that. This is a new feature and a win! Also
the case that we most care about.
P4: user runs an app locally, which can display windows on multiple
displays / screens.
S4: up to the app to get it to work (read: punt). this isn't going
to be something gnome 2.0 apps will be doing so not much of a
problem. This isn't even possible until gtk 2.2, so it's not a
regression. XEmacs doesn't even seem to handle this - i don't know
any other apps which do.
while in the long run i'd prefer a more display-oriented session
management scheme, i think this will work well for GNOME 2.0.
"don't get me wrong, i think that radiohead are amazing. i love their
music and i love their ethos, but that thom yorke guy always seems to
be complaining." -- moby
] [Thread Prev