Re: Drag and drop

[Rob Adams <robadams ucla edu>]

That's how all drag and drop works.

For the WM:
The window manager need only not raise participating window on
ButtonPress, but rather on receiving the _MAY_ACTIVATE message.  This is
about 5 minutes of coding for pretty much any WM I would guess.

For the Toolkit or Application:
On ButtonPress, the toolkit would determine whether, should the user
hold the button and move the mouse more than the drag threshold, a drag
and drop would be initiated.  If so, it doesn't send the message. 
Otherwise, it does send the the message.

The result is that the window would be raised immediately if there's no
chance a drag would start, and otherwise could be raised on
ButtonRelease by the WM.  I got this idea because this is the way the
Windows window manager handles it, and it makes drag and drop work the
way you would expect.

If you don't like the name, I'm certainly willing to entertain any
suggestions you have for improving it.  We could, for example, return to
the name _NET_WM_IS_DRAG_START.  I wanted to try to make it more
general, but I don't know of any use case beyond DND so we could chance
it back.

As for the WM-initiated part: It's certainly true that the other
protocols are all WM-initiated.  My previous proposal was for a
wM-initiated protocol, but that added extra complications, like the need
to include a coordinate pair in the message, which would require the
toolkit to create a special pathway for computing how to respond to the
message.  This way, the client, which already has to respond to
ButtonPress, and almost certainly also has to prepare to handle the
start of a drag and drop as well, the burden on the client for this
method is far smaller (My guess is that for most toolkits and
applications, it's just adding a few lines of code).

-Rob

On Fri, 2003-06-13 at 02:28, Waldo Bastian wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Friday 13 June 2003 10:43, Lubos Lunak wrote:
> >  If nothing else, I find the description quite confusing. A message called
> > MAY_ACTIVE with the meaning "don't raise" ?
> >
> >  But what interests me more: Do you actually have a working implementation
> > of this? Maybe other WMs do it differently, but I doubt this would work
> > with KWin. KWin has a button grab on the client windows, so a ButtonPress
> > event results in KWin getting it first, raising the window (if KWin is
> > configured so), and then the event is replayed, and it reaches the
> > application. At this point, it's too late for the application to ask not to
> > be raised.
> 
> And well-behaved KDE application don't start the drag on button-press but on a 
> mouse-move that exceeds the drag treshold, so I don't think this scheme has 
> much chance of working.
> 
> Cheers,
> Waldo
> - -- 
> bastian kde org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian suse com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE+6ZlMN4pvrENfboIRAoESAJ9Tx89OmpEmi+dbCs0Xo4+veCqbJgCeMEfg
> klvS8rYmCvn9ehs27u3JMMg=
> =f5SL
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>