RFC: FULLSCREEN_MONITORS property

[David Trowbridge]

Some of you may have noticed my cry for help on planet gnome
(http://david.navi.cx/blog/?p=131).  After spending some more time
getting particularly frustrated trying to work around individual
window manager implementations, I finally worked up the courage to try
implementing this as a hint.  Kudos to the metacity developers for
having a slightly-more-documented-than-usual codebase.

My preliminary implementation is at
http://bugzilla.gnome.org/show_bug.cgi?id=414476

I'm writing here to solicit comments on my chosen implementation.
What I've done is to create a new hint, which I'd personally name
_NET_WM_FULLSCREEN_MONITORS (though I honestly don't care what it's
called), which has a list of integers.  These correspond to the screen
numbers in a xinerama configuration.  The window manager is expected
to place a window over the union of these screens.  On a two-head
system, specifying [0,1] would give a single window across the entire
desktop area.  On a three-head system, it would cover two of the three
heads.  Setting a single screen index will place the window on that
screen, regardless of where the window's saved coordinates are.

This property has no effect if the window is not fullscreen.  If a
window goes fullscreen without this hint, it works exactly as before.

As I stated in the bug report with the patch, I'd love to get a
standard agreed upon in the next month or so, to ensure that I can
turn on conditional support for this so our capabilities improve as
people upgrade to new WM releases.  It's highly likely that after WS6
is released, we'd be able to get some developer resources towards
implementing this for a number of other popular window managers, since
it really improves our fullscreen experience (in case people have
concerns about implementation).

-David
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Havoc Pennington]

Hi,

Here are a bunch of questions ;-)

First, a background point. Owen and I had a long thread with Kevin
Martin a couple years ago (which was in private mail I think,
unfortunately). Anyway, the claim I was making then was that Xinerama is
overloaded to mean at least two things:

  a) "I have one big monitor that happens to be made up of multiple LCD
    panels / CRTs" - e.g. a video wall, is the extreme case
  b) "I have two monitors and wish to be able to move windows between
    them" - most commonly a plain dual-head or triple-head setup

When we talk about "Xinerama support" in the window manager and widget
toolkit, normally it means to act as if Xinerama is case b). That is,
the WM will do things like interpret FULLSCREEN as for only one monitor;
put DOCK windows on only one monitor; maximize to only one monitor; and
so forth.

All of this "Xinerama support" is busted if we are really in case a).

Anyway, my claim at the time was that X should just claim to have a
single monitor in case a), that is, apps have no interest in the
Xinerama info in case a), because the multiple monitors are really a
hardware implementation detail and not of interest. But at the very
least, we might want some kind of global property (set by e.g. the
desktop environment) that would tell the WM and the toolkit to ignore
Xinerama.

So second, why does FULLSCREEN go to only one monitor; it's because
we're in case b), "Xinerama support," and assuming that the two monitors
are supposed to be more or less separate. Common use-cases here include
having a status display such as a bunch of stock tickers or server
status readouts on one monitor and having your email/etc. on the other,
or just having email/web on one and programming on the other, or whatever.

Third, what is the case with VMWare? I'm guessing VMWare is totally
weird in that it's essentially doing hardware configuration - assign one
monitor to the VM and another monitor to the host, or something? Maybe
you can walk through the rough use-case and what your configuration GUI
for this might be like.

I'm having trouble thinking of something other than VMWare that might
want the hint you proposed, is why I'm calling it weird... doesn't mean
we can't do this hint, just that we shouldn't overload it with other
user-cases that aren't the same.

Fourth, excluding VMWare, what hints are missing...
we could add _NET_WM_FULLSCREEN_ALL_MONITORS or something, but I think
that might be wrong. It might be more correct to implement a property,
to be honored by both WMs and toolkits, that essentially says "ignore
Xinerama, this is case a) not case b)" - and then the existing
_NET_WM_FULLSCREEN would cover all the monitors, and other "Xinerama
awareness" would also be disabled.

Can anyone come up with a use case (other than VMWare) that would need
to force fullscreen to all monitors in case b)?

Fifth, I guess we could complicate things by allowing combinations of a)
and b) - "these two monitors form one monitor and this third monitor is
separate"

Sixth, I can imagine wanting to switch between a) and b) depending on
context; maybe you play your flight simulator with your three monitors
as one big screen, but when doing anything else you want three separate
monitors. This quickly becomes a serious programming and UI nightmare...
perhaps the proposed hint would fix it though by providing an "escape hatch"

Finally, what is the interaction with dynamic changes... metacity
reloads the xinerama info when it gets configure notify on the root
window iirc... I think xrandr can dynamically change the xinerama info.
It seems like there's a race created with the FULLSCREEN_MONITORS
property. This may be a minor problem though.

Havoc
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Elijah Newren]

Just a few extra cents...

On 3/4/07, Havoc Pennington <hp@...> wrote:

> Here are a bunch of questions ;-)
>
> First, a background point. Owen and I had a long thread with Kevin
> Martin a couple years ago (which was in private mail I think,
> unfortunately). Anyway, the claim I was making then was that Xinerama is
> overloaded to mean at least two things:
>
>   a) "I have one big monitor that happens to be made up of multiple LCD
>     panels / CRTs" - e.g. a video wall, is the extreme case
>   b) "I have two monitors and wish to be able to move windows between
>     them" - most commonly a plain dual-head or triple-head setup

<snip some good background and questions>

> Fourth, excluding VMWare, what hints are missing...
> we could add _NET_WM_FULLSCREEN_ALL_MONITORS or something, but I think
> that might be wrong. It might be more correct to implement a property,
> to be honored by both WMs and toolkits, that essentially says "ignore
> Xinerama, this is case a) not case b)" - and then the existing
> _NET_WM_FULLSCREEN would cover all the monitors, and other "Xinerama
> awareness" would also be disabled.

Do we really want a screen global property rather than a
window-specific property?

