Re: Display option in multiscreen (session management)
- From: jacob berkman <jacob ximian com>
- To: Havoc Pennington <hp redhat com>
- Cc: JAYARAJ P R <jayaraj rajappan wipro com>, desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: Display option in multiscreen (session management)
- Date: 29 Apr 2002 16:06:57 -0400
On Mon, 2002-04-29 at 15:40, Havoc Pennington wrote:
> jacob berkman <jacob ximian com> writes:
> > from reading the smlib docs, i got the impression that the session
> > manager shouldn't be doing anything to the data.
> > the client needs to be doing _all_ of this - if it was started remotely
> > it needs to tell the SM how to restart it remotely. if it used a
> > different screen, it needs to tell the SM how to restart it on a
> > different screen.
> > if gnome-session starts munging environment variables and command lines,
> > then the solution needs to be re-thought out, because we will break
> > other apps and won't work with other session managers.
> I don't see how we can do it entirely in the application, without
> forcing sessions to be specific to a particular machine.
i don't know how remote apps/multiple displays/differet users are
supposed to work either. that's why i think the whole SMlib is a load
but it's all kind of moot, as our session manager doesn't listen to
remote connections by default (and you have to read the code to figure
out how to turn it on).
and using DISPLAY isn't right either - you are really interested in the
*screen* not the display (:1.0 vs. :0.0).
so again, wouldn't adding a --screen argument (or env var) which
defaults to screen 0 if screen n didn't work be the right solution?
"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