notion-devel

[Notion-devel] Multihead expectations

[Arnout E. <no...@bz...>]

Hi,

How would we expect multihead to work?

A proposal as a starting point:

- When multiple monitors are found, one WScreen is created for each 
  non-'mirrored' monitor.

- When 2 monitors are acting in 'mirrored' mode (i.e. showing the same 
  contents), 1 WScreen is created to cater to them both. When they have
  different resolutions, the WScreen is as high as the highest monitor and
  as wide as the widest monitor.

- When WScreen 1 is on monitor A and WScreen 2 is on monitor B, and the
  relative locations are changed (monitor A moves from being left of monitor B
  to being right of monitor B), what should happen?

The latter is not an obvious choice, I think it would make sense to keep 
WScreen 1 on monitor A and WScreen 2 on monitor B. This way it's really just
the relative locations that change and not the contents of the windows. As an
additional plus, the WScreens don't have to be resized as long as the monitors
don't switch resolutions.

What do you think?


Kind regards,

Arnout

Re: [Notion-devel] Multihead expectations

[Javier R. <jer...@de...>]

On Thu, Mar 31, 2011 at 11:27:37PM +0200, Arnout Engelen wrote:
> Hi,
> 
> How would we expect multihead to work?
> 
> - When WScreen 1 is on monitor A and WScreen 2 is on monitor B, and the
>   relative locations are changed (monitor A moves from being left of monitor B
>   to being right of monitor B), what should happen?
> 
> The latter is not an obvious choice, I think it would make sense to keep 
> WScreen 1 on monitor A and WScreen 2 on monitor B. This way it's really just
> the relative locations that change and not the contents of the windows. As an
> additional plus, the WScreens don't have to be resized as long as the monitors
> don't switch resolutions.

Thw WScreens should be swapped. Otherwise the relative location change
would go unnoticed by the user (who either caused that change on purpose
and expects the screens to swap, or got that screen swap unvoluntarily
and should be notified), and stuff like mappings to change screen would
get its semantics reversed.

> What do you think?

^^^^

:D

-- 
Javier Rojas

Re: [Notion-devel] Multihead expectations

[Arnout E. <no...@bz...>]

On Fri, Apr 01, 2011 at 12:12:13AM +0200, Javier Rojas wrote:
> On Thu, Mar 31, 2011 at 11:27:37PM +0200, Arnout Engelen wrote:
> > - When WScreen 1 is on monitor A and WScreen 2 is on monitor B, and the
> >   relative locations are changed (monitor A moves from being left of monitor B
> >   to being right of monitor B), what should happen?
> > 
> > The latter is not an obvious choice, I think it would make sense to keep 
> > WScreen 1 on monitor A and WScreen 2 on monitor B. This way it's really just
> > the relative locations that change and not the contents of the windows. As an
> > additional plus, the WScreens don't have to be resized as long as the monitors
> > don't switch resolutions.
> 
> Thw WScreens should be swapped. Otherwise the relative location change
> would go unnoticed by the user (who either caused that change on purpose
> and expects the screens to swap

It would not go unnoticed: the mouse pointer would be moved from monitor A to 
monitor B by moving it off the other edge of monitor A.

I think you change the relative locations of screens when their physical 
relative locations change. In that case it does make sense to keep windows 
that were on physical screen A on physical screen A.

> or got that screen swap unvoluntarily and should be notified), 

Does that ever happen in reality?

> and stuff like mappings to change screen would get its semantics reversed.

I'm not sure what you mean here?


Arnout

Re: [Notion-devel] Multihead expectations

[Arnout E. <no...@bz...>]

Hi,

Thanks to some research by Tomas in https://sourceforge.net/tracker/?func=detail&aid=3262753&group_id=314802&atid=1324528
I found out about the 'primary' concept in RandR 1.3.

This seems to be a useful concept to piggyback on: the 'primary' screen 
should always hold the same WScreen. This gives the user some control over 
whether to swap WScreens: if he wants the WScreen to move to another monitor,
he can simply make that other monitor 'primary'.

This has the added advantage that the information which screen is 'primary' 
is also exposed through the Xinerama interface. To allow some graceful 
degredation, we should try and use the Xinerama API as much as possible for
the multihead code: RandR will continue to expose its information through this
interface.


Arnout

On Fri, Apr 01, 2011 at 01:01:13AM +0200, Arnout Engelen wrote:
> On Fri, Apr 01, 2011 at 12:12:13AM +0200, Javier Rojas wrote:
> > On Thu, Mar 31, 2011 at 11:27:37PM +0200, Arnout Engelen wrote:
> > > - When WScreen 1 is on monitor A and WScreen 2 is on monitor B, and the
> > >   relative locations are changed (monitor A moves from being left of monitor B
> > >   to being right of monitor B), what should happen?
> > > 
> > > The latter is not an obvious choice, I think it would make sense to keep 
> > > WScreen 1 on monitor A and WScreen 2 on monitor B. This way it's really just
> > > the relative locations that change and not the contents of the windows. As an
> > > additional plus, the WScreens don't have to be resized as long as the monitors
> > > don't switch resolutions.
> > 
> > Thw WScreens should be swapped. Otherwise the relative location change
> > would go unnoticed by the user (who either caused that change on purpose
> > and expects the screens to swap
> 
> It would not go unnoticed: the mouse pointer would be moved from monitor A to 
> monitor B by moving it off the other edge of monitor A.
> 
> I think you change the relative locations of screens when their physical 
> relative locations change. In that case it does make sense to keep windows 
> that were on physical screen A on physical screen A.
> 
> > or got that screen swap unvoluntarily and should be notified), 
> 
> Does that ever happen in reality?
> 
> > and stuff like mappings to change screen would get its semantics reversed.
> 
> I'm not sure what you mean here?
> 
> 
> Arnout
> 
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself; 
> WebMatrix provides all the features you need to develop and 
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> Notion-devel mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-devel