> Can anyone come up with a use case (other than VMWare) that would need
> to force fullscreen to all monitors in case b)?

I'd like to hear the VMWare case explained too.  I think I read it on
Christian's or Phillip's blog a while ago, but no longer remember any
details.  (Note: I don't know much about VMWare, so don't assume much
in your explanation)

I thought we had some other bug reports about this, but all I could
find is: http://bugzilla.gnome.org/show_bug.cgi?id=119187 (user wants
special key for maximizing their IDE across all monitors).

We also have an orthogonal fullscreen request (which I'm mentioning
just for completeness); basically in determining which of the
conflicting hints of fullscreen and non-resizability take precedence.
(In particular, games often don't want to be resized by the user, but
want to allow requests from the application to be made fullscreen).
See http://bugzilla.gnome.org/show_bug.cgi?id=130404.

> Fifth, I guess we could complicate things by allowing combinations of a)
> and b) - "these two monitors form one monitor and this third monitor is
> separate"

David's patch does that, if I read correctly in my quick scanning of
it.  My question is: why is this useful?  Would a simpler
fullscreen-across-all-monitors hint be sufficient?

> Sixth, I can imagine wanting to switch between a) and b) depending on
> context; maybe you play your flight simulator with your three monitors
> as one big screen, but when doing anything else you want three separate
> monitors. This quickly becomes a serious programming and UI nightmare...
> perhaps the proposed hint would fix it though by providing an "escape hatch"

I can see that this would be a nightmare if the hints were global to
the screen rather than specific to each window.  I don't see any
problems with the latter, right now.  Can others think of any?


Elijah
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Philip Langdale-4]

Elijah Newren wrote:
>
> David's patch does that, if I read correctly in my quick scanning of
> it.  My question is: why is this useful?  Would a simpler
> fullscreen-across-all-monitors hint be sufficient?

No. The feature we're trying to enable allows you dedicate subsets
of the available monitors to the VM - anything from 1 head to
all heads and any strictly contiguous subsets (so if you have
three monitors in a row, we won't let you choose the two outside
ones but any other combination is acceptable).

Yes, there is an argument that this is something of a niche requirement,
although I do believe it has applicability for other applications, but
the key factor is that it is currently *impossible* to implement this
behaviour if the window manager is being uncooperative (short of
override-redirect - which causes so many other problems). There is literally
no combination of hints that will convince metacity to allow this to happen.
Although I think it's possible with most other window managers, when the
broken case is so ubiquitous, you can't ignore it. So, it seems that the
only way to guarantee it to be possible is to clearly define the behaviour
in the spec so that window managers can know how to support it.

--phil
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[David Trowbridge]

>
> First, a background point. Owen and I had a long thread with Kevin
> Martin a couple years ago (which was in private mail I think,
> unfortunately). Anyway, the claim I was making then was that Xinerama is
> overloaded to mean at least two things:
>
>   a) "I have one big monitor that happens to be made up of multiple LCD
>     panels / CRTs" - e.g. a video wall, is the extreme case
>   b) "I have two monitors and wish to be able to move windows between
>     them" - most commonly a plain dual-head or triple-head setup
>
> When we talk about "Xinerama support" in the window manager and widget
> toolkit, normally it means to act as if Xinerama is case b). That is,
> the WM will do things like interpret FULLSCREEN as for only one monitor;
> put DOCK windows on only one monitor; maximize to only one monitor; and
> so forth.
>
> All of this "Xinerama support" is busted if we are really in case a).
>
> Anyway, my claim at the time was that X should just claim to have a
> single monitor in case a), that is, apps have no interest in the
> Xinerama info in case a), because the multiple monitors are really a
> hardware implementation detail and not of interest. But at the very
> least, we might want some kind of global property (set by e.g. the
> desktop environment) that would tell the WM and the toolkit to ignore
> Xinerama.
>
> So second, why does FULLSCREEN go to only one monitor; it's because
> we're in case b), "Xinerama support," and assuming that the two monitors
> are supposed to be more or less separate. Common use-cases here include
> having a status display such as a bunch of stock tickers or server
> status readouts on one monitor and having your email/etc. on the other,
> or just having email/web on one and programming on the other, or whatever.
>
> Third, what is the case with VMWare? I'm guessing VMWare is totally
> weird in that it's essentially doing hardware configuration - assign one
> monitor to the VM and another monitor to the host, or something? Maybe
> you can walk through the rough use-case and what your configuration GUI
> for this might be like.

Our use case is that we're exposing multiple monitors to the guest.  The most
basic case is that you have two monitors on the host, and want to go fullscreen
over both, and see two monitors in the guest.  As Phil said, we allow any
contiguous combination of monitors, so people with three heads could have a
two-headed guest on two of them, and still interact with their host on
the third.

We don't really have any configuration GUI for this.  The basic user procedure
is that they go to fullscreen on one monitor, which becomes their "primary"
monitor.  We then present a toolbar on that monitor which has a button to extend
the window onto another monitor.  Since our primary market for this product is
software dev/test, it's really handy to be able to switch between multi-monitor
layouts at the click of a button.

> I'm having trouble thinking of something other than VMWare that might
> want the hint you proposed, is why I'm calling it weird... doesn't mean
> we can't do this hint, just that we shouldn't overload it with other
> user-cases that aren't the same.
>
> Fourth, excluding VMWare, what hints are missing...
> we could add _NET_WM_FULLSCREEN_ALL_MONITORS or something, but I think
> that might be wrong. It might be more correct to implement a property,
> to be honored by both WMs and toolkits, that essentially says "ignore
> Xinerama, this is case a) not case b)" - and then the existing
> _NET_WM_FULLSCREEN would cover all the monitors, and other "Xinerama
> awareness" would also be disabled.
>
> Can anyone come up with a use case (other than VMWare) that would need
> to force fullscreen to all monitors in case b)?

As I suggested in the bug report, blender wants to go fullscreen across all
 monitors.  An all monitors hint would apply to them, but this would also work,
