Re: Application-controlled window dragging

["Christian Hammond" <chipx86 chipx86 com>]

If I could describe the whole feature, I would. This is just how things work in competitive businesses, but I'm not proposing something that would only be useful in this case. This is beneficial for any application that needs to do something special as the window moves.

The thing to keep in mind is that there are several applications that already bypass the window manager's moving logic and implement it themselves. XMMS is a good example because of how it deals with moving multiple windows simultaneously and binds windows together when they come in contact. What I'm proposing lets the window manager know that the window is being dragged, allows it to feel more "real," and yet still gives the application some control over its own movement logic.

In the past at VMware, we've had to use X in ways that most people just haven't needed so far. Our multimonitor support in VMware Workstation wasn't possible without either a spec extension (which hasn't been accepted last I heard) or some hacks. This new feature would benefit greatly from the proposed spec extension, as would some existing programs out there. Sometimes you have to push the envelope to make really useful features and do things that haven't been required from apps until now. If we can't get this implemented, we'll live without it, but it will really reduce the experience and I don't want to see that happen.

For the time being, yes, we can make a proprietary extension and try to get some window managers to use it. I don't think it's the best option long-term, but perhaps that'll do until we at the least have a demo or beta out. It'll be easier to describe at that point why it's essential.

Christian

On 10/5/07, Nathaniel Smith <njs pobox com> wrote:

On Fri, Oct 05, 2007 at 04:13:41PM -0700, Christian Hammond wrote:
>    The piece of code I'm working on now is an experiment at the moment, but
>    it will be part of a full-blown feature we're working on, one which I'm
>    sure will be very popular. I can't talk about the feature in detail
>    (unless either of you want to sign an NDA, which I can probably arrange),
>    as it hasn't been announced yet, but not having this support will have a
>    serious impact on this feature's usability.

I appreciate these issues, but I also hope you realize there are some
fundamental difficulties with convincing a free standards group to
mandate some behavior in N different window manager projects, just on
your word that it will allow one proprietary app to have a totally
cool feature that is best implemented and set in stone in this way
that I came up with and no-one has reviewed, trust me.

I mean, these might be all true... but I'm not sure how, as
hopefully-responsible engineers, we can just accept them without
checking for ourselves, or convince projects that they should bother
implementing/maintaining this feature with no more to go on than your
word.  Do you have any ideas?

If the problem is just that it needs to remain a secret for a while
longer, you may have more luck adding support for a custom (not
_NET_WM_*) extension to a few important window managers, convincing
their maintainers to take the patch, and then worry about pushing it
up into EWMH once the feature is out and there is some real-world
experience with it.

(Also, umm... is "lack of wobbly windows" really a "serious impact"?
Though I guess you can't really explain why things would affect
usability, either.)

-- Nathaniel

--
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein
_______________________________________________
wm-spec-list mailing list
wm-spec-list gnome org
http://mail.gnome.org/mailman/listinfo/wm-spec-list

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