Re: Application-controlled window dragging

[Carsten Haitzler (The Rasterman) <raster rasterman com>]

On Fri, 5 Oct 2007 15:13:00 -0700 "Christian Hammond" <chipx86 chipx86 com>
babbled:

> On 10/5/07, Havoc Pennington <hp redhat com> wrote:
> >
> > Hi,
> >
> > Christian Hammond wrote:
> > > I'm working on an experimental project at VMware that will require us to
> > > have greater control over a window's position while the window manager
> > > is dragging it. We'd need to basically give the application more control
> > > over the movement of the window, yet allow the the window manager to
> > > apply whatever effects and conditions it would typically apply while
> > > moving a window. We'd need to let the application, for example, prevent
> > > the window from going past a certain part of the screen, or to stay
> > > within a bounding box, or to just prevent it from moving over another
> > > window.
> >
> > It would seem more logical to me to convey these constraints to the WM,
> > rather than adding an "escape hatch" that potentially leaves the WM with
> > no clue what's going on or why.
> >
> > I'd guess metacity would have a really hard time knowing how to
> > implement the "escape hatch" - most of the time, the move constraints in
> > the metacity code apply even to moves originated by the WM itself.
> >
> > Certainly the codepaths related to this are "interesting" enough already.
> >
> > Is it possible to develop a more semantic hint instead of the escape
> > hatch? (without more detail on the project, it's tough for me to suggest
> > anything.)
> >
> > Havoc
> >
> >
> The problem is, we won't necessarily know these restrictions before we're
> dragging. We only have some idea of them as we drag, as we hit them.
> 
> If we go to a more traditional example, let's look at XMMS. It consists of
> multiple, separate windows that stick together while dragging. They have to
> handle move events themselves in order to guarantee the windows will stick

to GUARANTEE - yes. but with sufficiently smart wm's and some hints the wm
could do this too.

> together to bind them, and to move all the windows at the same time. They
> wouldn't be able to do this with _NET_WM_MOVERESIZE, and are forced to act
> in such a way where the window manager will have no idea that they're
> dragging.

correct. all the wm knows is that the app requests to be in a new location, and
nicely obliges. sometimes it doesn't oblige depending on the wm, policies and
user settings.

> We have this problem to a much higher degree. Not only do we need to support
> this case, but more complex cases where windows can't reach positions on the
> screen. And we just don't know until the user tries to drag it there.

we have a race condition here too. if you let the wm to do the move - there
will be a delay between you updating where it can and can't move things, the wm
getting such a message and then enforcing it. so it would be possible to just
set a property on your window that is a list of "allowed rect regions" (you
will need to list all the allowed regions for the window to be moved within,
and re-set this property with a new list whenever that changes, and hope the wm
enforces it. there will be a delay between a mouse move, then window move and
it could be a window will violate a non-move region before you update to say it
shouldn't go there. are such violations (or race conditions/temporary
violations) acceptable? or are they a hard limit? in which case you are talking
a round trip via x to the wm and back per mouse motion event where the wm sends
you a new location and your app ok's it or not. ugly imho.... :(

so i see 2 possible ways this could work - taking it on faith that you really
do need to limit a window's location on screen to a non-rectangular subset of
the screen:

1. set property that is a list of rectangles where the window is allowed to go.
the wm' must listen for updates to this property and never set it itself, and
keep the window within the region defined by that list of rectangles at all
times, even during moves and resizes. we have a race condition here - but that's
probably better than method 2:

2. wm WANTS window to go to x,y - it sends request to client, client responds
with yes or no. if yes, wm can move there. round trips to x and then over to
client, then back to x and back to wm per move. latency heaven. not pretty at
all.

oh yeah - does the region include the window frame or not? can the frame go
outside of it?

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


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com
裸好多
Tokyo, Japan (東京 日本)