since it's a lower level request.  It requires a little more lifting
on the application
side, but not more than a few lines of code.  This sort of display is fairly
common in the sorts of applications you see from the graphics world, since in
a lot of cases, artists want to live completely inside their environment.

I imagine any other applications that want this would probably just want all
monitors, but people could potentially ask for a subset with devil's pie.

> Fifth, I guess we could complicate things by allowing combinations of a)
> and b) - "these two monitors form one monitor and this third monitor is
> separate"
>
> Sixth, I can imagine wanting to switch between a) and b) depending on
> context; maybe you play your flight simulator with your three monitors
> as one big screen, but when doing anything else you want three separate
> monitors. This quickly becomes a serious programming and UI nightmare...
> perhaps the proposed hint would fix it though by providing an "escape hatch"
>
> Finally, what is the interaction with dynamic changes... metacity
> reloads the xinerama info when it gets configure notify on the root
> window iirc... I think xrandr can dynamically change the xinerama info.
> It seems like there's a race created with the FULLSCREEN_MONITORS
> property. This may be a minor problem though.

There is a race.  I'm thinking it work to recompute the bounding rect
for any applicable
windows when the xinerama configuration changes.  There might be a
momentary flicker
between waiting for the application to update its requested monitors
and the window
manager updating it, but changing a xinerama configuration is fraught
with flicker anyways.

-David
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Havoc Pennington]

Elijah Newren wrote:

>> Fourth, excluding VMWare, what hints are missing...
>> we could add _NET_WM_FULLSCREEN_ALL_MONITORS or something, but I think
>> that might be wrong. It might be more correct to implement a property,
>> to be honored by both WMs and toolkits, that essentially says "ignore
>> Xinerama, this is case a) not case b)" - and then the existing
>> _NET_WM_FULLSCREEN would cover all the monitors, and other "Xinerama
>> awareness" would also be disabled.
>
> Do we really want a screen global property rather than a
> window-specific property?

We definitely need a global prop also, if I understand your question -
if I have a single virtual monitor (made up of multiple LCD panels or
CRTs) then I want all the "fullscreen" buttons and options in my desktop
and my apps to automatically go to the whole monitor.

If I have multiple monitors, then I want all apps to automatically go to
only one monitor.

This is a global config thing, and it should be configured the same
place I set up Xinerama in the first place.

App-specific hints would be only to override the default because an app
was special somehow.

Otherwise every app would need to contain xinerama config, right?

>> Sixth, I can imagine wanting to switch between a) and b) depending on
>> context; maybe you play your flight simulator with your three monitors
>> as one big screen, but when doing anything else you want three separate
>> monitors. This quickly becomes a serious programming and UI nightmare...
>> perhaps the proposed hint would fix it though by providing an "escape
>> hatch"
>
> I can see that this would be a nightmare if the hints were global to
> the screen rather than specific to each window.  I don't see any
> problems with the latter, right now.  Can others think of any?

To be honest I don't see how per-window even works - metacity, for
example, needs to globally decide whether to be "xinerama aware" - if
apps disagree on whether there are multiple conceptual monitors or just
one, then who knows what "xinerama aware" should do.

Per-window works to make exceptions, but there has to be a basic
behavior for the overall desktop... what area do windows maximize to,
what area are dialogs centered in, etc.

Exceptions to the global setting might be:
  - you want "one big monitor" for certain games or something but
    not for productivity (note this is probably a user decision,
    not something the game developer should hardcode)
  - vmware... maybe. seems to me the vmware case may be the same
    as putting your stock ticker readouts on one head and your
    applications on another; the only thing is vmware wants to
    have the config GUI for it in the vmware app itself. But
    stuff would break if for example metacity thought there
    was one big monitor, and vmware wanted to be on only one
    of them; then e.g. metacity would maximize other apps
    to cover up vmware. So vmware may want to change the global
    setup? If we had a global hint, if a user wanted vmware on
    two monitors and native host on a third, they'd just fullscreen
    vmware on the two (after globally configuring those two as one
    virtual monitor)
  - I don't understand the blender case well enough

Writing the above made me realize, FULLSCREEN_MONITORS is probably wrong
because xinerama awareness goes beyond the fullscreen hint. e.g. what
about vmware's dialogs, which monitors should the WM consider when
placing them? what about maximization? etc. So maybe the hint is just
plain MONITORS.

Thinking about the user-visible behavior of the whole desktop, I'm
wondering if we're talking about inherently global state (the monitor
arrangement and which groups are conceptually single monitors) because
the state involves interactions between a bunch of different apps and
the WM itself, and everyone has to agree at any given point in time.
(i.e. to do fullscreen across all monitors, you'd have to just nuke the
separate monitors while your app was focused)

That may not be true, I do think *most* apps have to agree at any given
point though, at least, the WM, panel, and all normal apps that don't
have their own UI for tweaking which monitors they span. "Exception"
apps may have app-specific setup that overrides, or something.

Havoc

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[David Trowbridge]

There seem to be a number of ideas interwoven throughout your last email, and
try as I might, I can't seem to compose a cogent reply inline.  I'll try to
respond to each point individually, with the hope that I'm not misunderstanding
or missing anything.


>> What should the basic behavior of the desktop be?

We currently have a well understood behavior, and I think it maps quite well to
users' expectations: each physical monitor on the host is reflected within the
xinerama configuration.  If a window exists on a monitor, it will maximize to
the bounds of that screen.  Its dialogs will appear on the same screen, etc.  As
you noted, there are just a few "exceptions to the global setting"

>> What are the exceptions?
- Games: I think this one is pretty obvious.
- VMware: This is potentially less obvious, but I think it's actually a lot like
  the games use case.  The vmware window may want to span across multiple
  monitors, but a user doesn't want that to impact any other applications they
  happen to be running.
