RE: Multi-head session management

["Balamurali Viswanathan" <balamurali viswanathan wipro com>]

We have implemented the below proposal, the modules affected by this
proposal are

1. gtk+/gdk/gdk.c (81145)
2. libbonoboui/bonobo/bonobo-ui-init-gtk.c (81148)
3. libgnomeui/libgnomeui/gnome-client.c (81150)

Bugs are created for each of the above modules and the patch is uploaded
The numbers in brackets is the bug id against which the patch for the
rrespective modules are uploaded

Please review the same

Thanks,
Bala

-----Original Message-----
From: desktop-devel-list-admin gnome org
[mailto:desktop-devel-list-admin gnome org] On Behalf Of jacob berkman
Sent: Friday, May 03, 2002 1:49 AM
To: Havoc Pennington
Cc: balamurali viswanathan wipro com; 'desktop-devel-list'
Subject: Re: Multi-head session management


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
    (hostname:0.0).

    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
    1.4 has).
    
    
    
    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.


jacob
-- 
"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 _______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list