Hi everyone.

On Nov 30, 2007 5:57 AM, Elijah Newren <[EMAIL PROTECTED]> wrote:

> On Nov 29, 2007 6:12 PM, Grant Patterson <[EMAIL PROTECTED]> 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 - [EMAIL PROTECTED]
VMware, Inc.
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list

Reply via email to