- Blender: This was just me racking my brain for other applications which
  request that a window cover multiple monitors.  It's pretty typical in the
  graphics application space (of which blender is the only linux representative
  that I know of) to request as many pixels as possible, since in a lot of
  cases, an artist just wants to live inside that environment.

Two things strike me about all of these use cases.  First, they are all within
fullscreen mode.  This may be an accident, or it may be a useful observation.
Second, I think these cases are at their most well behaved when the applications
in question have some xinerama awareness built-in.  A flight sim would want to
draw things such that the splits between monitors didn't occur in the middle of
your altitude control.  VMware passes the monitor information through to the
guest OS to really make it look like you're not using a virtual machine.
Blender might want to add edge resistance on its internal area splits to make it
easier to lay out your workspace to fit your screens.

>> Should this be a global hint, and allow applications to change the xinerama
>> layout to suit their needs?

I think this is a huge can of worms.  What if I have a spreadsheet maximized on
screen 0, and I ask vmware to go into fullscreen across both screens 0 and 1?
Does my spreadsheet now get maximized to both heads along with it?  What happens
to my panel windows?  A lot (read: all) of applications are not written with
this sort of behavior in mind.  randr++ will force things like gnome-panel to
take it into account, but I think the chances that an application would do
something that the user didn't want are pretty high.



Back to my requirements for this -- I really, *really* don't want users to have
to think about configuring "virtual" monitors in order to do something like have
a VM across two of their three heads and still interact with their host on the
third.  Apps that want to take advantage of more than a single screen will work
best when they know about xinerama, and chances are that I, or the flight
simulator programmer, or the graphics app hacker will know better about their
individual usage of multi-monitor windows than the window manager or the user.


-David

On 3/4/07, Havoc Pennington <hp@...> wrote:

> Elijah Newren wrote:
> >> Fourth, excluding VMWare, what hints are missing...
> >> we could add _NET_WM_FULLSCREEN_ALL_MONITORS or something, but I think
> >> that might be wrong. It might be more correct to implement a property,
> >> to be honored by both WMs and toolkits, that essentially says "ignore
> >> Xinerama, this is case a) not case b)" - and then the existing
> >> _NET_WM_FULLSCREEN would cover all the monitors, and other "Xinerama
> >> awareness" would also be disabled.
> >
> > Do we really want a screen global property rather than a
> > window-specific property?
>
> We definitely need a global prop also, if I understand your question -
> if I have a single virtual monitor (made up of multiple LCD panels or
> CRTs) then I want all the "fullscreen" buttons and options in my desktop
> and my apps to automatically go to the whole monitor.
>
> If I have multiple monitors, then I want all apps to automatically go to
> only one monitor.
>
> This is a global config thing, and it should be configured the same
> place I set up Xinerama in the first place.
>
> App-specific hints would be only to override the default because an app
> was special somehow.
>
> Otherwise every app would need to contain xinerama config, right?
>
> >> Sixth, I can imagine wanting to switch between a) and b) depending on
> >> context; maybe you play your flight simulator with your three monitors
> >> as one big screen, but when doing anything else you want three separate
> >> monitors. This quickly becomes a serious programming and UI nightmare...
> >> perhaps the proposed hint would fix it though by providing an "escape
> >> hatch"
> >
> > I can see that this would be a nightmare if the hints were global to
> > the screen rather than specific to each window.  I don't see any
> > problems with the latter, right now.  Can others think of any?
>
> To be honest I don't see how per-window even works - metacity, for
> example, needs to globally decide whether to be "xinerama aware" - if
> apps disagree on whether there are multiple conceptual monitors or just
> one, then who knows what "xinerama aware" should do.
>
> Per-window works to make exceptions, but there has to be a basic
> behavior for the overall desktop... what area do windows maximize to,
> what area are dialogs centered in, etc.
>
> Exceptions to the global setting might be:
>   - you want "one big monitor" for certain games or something but
>     not for productivity (note this is probably a user decision,
>     not something the game developer should hardcode)
>   - vmware... maybe. seems to me the vmware case may be the same
>     as putting your stock ticker readouts on one head and your
>     applications on another; the only thing is vmware wants to
>     have the config GUI for it in the vmware app itself. But
>     stuff would break if for example metacity thought there
>     was one big monitor, and vmware wanted to be on only one
>     of them; then e.g. metacity would maximize other apps
>     to cover up vmware. So vmware may want to change the global
>     setup? If we had a global hint, if a user wanted vmware on
>     two monitors and native host on a third, they'd just fullscreen
>     vmware on the two (after globally configuring those two as one
>     virtual monitor)
>   - I don't understand the blender case well enough
>
> Writing the above made me realize, FULLSCREEN_MONITORS is probably wrong
> because xinerama awareness goes beyond the fullscreen hint. e.g. what
> about vmware's dialogs, which monitors should the WM consider when
> placing them? what about maximization? etc. So maybe the hint is just
> plain MONITORS.
>
> Thinking about the user-visible behavior of the whole desktop, I'm
> wondering if we're talking about inherently global state (the monitor
> arrangement and which groups are conceptually single monitors) because
> the state involves interactions between a bunch of different apps and
> the WM itself, and everyone has to agree at any given point in time.
> (i.e. to do fullscreen across all monitors, you'd have to just nuke the
> separate monitors while your app was focused)
>
> That may not be true, I do think *most* apps have to agree at any given
> point though, at least, the WM, panel, and all normal apps that don't
> have their own UI for tweaking which monitors they span. "Exception"
> apps may have app-specific setup that overrides, or something.
>
> Havoc
>
>

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Elijah Newren]

Hi,

On 3/9/07, David Trowbridge <trowbrds@...> wrote:
<snip>
> Back to my requirements for this -- I really, *really* don't want users to have
> to think about configuring "virtual" monitors in order to do something like have
> a VM across two of their three heads and still interact with their host on the
> third.  Apps that want to take advantage of more than a single screen will work
> best when they know about xinerama, and chances are that I, or the flight
> simulator programmer, or the graphics app hacker will know better about their
> individual usage of multi-monitor windows than the window manager or the user.

