Re: Application-controlled window dragging

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 <[email protected]> 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
> [email protected]
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>



-- 
Christian Hammond - [email protected]
VMware, Inc.

_______________________________________________
wm-spec-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/wm-spec-list