Re: Review: FULLSCREEN_MONITORS Hint

["Christian Hammond" <chipx86 chipx86 com>]

Hi everyone.

On Nov 30, 2007 5:57 AM, Elijah Newren <newren gmail com> wrote:

On Nov 29, 2007 6:12 PM, Grant Patterson <grantp vmware com> wrote:
> I'm just using Nvidia TwinView and am relatively new to this stuff, so I don't
> have a firm grasp on what is possible without the new "RandR hotness". (Can
> monitors be different sizes? Can arrangements be non-linear, e.g. square of 4 or
> L shape? Can 2 monitors be skewed?)
>
> Nevertheless, it seems like we might as well make the property something that
> can handle monitors anywhere on the framebuffer. This is easy enough to do with
> my new favorite method: specify a top-left and bottom-right monitor; the WM
> takes the bounding box of these and sets the window accordingly

Bounding box?  So if you have two monitors of different sizes next to
each other and you use them, then you expect the vmware window to not
be totally visible?

In our case, we're setting the VMware window fullscreen and setting the guest's multimon configuration to be the same as ours. If the window is technically partially hidden on one monitor, it'll never be noticeable, since the guest OS's topology will match ours.

This may be a special case for us (and other apps that work like ours). In the case of video players, that may not be as desirable, but they can always check the monitor geometries before picking something that fits what they need exactly. Keeping it flexible by allowing a bounding box gives more options, I think. Ensuring that the full bounding box of the window be visible on all monitors limits the usefulness of this feature, as applications wouldn't be able to decide for themselves whether or not it can work with monitors of different geometries.
 

> I don't understand how width/height would be enough--given some horizontal
> arrangement of >2 monitors and width=2 monitors, how does the WM know where to
> place the window? VMware wants to change window configurations without leaving
> fullscreen (go from monitors {0, 1} to {1, 2}), so using the monitor we started
> fullscreen from won't cut it. Have I explained our desired functionality enough?

Ah, I didn't realize that you wanted to update it on the fly in order
to change position.  So, we could specify an x,y (in monitor sizes)
for the upper left of the window too.  But I think the x,y part should
just be an "initial" hint, not a maintained constraint.

I really dislike hardcoding the position (e.g. specifying upper left
and bottom right corner), since I'd like the user to be able to grab
and move the window to other monitors and specifying absolute
positions doesn't seem very compatible with that.  Maybe the grab and
move case is more relevant for movie players than vmware, but I don't
want this to be a vmware-only hint.

Fullscreen applications won't have window decorations, requiring that they handle any drag operations themselves.They'd have to handle updating the hint when moving onto a different monitor. I think the x, y location would actually benefit the movie player scenario in this case.
 
Do any fullscreen applications have the ability to switch monitors right now? I'm curious what they do for this.

Christian

-- 
Christian Hammond - 
chipx86 chipx86 com
VMware, Inc.