So, your hint is an application specific override to the current
handling of xinerama only.  And I think I understand the basic use
cases.  Makes sense to me; I'm in favor.

Elijah
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Havoc Pennington]

Hi,

Elijah Newren wrote:

> Hi,
>
> On 3/9/07, David Trowbridge <trowbrds@...> wrote:
> <snip>
>> Back to my requirements for this -- I really, *really* don't want users to have
>> to think about configuring "virtual" monitors in order to do something like have
>> a VM across two of their three heads and still interact with their host on the
>> third.  Apps that want to take advantage of more than a single screen will work
>> best when they know about xinerama, and chances are that I, or the flight
>> simulator programmer, or the graphics app hacker will know better about their
>> individual usage of multi-monitor windows than the window manager or the user.
>
> So, your hint is an application specific override to the current
> handling of xinerama only.  

Current handling of xinerama or current handling of fullscreen? e.g. if
vmware opens a dialog, should the WM center it on one monitor or across
the two vmware covers?

David, I think your comment that the app hacker knows better applies
exactly to the extent that the behavior change is only in one app. If
two apps need to coordinate, then the app hacker may know better, but
isn't in a position to implement the behavior.

It does make sense to me that certain apps (games, vmware) might say
"cover multiple monitors" where the multiple monitors are distinct
spaces (what I called "b)" originally) for all other apps. So I'd go
with Elijah and say the hint makes sense, though I'm not clear yet on
whether it should cover only fullscreen behavior or all "xinerama awareness"

I do think some of the other issues raised need addressing, but they
appear orthogonal to this hint since this hint assumes case b) and
doesn't take a position on how we distinguish a) and b)

Perhaps there's a caveat that if we add a global hint to specify case
a), this app-window-specific hint would need to match that overriden
monitor layout rather than what the Xinerama extension reports.

Hmm, another unrelated thought; is this hint really per-window or should
it be on the group leader - seems to me we'll have to effectively figure
out the xinerama request of the transient parent in order to place
dialogs, anyhow.

Havoc

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On Friday 09 of March 2007, Havoc Pennington wrote:

> Hi,
>
> Elijah Newren wrote:
> > Hi,
> >
> > On 3/9/07, David Trowbridge <trowbrds@...> wrote:
> > <snip>
> >
> >> Back to my requirements for this -- I really, *really* don't want users
> >> to have to think about configuring "virtual" monitors in order to do
> >> something like have a VM across two of their three heads and still
> >> interact with their host on the third.  Apps that want to take advantage
> >> of more than a single screen will work best when they know about
> >> xinerama, and chances are that I, or the flight simulator programmer, or
> >> the graphics app hacker will know better about their individual usage of
> >> multi-monitor windows than the window manager or the user.
> >
> > So, your hint is an application specific override to the current
> > handling of xinerama only.

 I think a WM setting would do as well (enabling strict geometry in KWin's
window-specific settings could do this, although I'm too lazy to try for
real :) ), but I suppose a hint apps could set would be simpler for users.
After all, if people start misusing it, I can still interpret the strict
geometry setting the other way around. So this is on okay from me too.


> Current handling of xinerama or current handling of fullscreen? e.g. if
> vmware opens a dialog, should the WM center it on one monitor or across
> the two vmware covers?

 On one, we're still talking b) and you don't want the dialog to be split
between two monitors. However this might make sense e.g. for maximization.
But allowing this flag to apply to more than just fullscreen brings up more
questions (what if I want it to apply only to fullscreen?), so I'd probably
keep this fullscreen-only until somebody asks for this. I've also already
seen requests for apps being able to ask for multiple-monitors fullscreen but
I don't remember asking for anything else.

> David, I think your comment that the app hacker knows better applies
> exactly to the extent that the behavior change is only in one app. If
> two apps need to coordinate, then the app hacker may know better, but
> isn't in a position to implement the behavior.
>
> It does make sense to me that certain apps (games, vmware) might say
> "cover multiple monitors" where the multiple monitors are distinct
> spaces (what I called "b)" originally) for all other apps.

 Why? I don't see a single reason why VMWare should be able to change how
Konqueror goes fullscreen.

> So I'd go
> with Elijah and say the hint makes sense, though I'm not clear yet on
> whether it should cover only fullscreen behavior or all "xinerama
> awareness"
>
> I do think some of the other issues raised need addressing, but they
> appear orthogonal to this hint since this hint assumes case b) and
> doesn't take a position on how we distinguish a) and b)

 And do we need to take position on a)? As you said, in such case Xinerama
settings should pretend there's no Xinerama.

> Perhaps there's a caveat that if we add a global hint to specify case
> a), this app-window-specific hint would need to match that overriden
> monitor layout rather than what the Xinerama extension reports.
>
> Hmm, another unrelated thought; is this hint really per-window or should
> it be on the group leader - seems to me we'll have to effectively figure
> out the xinerama request of the transient parent in order to place
> dialogs, anyhow.

 I'd say per-window.

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Havoc Pennington]

Lubos Lunak wrote:
>> It does make sense to me that certain apps (games, vmware) might say
>> "cover multiple monitors" where the multiple monitors are distinct
>> spaces (what I called "b)" originally) for all other apps.
>
>  Why? I don't see a single reason why VMWare should be able to change how
> Konqueror goes fullscreen.

I think you interpreted my comment backward from what I was trying to
say, I didn't mean vmware should change the global state.

>
>> So I'd go
>> with Elijah and say the hint makes sense, though I'm not clear yet on
>> whether it should cover only fullscreen behavior or all "xinerama
>> awareness"
>>
>> I do think some of the other issues raised need addressing, but they
>> appear orthogonal to this hint since this hint assumes case b) and
>> doesn't take a position on how we distinguish a) and b)
>
>  And do we need to take position on a)? As you said, in such case Xinerama
> settings should pretend there's no Xinerama.

