Re: Application-controlled window dragging
- From: "Christian Hammond" <chipx86 chipx86 com>
- To: "Havoc Pennington" <hp redhat com>
- Cc: wm-spec-list gnome org
- Subject: Re: Application-controlled window dragging
- Date: Fri, 5 Oct 2007 15:13:00 -0700
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 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.
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.
Christian
--
Christian Hammond -
chipx86 chipx86 comVMware, Inc.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]