[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: multi-head
From:       Stefan Taferner <taferner () salzburg ! co ! at>
Date:       1999-07-02 6:58:47
[Download RAW message or body]

On Fri, 02 Jul 1999, Cristian Tibirna wrote:
> On Thu, 1 Jul 1999, Stefan Taferner wrote:
> 
> > Is it two different DISPLAYs, or is it one big virtual screen that resides
> > on two monitors?
> 
> It's not the first, it could eventually be the second (X11R6.4 introduced
> an extention called Xinerama that does exactly this). But what I'm talking
> about is two screens (displays) showing different things but pertaining to
> the same X11 DISPLAY thing. That means, screens are children objects of
> the DISPLAY and run separately but can communicate (more directly that
> distinct DISPLAYs).

Ok, so we have two SCREENs (speaking in X terminology) and only one
DISPLAY. 

Interesting thing. Does this actually work with applications?

Whenever I have written apps that use X functions rather directly, I used
the default screen of a display. This would mean that each new window
would pop up on the default screen and not the one the main app window is
currently on. This probably looks strange, as one would expect that the
new windows (and dialogs) open on the screen the app is on. Hmm...

> > > How kpanel content should be managed on a multi-head system? A single
> > > instance simultaneously displayed on all the screens? A different (icon
> > > layout) configuration on each screen (I'd find this confusing)?
> > 
> > Or one kpanel on the leftmost / rightmost / wherever screen?
> 
> No, the position, layout etc would surely be saved on per-screen basis (or
> even per virtual desktop). I mean, the icons contained in the panel should
> be the same all over the screens or should it be different? Or should
> panel be ran per-screen at users' will? (thus eliminating the need of
> multihead support on kpanel altogether)

IMO there are two possible behaviours:

* the same panel on all screens
* a different panel per screen, maybe even the panel only on one screen.

The first one is easier to implement I think.

--Stefan

[prev in list] [next in list] [prev in thread] [next in thread]