I think it would be better if the X server simply didn't report
xinerama, but last time we tried the X hackers couldn't be convinced, so
perhaps we need to set our own XSETTING-type global desktop property.

Havoc

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[David Trowbridge]

As far as I can tell, reading through this again, people seem to be
generally happy with the idea of a FULLSCREEN_MONITORS hint
per-window.  Is this actually the case, and if so, what happens next?

-David


On 3/12/07, Havoc Pennington <hp@...> wrote:

> Lubos Lunak wrote:
> >> It does make sense to me that certain apps (games, vmware) might say
> >> "cover multiple monitors" where the multiple monitors are distinct
> >> spaces (what I called "b)" originally) for all other apps.
> >
> >  Why? I don't see a single reason why VMWare should be able to change how
> > Konqueror goes fullscreen.
>
> I think you interpreted my comment backward from what I was trying to
> say, I didn't mean vmware should change the global state.
>
> >
> >> So I'd go
> >> with Elijah and say the hint makes sense, though I'm not clear yet on
> >> whether it should cover only fullscreen behavior or all "xinerama
> >> awareness"
> >>
> >> I do think some of the other issues raised need addressing, but they
> >> appear orthogonal to this hint since this hint assumes case b) and
> >> doesn't take a position on how we distinguish a) and b)
> >
> >  And do we need to take position on a)? As you said, in such case Xinerama
> > settings should pretend there's no Xinerama.
>
> I think it would be better if the X server simply didn't report
> xinerama, but last time we tried the X hackers couldn't be convinced, so
> perhaps we need to set our own XSETTING-type global desktop property.
>
> Havoc
>
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list@...
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Havoc Pennington]

Hi,

David Trowbridge wrote:
> As far as I can tell, reading through this again, people seem to be
> generally happy with the idea of a FULLSCREEN_MONITORS hint
> per-window.

Reading back over it, the only thing is I'm not sure I agree with Lubos
that it should only affect FULLSCREEN.

Let's put it this way - for vmware, where do you want dialogs to open (I
know you can force-override from the app, but assuming you don't do that
and let the WM place them, over what area should they be centered)

It seems like there are xinerama considerations other than dialog
location but I'm blanking on it right now.

Oh, maximization I guess, in addition to fullscreen - should that follow
this hint?

Generally speaking the name FULLSCREEN_MONITORS just seems very not
semantic to me. That is, if I have a question about how the WM should
interpret it, I don't really know what the answer is, since I'm not sure
what this hint means about the app at a high level.

Here's another question - what happens if the user moves the app to
another monitor that isn't a FULLSCREEN_MONITOR (and the app is
fullscreen?) - metacity might allow that unless we also implement some
kind of "fullscreen lock" behavior. Well, we allow it for maximized
windows anyway, don't remember for fullscreen.

Or if the app is not fullscreen and not on a FULLSCREEN_MONITOR and it
gets fullscreened, it would warp to the FULLSCREEN_MONITOR? That seems a
little weird. Would the app generally have to keep updating the
FULLSCREEN_MONITOR to the monitor it's currently on?

Now I'm wanting to say the hint should be a client message + hint combo
like _NET_WM_STATE, i.e.
  - property sets the initial map value
  - WM updates the property after map
  - after map, app can change it via client message

> Is this actually the case, and if so, what happens next?

We need a patch to the spec DocBook, then if there are no improvements
to the exact wording, someone can commit it (I'm not sure who has commit
access these days but surely someone on the list does ;-))

In the spec text I'd be sure to cover some of the questions such as I
have in this mail since all the implementations will need to know.

We should probably then be willing to change the spec if the first
couple WMs to implement it encounter problems.

Havoc
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Elijah Newren]

On 4/10/07, Havoc Pennington <hp@...> wrote:
> David Trowbridge wrote:
> > As far as I can tell, reading through this again, people seem to be
> > generally happy with the idea of a FULLSCREEN_MONITORS hint
> > per-window.
>
> Reading back over it, the only thing is I'm not sure I agree with Lubos
> that it should only affect FULLSCREEN.
<snip and pull a line out of order>
> Oh, maximization I guess, in addition to fullscreen - should that follow
> this hint?

I've seen at least bug report requesting a similar ability for
maximization (in particular for some IDE).  I'm not sure I'd see why
to support fullscreen but not maximization with such a hint.

> Let's put it this way - for vmware, where do you want dialogs to open (I
> know you can force-override from the app, but assuming you don't do that
> and let the WM place them, over what area should they be centered)
>
> It seems like there are xinerama considerations other than dialog
> location but I'm blanking on it right now.

Actually, we already have a similar precedent that may be useful.  In
a dual-monitor xinerama system with metacity, we make desktop windows
(such as the one from nautilus) cover both monitors.  We got bug
reports when nautilus dialogs were split across xineramas.  Based on
that, I think the answer is that the FULLSCREEN_MONITORS hint (or
whatever we call it) should not be inherited by children.  Thus, the
behavior would be as Lubos suggested earlier: we would not want child
dialogs to be split across monitors and thus such dialogs wouldn't
necessarily be centered on their parent.

> Here's another question - what happens if the user moves the app to
> another monitor that isn't a FULLSCREEN_MONITOR (and the app is
> fullscreen?) - metacity might allow that unless we also implement some
> kind of "fullscreen lock" behavior. Well, we allow it for maximized
> windows anyway, don't remember for fullscreen.
>
> Or if the app is not fullscreen and not on a FULLSCREEN_MONITOR and it
> gets fullscreened, it would warp to the FULLSCREEN_MONITOR? That seems a
> little weird. Would the app generally have to keep updating the
> FULLSCREEN_MONITOR to the monitor it's currently on?

I think these are really good questions.  The current suggested hint
now bothers me because I can't see how to handle these.  Perhaps we
should instead have a
   _NET_WM_FULLSCREEN_AND_MAXIMIZATION_GEOMETRY
hint (or some better name with a similar meaning) which consists of a
pair of integers and defaults to 1x1.  1x1 means the window
fullscreens/maximizes to cover 1 monitor horizontally and 1 monitor
vertically.  2x1 would make the window cover both monitors in your
typical dual monitor xinerama case.  But having 2x1 would also make it
clear what to do if you had a three monitor setup and wanted to move
the maximized/fullscreen window.

Thoughts?

Elijah
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On Wednesday 18 of April 2007, Elijah Newren wrote:

> On 4/10/07, Havoc Pennington <hp@...> wrote:
> > David Trowbridge wrote:
> > > As far as I can tell, reading through this again, people seem to be
> > > generally happy with the idea of a FULLSCREEN_MONITORS hint
> > > per-window.
> >
> > Reading back over it, the only thing is I'm not sure I agree with Lubos
> > that it should only affect FULLSCREEN.
>
> <snip and pull a line out of order>
>
> > Oh, maximization I guess, in addition to fullscreen - should that follow
> > this hint?
>
> I've seen at least bug report requesting a similar ability for
> maximization (in particular for some IDE).  I'm not sure I'd see why
> to support fullscreen but not maximization with such a hint.

 Was that a request for the IDE being able to maximize its window in such a
way or a for the user being able to maximize some window in such a way using
the WM? I can see some point in apps asking for a special geometry in special
cases but I don't see why maximization should be any app's business.

> > Let's put it this way - for vmware, where do you want dialogs to open (I
> > know you can force-override from the app, but assuming you don't do that
> > and let the WM place them, over what area should they be centered)
> >
> > It seems like there are xinerama considerations other than dialog
> > location but I'm blanking on it right now.
>
> Actually, we already have a similar precedent that may be useful.  In
> a dual-monitor xinerama system with metacity, we make desktop windows
> (such as the one from nautilus) cover both monitors.  We got bug
> reports when nautilus dialogs were split across xineramas.  Based on
> that, I think the answer is that the FULLSCREEN_MONITORS hint (or
> whatever we call it) should not be inherited by children.  Thus, the
> behavior would be as Lubos suggested earlier: we would not want child
> dialogs to be split across monitors and thus such dialogs wouldn't
> necessarily be centered on their parent.

 Note that this brings another question: Where should the dialog be shown
then? And, if you're tempted to immediately give the (probably correct)
answer that on the active one, which one would that be? And no, the one with
the mouse doesn't count, as soon as one throws it away and uses only keyboard
for a while. Apps using this multi-screen hint would probably also have to
provide this information somehow (internal focus/cursor position?).

> > Here's another question - what happens if the user moves the app to
> > another monitor that isn't a FULLSCREEN_MONITOR (and the app is
> > fullscreen?) - metacity might allow that unless we also implement some
> > kind of "fullscreen lock" behavior. Well, we allow it for maximized
> > windows anyway, don't remember for fullscreen.
> >
> > Or if the app is not fullscreen and not on a FULLSCREEN_MONITOR and it
> > gets fullscreened, it would warp to the FULLSCREEN_MONITOR? That seems a
> > little weird. Would the app generally have to keep updating the
> > FULLSCREEN_MONITOR to the monitor it's currently on?
>
> I think these are really good questions.  The current suggested hint
> now bothers me because I can't see how to handle these.  Perhaps we
> should instead have a
>    _NET_WM_FULLSCREEN_AND_MAXIMIZATION_GEOMETRY
> hint (or some better name with a similar meaning) which consists of a
> pair of integers and defaults to 1x1.  1x1 means the window
> fullscreens/maximizes to cover 1 monitor horizontally and 1 monitor
> vertically.  2x1 would make the window cover both monitors in your
> typical dual monitor xinerama case.  But having 2x1 would also make it
> clear what to do if you had a three monitor setup and wanted to move
> the maximized/fullscreen window.

 This would make more sense, but then the question is if the app handles
moving between (xinerama) screens and the possible changes of geometry. Would
VMWare handle such case?

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[David Trowbridge]

> Let's put it this way - for vmware, where do you want dialogs to open (I
> know you can force-override from the app, but assuming you don't do that
> and let the WM place them, over what area should they be centered)

I'd say "on a monitor covered by the main window."  If possible, the one which
the mouse is on.


> Oh, maximization I guess, in addition to fullscreen - should that follow
> this hint?

Maybe there's a use case for maximizing over multiple monitors.  I personally
don't know of any.

> Generally speaking the name FULLSCREEN_MONITORS just seems very not
> semantic to me. That is, if I have a question about how the WM should
> interpret it, I don't really know what the answer is, since I'm not sure
> what this hint means about the app at a high level.
>
> Here's another question - what happens if the user moves the app to
> another monitor that isn't a FULLSCREEN_MONITOR (and the app is
> fullscreen?) - metacity might allow that unless we also implement some
> kind of "fullscreen lock" behavior. Well, we allow it for maximized
> windows anyway, don't remember for fullscreen.

I can't alt+drag a fullscreened window with metacity right now.  I
don't think there's
any specification that says that window managers aren't allowed to do
that, though.


> Or if the app is not fullscreen and not on a FULLSCREEN_MONITOR and it
> gets fullscreened, it would warp to the FULLSCREEN_MONITOR? That seems a
> little weird. Would the app generally have to keep updating the
> FULLSCREEN_MONITOR to the monitor it's currently on?

It would warp, at least with the implementation I wrote against
metacity.  I don't think it's
unreasonable to expect that an application which uses this hint will
update it before
setting _NET_WM_FULLSCREEN.


> Now I'm wanting to say the hint should be a client message + hint combo
> like _NET_WM_STATE, i.e.
>   - property sets the initial map value
>   - WM updates the property after map
>   - after map, app can change it via client message

Sounds fine.


-David
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Elijah Newren]

On 5/20/07, David Trowbridge <trowbrds@...> wrote:
> > Let's put it this way - for vmware, where do you want dialogs to open (I
> > know you can force-override from the app, but assuming you don't do that
> > and let the WM place them, over what area should they be centered)
>
> I'd say "on a monitor covered by the main window."  If possible, the one which
> the mouse is on.

That doesn't work as a (complete) solution.  I missed the same point
in my last email, which Lubos pointed out.  To quote him on this
topic, addressing which monitor to place dialogs of such windows on:

"And, if you're tempted to immediately give the (probably correct)
answer that on the active one, which one would that be? And no, the
one with the mouse doesn't count, as soon as one throws it away and
uses only keyboard for a while."

> > Generally speaking the name FULLSCREEN_MONITORS just seems very not
> > semantic to me. That is, if I have a question about how the WM should
> > interpret it, I don't really know what the answer is, since I'm not sure
> > what this hint means about the app at a high level.
> >
> > Here's another question - what happens if the user moves the app to
> > another monitor that isn't a FULLSCREEN_MONITOR (and the app is
> > fullscreen?) - metacity might allow that unless we also implement some
> > kind of "fullscreen lock" behavior. Well, we allow it for maximized
> > windows anyway, don't remember for fullscreen.
>
> I can't alt+drag a fullscreened window with metacity right now.  I don't think there's any
> specification that says that window managers aren't allowed to do that, though.

I'd count that as a bug (or at least missing feature) in metacity.
There's nothing technically stopping us from implementing it (just
time constraints), and it's one that I'd particularly like to address.
 However, the FULLSCREEN_MONITOR proposal would introduce a technical
hurdle for this feature.  I don't like that.

> > Or if the app is not fullscreen and not on a FULLSCREEN_MONITOR and it
> > gets fullscreened, it would warp to the FULLSCREEN_MONITOR? That seems a
> > little weird. Would the app generally have to keep updating the
> > FULLSCREEN_MONITOR to the monitor it's currently on?
>
> It would warp, at least with the implementation I wrote against metacity.  I don't think it's
> unreasonable to expect that an application which uses this hint will update it before
> setting _NET_WM_FULLSCREEN.
>
> > Now I'm wanting to say the hint should be a client message + hint combo
> > like _NET_WM_STATE, i.e.
> >   - property sets the initial map value
> >   - WM updates the property after map
> >   - after map, app can change it via client message
>
> Sounds fine.

I'm not following the suggestion, Havoc.  How does the WM update it?
If you're referring to a hint like the original, as I was inferring,
then the hint is the monitors to which the app says that the WM should
fullscreen the app window.  How then does the WM update this hint,
i.e. how does it magically guess which monitors are okay to fullscreen
to if it doesn't use the app hint?  (And if we can do that, why do we
need a hint from the app in the first place?)


Elijah
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Havoc Pennington]

Hi,

Elijah Newren wrote:
> I'm not following the suggestion, Havoc.  How does the WM update it?
> If you're referring to a hint like the original, as I was inferring,
> then the hint is the monitors to which the app says that the WM should
> fullscreen the app window.  How then does the WM update this hint,
> i.e. how does it magically guess which monitors are okay to fullscreen
> to if it doesn't use the app hint?  (And if we can do that, why do we
> need a hint from the app in the first place?)
>

I don't think the _NET_WM_STATE-style approach introduces the problems
here, the problems arise if you say that the WM can try to be smart
about or participate in the fullscreen monitors decision (by allowing
alt+drag, or by fullscreening to the current monitor instead of
fullscreen monitors, or by having a menu item to "stretch this app over
the monitor to the right also," or whatever).

If you allow the WM (or pager) to e.g. allow the user to alt+drag the
window from monitors 1,2 to monitors 2,3 or something like that, then
you need the _NET_WM_STATE approach to do that without races, you can't
just have a free-for-all where app and WM can both change the property
directly, or where the WM ignores the property sometimes.

The _NET_WM_STATE approach does not preclude a "non-interfering" WM that
changes FULLSCREEN_MONITORS only when the app itself asks it to via
client message. It does however *allow* an "interfering" WM.

If we don't go the _NET_WM_STATE route, then the WM in effect *must* be
"non-interfering" - it MUST accept the FULLSCREEN_MONITORS property in
all cases and never change it or ignore it. That may be right but seems
inflexible.

What makes sense to me (right this minute anyway) is to treat
FULLSCREEN_MONITORS just like the other state info such as MAXIMIZED.
The WM can have UI or keybindings or something to change it, the app can
have defaults, and the app would typically accept any state set by the
WM, and also save the current state when the app exits, and restore it
on app startup.

It does seem like the best UI for this would be in an app dialog (since
it's only useful to do this for some apps), with only "hidden" UI like
alt+drag in the WM. But that doesn't preclude the _NET_WM_STATE-style
approach - it just means the dialog in the app would either set the hint
(before map) or send the client message (after map), and that the app
would then need to track the current property state and update its
dialog/saved-state accordingly if it changes. IOW just like MAXIMIZED,
the canonical copy of the state is kept by the WM for mapped windows and
kept by the app for withdrawn windows, and when the app exits (withdraws
a window) the app is responsible for persisting the last-known state.

It's possible that going more top-down on the problem and doing some
quick sketches of all the involved dialogs, menu items, keybindings,
etc. would make it clearer what to do?

Havoc

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[David Trowbridge]

> > I'd say "on a monitor covered by the main window."  If possible, the one which
> > the mouse is on.
>
> That doesn't work as a (complete) solution.  I missed the same point
> in my last email, which Lubos pointed out.  To quote him on this
> topic, addressing which monitor to place dialogs of such windows on:
>
> "And, if you're tempted to immediately give the (probably correct)
> answer that on the active one, which one would that be? And no, the
> one with the mouse doesn't count, as soon as one throws it away and
> uses only keyboard for a while."

How is that case any different from "placing a new window on a
multi-head system without a mouse"?  It's just in this case, you're
restricted about which monitors you might choose for such a window.

-David
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list