Drag and drop in Tk 4.0
T.S.Locke
I have just been looking at the Tk 4.0 overview document from Sun and I notice
that Motif drag and drop in not supported. Drag and drop is pretty much
essential for what I want to do with Tk.
I know proper motif style drag and drop (with the little running man and the
funny rubber bands that whip him back to where he started) is not the only
option. Obviously drag and drop of objects within a canvas window can be done
but what about draging an object between different widgets, or between two
top-levels?
Tom.
Jeffrey Hobbs
>I know proper motif style drag and drop (with the little running man and the
>funny rubber bands that whip him back to where he started) is not the only
>option.
The BLT extension offers an excellent drag&drop package. It would be nice
to have motif 2.0 drag&drop, but this is what's available. You can find
the unofficial version (v1.8) for tk4 at
http://www.cs.uoregon.edu/jhobbs/
George Howlett (the author) will be releasing the official update for tk4
in a couple of weeks, so you may want to wait.
--
Jeffrey Hobbs Office: 503/346-3998
Univ of Oregon CIS GTF email: jho...@cs.uoregon.edu
URL: http://www.cs.uoregon.edu/~jhobbs/
John Ousterhout
|>
|> I have just been looking at the Tk 4.0 overview document from Sun and I notice
|> that Motif drag and drop in not supported. Drag and drop is pretty much
|> essential for what I want to do with Tk.
We've put off doing drag and drop until the PC and Mac ports are done,
so that we can be sure to design a high-level interface to drag and
drop that will be usable on all the platforms. I suspect that it will
be about another year before drag and drop appears in Tk. Sorry about
that...
John Chambers
Actually, after getting a few clues from this newsgroup as to how
to figure out where the pointer is really pointing, it only took
me an hour or so to get drag&drop to work between a window that
shows a lot of bitmap icons and another window that shows a sort
of typical network map. Most of that time was spent futzing with
the arithmetic that it takes to get things positioned right.
I'm a bit curious as to just what sort of things people expect from
a drag&drop package. I've used them on Macs and MS-Windows, but never
programmed them, and I don't have much feel for what might be expected.
I've been using Netview, which implements its own demented version of
drag&drop, differently from Mac and MS-W software. Has there been
much discussion of what's the "right" way to do drag&drop? I can
easily think of several incompatible ways to do it.
The weirdest thing about how tk does it is that when you release
the button, you get a release event in the window where you pressed
the button, not where you released it. In my application, these are
in fact two different processes. So what I found I had to do was to
have the recipient of the release event send messages to all the other
scripts in the package, telling them all about the release, including
the %X and %Y values. Each of the others then does [wm geometry .]
and check to see if the coordinates is in its window, and if so, take
whatever actions it takes for a drop.
This isn't hard to program, it does seem like there oughta be a better
way. I mean, it's fairly obvious that the underlying window software
knows, at some level, which window the release occurred in, and which
process owns that window. A lot of cpu time could be saved if the lower
layers would just tell the right process about the event. Is there
maybe some subtle reason that my feeble brain can't fathom why it was
done this way? It seems that, at most, only two processes would be
interested in a drag&drop: The owner of the "press" window needs to
indicate something about the thing being dragged, and the owner of
the "release" window needs to be able to find out what has been dropped
on it. What am I missing? Has there been a discussion that I've
missed out on?
--
John Chambers <jm...@gte.com> <j...@minya.bcs.org>
Unix puzzle of the week: What does this do?
find . '*.bak' -exec rm -f {} ';'
Don't try this at $HOME ...
T.S.Locke
: We've put off doing drag and drop until the PC and Mac ports are done,
: so that we can be sure to design a high-level interface to drag and
: drop that will be usable on all the platforms. I suspect that it will
: be about another year before drag and drop appears in Tk. Sorry about
: that...
I'd just like to put in a wish - seeing as the stuff hasn't been developed
yet.
One thing a lot of programs that use drag and drop often lack, is the
ability to dynamically track the destination of the drop _before_ the drop
takes place.
A good example of when this is very useful (vital?) is in the text
selection drap and drop in Microsoft Word. As you move the pointer, a sort
of greyed-out insertion cursor follows the mouse to indicate exactly where
you are about to drop.
I have used text editors that support drag and drop, but leave you
guessing as to where exactly you are dropping - this becomes very tedious
as you have to position the mouse _very_ carefully to get it right.
Here's hoping...
Tom (wondering if he can mention Microsoft
and live to tell the tale)
Jeffrey Hobbs
>ability to dynamically track the destination of the drop _before_ the drop
>takes place. A good example of when this is very useful (vital?) is in the
>text selection drap and drop in Microsoft Word. As you move the pointer, a
>sort of greyed-out insertion cursor follows the mouse to indicate exactly
>where you are about to drop.
I don't think that's necessarily not done currently. BLT's drag and drop
allows you to select the dd cursor and relative position of the window to
the cursor (n, s, e, w, nw...). I wrote something simple for a text
widget that places the window 15 pixels to the right of the pointer so you
definitely knew where the text was going. Really trivial tk code.
What's would be nice for tk that I haven't seen any way to do at the
scripting level would be to have an optional "see-through" window for doing
dd, like the Mac and others do it (the opposite of an opaque move).
Heiko Nardmann
have. So I dropped a project which should implement a filemanager like the Norton Commander
on PCs resp. better like the Directory Opus 4.x on the Amiga and OS/2. Pressing on the
one widget and releasing on another one was one problem I had. Checking whether a double
click with the first click on a different widget than the second click was another one when
you have many widgets. Maybe the binding substitutions like %x etc. could be enhanced to
show up the source and the destination widgets.
A hint for John Ousterhout? :-)
--
Ciao ... Heiko Nardmann (nph...@informatik.uni-siegen.de)
student of computer science
at: DEC AXP 3000 (OSF1 parallel1 V3.2 250 alpha)
WWW: http://www.informatik.uni-siegen.de/~npheiko
Jeffrey Hobbs
Heiko Nardmann <nph...@informatik.uni-siegen.de> wrote:
>So I dropped a project which should implement a filemanager like the
>releasing on another one was one problem I had.
I did not have any problems duplicating things similar to DOpus. For
checking what button was pressed on what you have to make bindings for
both ButtonPress _and_ ButtonRelease. For drag and drop, I use the BLT
toolkit. After playing a while with Tk, you realize how simple DOpus
really is (the GUI that is).
Donal K. Fellows
John Chambers <jm...@roger.gte.com> wrote:
>The weirdest thing about how tk does it is that when you release
>the button, you get a release event in the window where you pressed
>the button, not where you released it. In my application, these are
>in fact two different processes. So what I found I had to do was to
>have the recipient of the release event send messages to all the other
>scripts in the package, telling them all about the release, including
>the %X and %Y values. Each of the others then does [wm geometry .]
>and check to see if the coordinates is in its window, and if so, take
>whatever actions it takes for a drop.
>
It would be far worse if the initiating application didn't receive the
ButtonRelease, as then it would have to guess when the button was
released, and whether that was over another Tk app, a non-Tk window,
or the root. Ugh!
The only way round this requires the window manager to act as a
drag-n-drop server...
Also, why didn't you just use the `winfo containing' command as
demonstrated by the demonstration in:
http://www.cs.man.ac.uk/~fellowsd/d&d.tcl
as this gets rid of a lot of calculation (in Tcl)...
Donal.
--
Donal K. Fellows, (at work) | Donal K. Fellows, (at home)
Dept. of Computer Science, | 6, Randall Place, Heaton,
University of Manchester | Bradford, BD9 4AE
U.K. Tel: ++44-161-275-6137 | U.K. Tel: ++44-1274-401017
fell...@cs.man.ac.uk (preferred) | do...@ugglan.demon.co.uk (if you must)
-------------------------------------------------------------------------------
See my <A HREF="http://www.cs.man.ac.uk/~fellowsd/">home page</A>
My WWW pages are now available by mail. Send mail to me with the Subject:
WWW-Mail: whatever_URL_you_want
Donal K. Fellows
>One thing a lot of programs that use drag and drop often lack, is the
>ability to dynamically track the destination of the drop _before_ the drop
>takes place.
>
>A good example of when this is very useful (vital?) is in the text
>selection drap and drop in Microsoft Word. As you move the pointer, a sort
>of greyed-out insertion cursor follows the mouse to indicate exactly where
>you are about to drop.
>
>guessing as to where exactly you are dropping - this becomes very tedious
>as you have to position the mouse _very_ carefully to get it right.
>
You can add it to Tcl/Tk now without much effort. The only problem
will be when using applications over very slow network links...
But then, drag-n-drop within a canvas is painful over a 14400-baud
modem (I've tried it :)
No, I'm not going to implement it. I have work to do instead... :^)
Larry W. Virden:
Unfortunately, the 'right' way to D&D is the 'native' way. For instance,
I believe there's a few documents (the ICCCCM and perhaps a tutorial or two)
that I have seen describing the proper way to do X drag and drop. But
I doubt that's compatible with Windows, Mac, etc. So for Tk, one really
needs something else.
I would prefer, myself, to see an OpenDoc compatible that allowed one to
drag and drop between Tk and other apps appearing on one's desktop without
consideration of the source and destination applications.
--
:s Larry W. Virden INET: larry....@cas.org
:s In search of a new WWW home...
:s Unless explicitly stated to the contrary, nothing in this posting should
:s be construed as representing my employer's opinions.
Donal K. Fellows
Jeffrey Hobbs <jho...@cs.uoregon.edu> wrote:
> In article <14...@larch.ukc.ac.uk>, T.S.Locke <ts...@ukc.ac.uk> wrote:
>> One thing a lot of programs that use drag and drop often lack, is the
>> ability to dynamically track the destination of the drop _before_ the drop
>> takes place. A good example of when this is very useful (vital?) is in the
>> text selection drap and drop in Microsoft Word. As you move the pointer, a
>> sort of greyed-out insertion cursor follows the mouse to indicate exactly
>> where you are about to drop.
At the weekend I felt rather bored, so I had a go at implementing drag
and drop at script level in pure Tk4.0. The result can be found in
http://www.cs.man.ac.uk/~fellowsd/d+d.tcl
which contains everything needed to get drag and drop working between
applications (there are sufficient hooks to allow the use of cursors
that change according to data type and drop location, as well as
allowing the indication of the putative drop location in the target
before the button release) together with a quick-and-dirty testbed.
Isn't it amazing what you can do with send? :^)
> I don't think that's necessarily not done currently. BLT's drag and drop
> allows you to select the dd cursor and relative position of the window to
> the cursor (n, s, e, w, nw...). I wrote something simple for a text
> widget that places the window 15 pixels to the right of the pointer so you
> definitely knew where the text was going. Really trivial tk code.
>
> What's would be nice for tk that I haven't seen any way to do at the
> scripting level would be to have an optional "see-through" window for doing
> dd, like the Mac and others do it (the opposite of an opaque move).
>
I have seen BLT's drag and drop using toplevel windows, and to be
quite frank, I'd rather do without drag and drop!
Jeffrey Hobbs
Donal K. Fellows <fell...@cs.man.ac.uk> wrote:
>I have seen BLT's drag and drop using toplevel windows, and to be
>quite frank, I'd rather do without drag and drop!
I'm sure a long discussion could arise over not using any windows for
drag and drop, but I just don't see the purpose. In many applications
it's not always certain to the user what's moving without the window for
reference. I think that's why we've never seen it done.
Gordon Chaffee
Jeffrey Hobbs <jho...@cs.uoregon.edu> wrote:
>In article <3udggr$f...@m1.cs.man.ac.uk>,
>Donal K. Fellows <fell...@cs.man.ac.uk> wrote:
>>I have seen BLT's drag and drop using toplevel windows, and to be
>>quite frank, I'd rather do without drag and drop!
>
>I'm sure a long discussion could arise over not using any windows for
>drag and drop, but I just don't see the purpose. In many applications
>it's not always certain to the user what's moving without the window for
>reference. I think that's why we've never seen it done.
Windows deals with drag and drop by changing the cursor shape, so there
are certainly other ways to handle drag and drop that don't involve
moving around toplevel windows. I'm not suggesting that one is better
than the other; I'm just saying we have seen it done other ways before,
maybe not under Tk or event under X (anybody know how Motify 2.0 implements
drag and drop?), but under Windows and on the Mac.
Gordon Chaffee
cha...@bugs-bunny.cs.berkeley.edu
Donal K. Fellows
> Jeffrey Hobbs wrote in article <3ue86s$k...@ix.cs.uoregon.edu> :
>> In article <3udggr$f...@m1.cs.man.ac.uk>,
>> Donal K. Fellows <fell...@cs.man.ac.uk> wrote:
>>> I have seen BLT's drag and drop using toplevel windows, and to be
>>> quite frank, I'd rather do without drag and drop!
>>
>> I'm sure a long discussion could arise over not using any windows for
>> drag and drop, but I just don't see the purpose.
>
>
Dragging and dropping non-toplevels is only possible within a single
toplevel, so your question is not really understandable. However:
For inter-application/toplevel drag and drop, you must either use a
toplevel to indicate where your your cursor is, and what it is
carrying, or you must use just your mouse cursor. There really are
no other alternatives unless you write your own toplevel clone!
IMHO, it is desirable to see exactly where you are going to drop
whatever you're dragging, and so fully decorated dragged toplevels
is right out. Marking them transient is the least you can do, though
setting the overrideredirect flag and getting rid of the border
looks better. However, it is still easy for that window to obscure
where you are dropping the data. If the window could be shaped
(using the right X extension) then this wouldn't be a problem, but
that is not possible with Tk4.0 AFAIK (at least not without having
to do quite a lot of work... :^). This leaves, to my mind at least,
merely changing the cursor as the most preferable option, especially
when you see just how configurable the cursor really is.
This might be heresy, but the M$WinDoze style of dragging indication
is really quite reasonable...
wi...@spooky.rwwa.com
>Dragging and dropping non-toplevels is only possible within a single
>toplevel
That was the point I was going to raise.
> IMHO, it is desirable to see exactly where you are going to drop
> whatever you're dragging
I don't see why dragging a window (of reasonable size, and reasonably
configured) has to, of necessity, obscure a d&d target. After all,
the token can be located anywere WRT the cursor (after the pick). If
the token were placed below and to the right of the cursor it would
serve nicely for most applications. Could be configurable (and even
variable during the drag).
> This leaves, to my mind at least,
> merely changing the cursor as the most preferable option, especially
> when you see just how configurable the cursor really is.
Two objections:
a) Cursors are frequently of limited size (and color). This limits
the look of the token.
b) The cursor can display additional information. Like an insert
versus overwrite cursor, or something like that. This is obviated
by overloading the cursor with the token image.
-----------------------------------------------------------------------------
Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430 Net: wi...@rwwa.COM
R.W. Withrow Associates, 319 Lynnway Suite 201, Lynn MA 01901 USA
wi...@spooky.rwwa.com
>
>In article <3udggr$f...@m1.cs.man.ac.uk>,
>Donal K. Fellows <fell...@cs.man.ac.uk> wrote:
>>I have seen BLT's drag and drop using toplevel windows, and to be
>>quite frank, I'd rather do without drag and drop!
>
>I'm sure a long discussion could arise over not using any windows for
>drag and drop, but I just don't see the purpose.
Is it *any* windows he is complaining about, or just toplevel windows.
-----------------------------------------------------------------------------
Donal K. Fellows
>I don't see why dragging a window (of reasonable size, and reasonably
>configured) has to, of necessity, obscure a d&d target. After all,
>the token can be located anywere WRT the cursor (after the pick). If
>the token were placed below and to the right of the cursor it would
>serve nicely for most applications. Could be configurable (and even
>variable during the drag).
>
It doesn't have to, but that doesn't change the fact that I've found
that it usually does... :^)
[ About using cursors by themselves ]
>Two objections:
> a) Cursors are frequently of limited size (and color). This limits
> the look of the token.
>
Two colours (any you want) isn't much of a problem, and I haven't hit
the size limit yet (I've seen a 216x208 cursor - the escherknot from
the X distribution :^)
> b) The cursor can display additional information. Like an insert
> versus overwrite cursor, or something like that. This is obviated
> by overloading the cursor with the token image.
>
How do you distinguish between dragging to insert and dragging to
overwrite? Surely this is purely a target application-dependant
thing... (and wht about dragging to a file manager, that doesn't
necessarily fit either model)
Donal.
--
Donal K. Fellows, (at work) | Donal K. Fellows, (at home)
Dept. of Computer Science, | 6, Randall Place, Heaton,
University of Manchester | Bradford, BD9 4AE
U.K. Tel: ++44-161-275-6137 | U.K. Tel: ++44-1274-401017
fell...@cs.man.ac.uk (preferred) | do...@ugglan.demon.co.uk (if you must)
-------------------------------------------------------------------------------
See my home page at http://www.cs.man.ac.uk/~fellowsd/
Donal K. Fellows
Ioi K. Lam <i...@red.seas.upenn.edu> wrote:
>The experience of dragging a window into a drop site is similar to
>moving a refrigerator through a narrow door. Of course, you can see
>the door well if you move the fridge aside. But when you hold up the
>fridge, it completely blocks your view and you can only hope that you
>are really moving past the door and are not hitting against the
>wall. Try to move your fridge out of the kitchen and back again, and
>you will realize how annoying this gets. And you certainly don't want
>your users to feel this way.
>
Anyone who is interested in just what a drag-and-drop system can be
like should have a good look at RiscOS. It is certainly an
eye-opener...
Ioi K. Lam
: >>quite frank, I'd rather do without drag and drop!
: >
: >I'm sure a long discussion could arise over not using any windows for
: >it's not always certain to the user what's moving without the window for
: >reference. I think that's why we've never seen it done.
: Windows deals with drag and drop by changing the cursor shape, so there
: are certainly other ways to handle drag and drop that don't involve
: moving around toplevel windows. I'm not suggesting that one is better
: than the other; I'm just saying we have seen it done other ways before,
: maybe not under Tk or event under X (anybody know how Motify 2.0 implements
: drag and drop?), but under Windows and on the Mac.
The reasons against using windows as a D+D indicator are (1) The window
is always square and (2) it can be very slow on low end machines and
MS Windows. I saw a demo of the Sun Tk interface builder in the Tcl
workshop and they have a version that runs on top of MS Windows.
They do drag+drop in MS Windows using window as the D+D indicator, and
you can see a lot of "droppings" along the way when you are dragging
the mouse cursor.
Ioi
Ioi K. Lam
: > whatever you're dragging
: I don't see why dragging a window (of reasonable size, and reasonably
: configured) has to, of necessity, obscure a d&d target. After all,
: the token can be located anywere WRT the cursor (after the pick). If
: the token were placed below and to the right of the cursor it would
: serve nicely for most applications. Could be configurable (and even
: variable during the drag).
The experience of dragging a window into a drop site is similar to
moving a refrigerator through a narrow door. Of course, you can see
the door well if you move the fridge aside. But when you hold up the
fridge, it completely blocks your view and you can only hope that you
are really moving past the door and are not hitting against the
wall. Try to move your fridge out of the kitchen and back again, and
you will realize how annoying this gets. And you certainly don't want
your users to feel this way.
Ioi.
Mark Roseman
of drag and drop, annette wagner from sunsoft had a paper in one of
the design briefings tracks at this past year's chi that talked about
some of the issues they had to deal with when implementing drag and
drop for motif/cde. the paper also had the best title in the
conference: "drag me, drop me, treat me like an object"
as someone already mentioned, the "right thing" we'll want to have in
tk is whatever the platform standard is. for unix its motif/cde,
for windows its what windows does and for the mac its what the mac
does (yes i know, tres descriptive). not only look and feel but also
using the native mechanisms so we can work with non-tk apps.
mark
--
Mark Roseman, Research Associate phone: (403) 220-3532 / 220-6087
Dept. of Computer Science fax: (403) 284-4707
University of Calgary email: ros...@cpsc.ucalgary.ca
Calgary, Alta CANADA T2N 1N4 http://www.cpsc.ucalgary.ca/~roseman
John Chambers
>as someone already mentioned, the "right thing" we'll want to have in
>tk is whatever the platform standard is. for unix its motif/cde, ...
Uh, don't look now, but neither motif nor cde is a part of Unix(TM).
If you think it is, you're falling victim to an ad campaign of the
form "If you're outta Schlitz, you're outta beer".
Hereabouts, we have a motley collection of Unices, including a bunch
of Suns for which OpenLook is a "mandatory option" (a nice term coined
by the Consumer Reports folks). That is, the libraries contain other
window managers, including mwm and twm, but nobody can discover how to get
them to run. When you run them, they just complain that there's already
a window manager present, and exit, leaving olwm in charge. All sorts
of things written with the assumption that motif was decreed by the Unix
gods turn out not to work on these machines.
If you want to determine the "standard" way to do D&D on a Unix
machine, you must consider *all* the graphics packages (or at least
those that tk runs on ;-), not just one that happens to be in use
where you are. This materially complicates the job. For a further
example, we have Silicon Graphics machines, and there are a couple
of Next machines lurking hereabouts.
As for Bill Gates' popular machines, things turn out not to be quite
as uniform as the salesmen would have you believe. We even have some
PCs running motif on top of MS-windows. Talk about a weird motif ...
wi...@spooky.rwwa.com
>
>: > IMHO, it is desirable to see exactly where you are going to drop
>: > whatever you're dragging
>
>: I don't see why dragging a window (of reasonable size, and reasonably
>: configured) has to, of necessity, obscure a d&d target.
>
>moving a refrigerator through a narrow door.
Come now, you're getting a little carried away. A window the same
size and shape (yes shape) as a windows style D&D cursor won't obscure
the target anymore than the cursor will.
Too much of these claims of the inferiority of using windows for the
token rely on the strawman assumptions about the size and shape of the
windows. It would be like me talking about a 500x700 cursor.
George A. Howlett
>In article <3umr31$8...@shore.shore.net>, <wi...@spooky.rwwa.com> wrote:
>> Come now, you're getting a little carried away. A window the same
>> size and shape (yes shape) as a windows style D&D cursor won't
>> obscure the target anymore than the cursor will.
>
>using cursors...
I don't think there's a clear winner regarding how to display the
drag-and-drop token. I can think of three different approaches
1) window
2) cursor
3) xor-ing over the root window
and each approach has its pluses and minuses.
Using a window gives you the maximum flexibility in how to visually
display the token. It can be as simple as a word of text or as
complex as a full-color image. Token windows can, however, take a
while to realize and map on slower hardware. And if the window is
too large, it can obscure the user's view of target sites.
Cursors on the other hand can be very fast, especially if you have a
hardware cursor. You can create tokens as simple outlines which you
can see through (around), lessening the chance of obscuring a target
site.
Cursors also have limitations. You can only have one foreground and
background color. Some X servers allow only relatively small cursors
(16x16 pixels). It's harder to create or change tokens (especially
from Tcl), because you need to generate a new bitmap (and a mask).
This makes it hard to provide good visual cues. For example, you need
another cursor to indicate when you're over a drop site and you need a
couple more to indicate if the drop was good. Of course, many
cursor-based implementations don't bother with this. But if you like
the active background/foreground feature or Tk buttons and scrollbars,
you'll understand how useful these visual cues are.
Xor-ing over the root window (subwindow_mode set to IncludeInferiors)
is slower than using cursors but it doesn't limit the size of the
token. You really can't control the colors drawn. But it's
relatively easy to generate the token (Xlib drawing procedures).
Right now, the drag-and-drop command in BLT uses windows. One of
Michael's goals was to make blt_drag&drop simple, yet flexible. It
gives the user a simple way to generate a token, without drastically
limiting what the token can look like. The trade-off is that it can
sometimes be slow and bulky. [BTW. Adding another approach (cursor,
xor-ing) shouldn't be very hard.]
The more interesting question is what drag-and-drop should be like.
I take the slightly heretical view that interoperability with Motif,
etc. is less important than a rich, powerful drag-and-drop mechanism.
Trouble is that the most common examples of drag-and-drop (Windows
file manager, etc) are too simple. They don't do much more than
transfer a filename or a text string. It's just a better way of doing
selections. So they don't demonstrate the need for a more powerful
drag-and-drop mechanism. Don't get me wrong. I like the feel of the
Windows and Mac drag-and-drop. But if there was a decent shell and
terminal window, I might use that instead to move, copy, and delete
files/folders.
Drag-and-drop at its best, deals in abstract quantities. In a circuit
simulator, I drop a circuit schematic on a graph and it displays the
relevant waveforms. If you've never seen the program Simply3D, it
lets you drag-and-drop complex items like objects, view ports, and light
sources.
What strikes me about the Motif drag-and-drop mechanism is how complex
and limited the protocols are compared to a real language like Tcl.
I see drag-and-drop like a telephone switchboard operator, connecting
you (the drop source) with different parties (drop targets). After
connecting, the two parties (source/target) manage the communication,
not the operator.
In the Tk "send" command, we have what seems to be the perfect
mechanism for this. The protocol (Tcl) is powerful, yet compact. The
drag-and-drop source and target can send Tcl commands back and forth
to mediate their own data transfers. You dispose of the entire notion
of data interchange types and formats.
Now I'm all for Tk's drag-and-drop inter-operating with Motif,
Windows, Mac, etc. drag-and-drop. But I'd hate to be limited to just
that, when here in the Tk world we have something much more powerful.
--gah
Olaf Schlueter
John> In article <ROSEMAN.95...@janu.cpsc.ucalgary.ca>
John> ros...@janu.cpsc.ucalgary.ca (Mark Roseman) writes:
>> as someone already mentioned, the "right thing" we'll want to
>> have in tk is whatever the platform standard is. for unix its
>> motif/cde, ...
John> Uh, don't look now, but neither motif nor cde is a part of
John> Unix(TM). If you think it is, you're falling victim to an
John> ad campaign of the form "If you're outta Schlitz, you're
John> outta beer".
But CDE is on its way to become the "standard" for an X Windows based
environment. Don't let things get too much complicated. If we talk of
a general drag & drop mechanism, we can safely ignore the operating
system, the X server runs on. As Motif is part of CDE, the drag and
drop protocol (not necessarily the look and feel) of this toolkit will
become the standard protocol for CDE. Since the other important GUI
toolkits in the X world (Athena, XView and tk) are available as source
it should be easy for someone who has access to the definition of the
motif drag and drop protocol to add support for it (I think one can
safely ignore Athena). Especially tk, which already mimic the look and
feel of Motif, and has a very good chance to become a free available
motif replacement will need to interoperate with plain motif
applications. Resumee: in a X environment, motif drag and drop
protocol must be supported.
John> Hereabouts, we have a motley collection of Unices, including
John> a bunch of Suns for which OpenLook is a "mandatory option"
John> (a nice term coined by the Consumer Reports folks). That
John> is, the libraries contain other window managers, including
John> mwm and twm, but nobody can discover how to get them to run.
John> When you run them, they just complain that there's already a
John> window manager present, and exit, leaving olwm in charge.
John> All sorts of things written with the assumption that motif
John> was decreed by the Unix gods turn out not to work on these
John> machines.
On Sun's, Try setting the environment variable WINDOW_MANAGER to mwm
before running openwin. However, mwm is not essential for Motif, it is
just another window manager. If you run a motif application in an X
environment, it supports drag & drop with a motif specific protocol,
and if you want to drag from any other application to it, this
application will have to know about that protocol.
--
Olaf Schlüter, Vaasastr. 22, 24109 Kiel, Germany, Toppoint Mailbox e.V.
"Wenn ich Klasse bin, möchte ich auch nicht, daß jeder mein Freund wird."
Ein Kollege lernt C++.
Donal K. Fellows
> But CDE is on its way to become the "standard" for an X Windows based
> environment. Don't let things get too much complicated. If we talk of
> a general drag & drop mechanism, we can safely ignore the operating
> system, the X server runs on. As Motif is part of CDE, the drag and
> drop protocol (not necessarily the look and feel) of this toolkit will
> become the standard protocol for CDE. Since the other important GUI
> toolkits in the X world (Athena, XView and tk) are available as source
> it should be easy for someone who has access to the definition of the
> motif drag and drop protocol to add support for it (I think one can
> safely ignore Athena). Especially tk, which already mimic the look and
> feel of Motif, and has a very good chance to become a free available
> motif replacement will need to interoperate with plain motif
> applications. Resumee: in a X environment, motif drag and drop
> protocol must be supported.
>
I've just been looking into this, but there are a number of
problems...
a) Whether or not to link with the Motif library.
I think we'd rather avoid this if we can (for a host of
reasons that I don't want to go into here)
b) Whether we want to run after a moving target.
The documentation I have on drag-and-drop for Motif says that
this is not especially stable, as there was mention of a joint
project between Sun and OSF to get d+d between OopenLook and
Motif apps. This is what we really want, but I don't know the
details of this. Mind you, my Motif docs aren't exactly up to
date... :^)
c) Whether we can bear to read enough of the manual to figure out
how to make Tk compatible... (66 pages is too much IMHO :^)
In short, I think I'll let someone else figure out how to make Tk work
in this respect.
Oh, and I had a good look at how Motif implements the indicators of
whether a drop is possible, and it seems to be using shaped
override-redirected windows (the most flexible option IMHO) since I
can obscure the `cursor' in one of these operations with another OR
window, and it is definitely not rectangular. However, until we get
shaped windows, I'll stick to using cursors...
a90...@pluto.tiuk.ti.com
:>
:>I'm sure a long discussion could arise over not using any windows for
:>drag and drop, but I just don't see the purpose. In many applications
:>it's not always certain to the user what's moving without the window for
:>reference. I think that's why we've never seen it done.
:
:Windows deals with drag and drop by changing the cursor shape, so there
:are certainly other ways to handle drag and drop that don't involve
:moving around toplevel windows. I'm not suggesting that one is better
:than the other; I'm just saying we have seen it done other ways before,
:maybe not under Tk or event under X (anybody know how Motify 2.0 implements
:drag and drop?), but under Windows and on the Mac.
Sun's Xview (OpenLook) does it with Cursor too - all be it a very big cursor
in some cases with fragment of moving window in it.
A Motif Drag&Drop code someone sent me also uses the cursor.
This was one of the main motivations for my patches that cause
Tk's 'grab' command to use the cursor of the grab window. With the
patch these cursor effects can be done with Tk.
n...@tiuk.ti.com
:What strikes me about the Motif drag-and-drop mechanism is how complex
:and limited the protocols are compared to a real language like Tcl.
:
:I see drag-and-drop like a telephone switchboard operator, connecting
:you (the drop source) with different parties (drop targets). After
:connecting, the two parties (source/target) manage the communication,
:not the operator.
:
:In the Tk "send" command, we have what seems to be the perfect
:mechanism for this. The protocol (Tcl) is powerful, yet compact. The
:drag-and-drop source and target can send Tcl commands back and forth
:to mediate their own data transfers. You dispose of the entire notion
:of data interchange types and formats.
:
:Now I'm all for Tk's drag-and-drop inter-operating with Motif,
:Windows, Mac, etc. drag-and-drop. But I'd hate to be limited to just
:that, when here in the Tk world we have something much more powerful.
Suggestion:
Use 'native' Motif/Windows/Mac Drag and Drop to "establish the
connection". This gives you inter-operation.
Then (talking X here because it is all I know) have one of TARGETS
selection types supported by the source be "TK_INTERP" or whatever
to allow any interaction you like via 'send' if both apps happen to
be Tk based.
Donal K. Fellows
>Sun's Xview (OpenLook) does it with Cursor too - all be it a very big cursor
>in some cases with fragment of moving window in it.
>
The performance of this is too bad for it to be a realistic option
(IMHO, in Tk at least - the window tends to lag so badly, it causes
usability problems...)
>A Motif Drag&Drop code someone sent me also uses the cursor.
>
Motif drag-and-drop uses shaped windows, and _hides_ the cursor. This
is the only way to obtain the multicolor effects that it uses. Also,
You can never pop an override-redirected window on top of an X cursor,
but you can do it on top of a Motif d+d `cursor'.
You can test this for yourself using:
toplevel .t
wm withdraw .t
wm overrideredirect .t 1
wm geometry .t 300x300+1+1
after 3000 {wm deiconify .t}
and a handy Motif app that supports drag-and-drop.
>This was one of the main motivations for my patches that cause
>Tk's 'grab' command to use the cursor of the grab window. With the
>patch these cursor effects can be done with Tk.
>
When the mouse button is help down, all (mouse, I haven't checked for
keyboard) events are communicated to the window which the button was
pressed in, and the cursor shape is controlled by what that window's
cursor configuration option is.
Olaf Schlueter
Donal> In article <OLAF.95Ju...@oski.oski>, Olaf Schlueter
Donal> <olaf@oski> wrote:
>> Resumee:
>> in a X environment, motif drag and drop protocol must be
>> supported.
>>
Donal> I've just been looking into this, but there are a number of
Donal> problems...
Donal> a) Whether or not to link with the Motif library. I
Donal> think we'd rather avoid this if we can (for a host of
Donal> reasons that I don't want to go into here)
Donal> b) Whether we want to run after a moving target. The
Donal> documentation I have on drag-and-drop for Motif says that
Donal> this is not especially stable, as there was mention of a
Donal> joint project between Sun and OSF to get d+d between
Donal> OopenLook and Motif apps. This is what we really want, but
Donal> I don't know the details of this. Mind you, my Motif docs
Donal> aren't exactly up to date... :^)
That's bad news. My intention was to implement the protocol of Motif
drag and drop, not its API. But if the protocol definition isn't
stable :-) Seems, that b) could be solved by linking with motif libs,
which would not make sense for a motif replacement.
Olaf Schlueter
Peter.DeRijk
: fell...@cs.man.ac.uk (Donal K. Fellows) wrote:
: >In article <3umr31$8...@shore.shore.net>, <wi...@spooky.rwwa.com> wrote:
: >> Come now, you're getting a little carried away. A window the same
: >> size and shape (yes shape) as a windows style D&D cursor won't
: >> obscure the target anymore than the cursor will.
: >
: >Wake me up when Tk can do that, but in the mean time I'll continue
: >using cursors...
: I don't think there's a clear winner regarding how to display the
: drag-and-drop token. I can think of three different approaches
: 1) window
: 2) cursor
: 3) xor-ing over the root window
: and each approach has its pluses and minuses.
Would it be possible to plot a colour bitmap on the screen (not
xor-ing), using backing-store to restore the original image. I don't
know X well enough to know if it's possible, but it would give the best of
all worlds:
It would be more light-weight than a window.
You can use large, coloured tokens.
You would have full control of the colour
Anybody know whether it would be feasable.
Peter
--
Peter De Rijk der...@uia.ua.ac.be
<a href="http://www-rrna.uia.ac.be/~peter/personal/peter.html">Peter</a>
To achieve the impossible, one must think the absurd.
to look where everyone else has looked, but to see what no one else has seen.
Donal K. Fellows
Olaf Schlueter <ol...@toppoint.de> wrote:
> Donal K. Fellows wrote:
>> In article <OLAF.95Ju...@oski.oski>, Olaf Schlueter
>>> Resumee:
>>> in a X environment, motif drag and drop protocol must be
>>> supported.
>>>
>>
>> a) Whether or not to link with the Motif library. I
>>
>
> That's bad news. My intention was to implement the protocol of Motif
> drag and drop, not its API. But if the protocol definition isn't
> stable :-) Seems, that b) could be solved by linking with motif libs,
> which would not make sense for a motif replacement.
>
All is not lost, since all my documentation on Motif dates from 1992
and 1993 and so, I believe, predates Motif 2. There is no chance of me
delving into Motif very deeply, (especially given my views on C :^)
but anyone else is welcome to have a closer look and come up with a
summary. I might even take some time to convert _that_ into a
bare-bones extension, but I haven't got the time to research the thing
properly.
About the only thing left to add to my drag-n-drop code now is hooks
for this sort of extension, and then I might make a proper release...
Donal K. Fellows
George A. Howlett <ghow...@fast.net> wrote:
>fell...@cs.man.ac.uk (Donal K. Fellows) wrote:
>>In article <3umr31$8...@shore.shore.net>, <wi...@spooky.rwwa.com> wrote:
>>> Come now, you're getting a little carried away. A window the same
>>> size and shape (yes shape) as a windows style D&D cursor won't
>>> obscure the target anymore than the cursor will.
>>
>>Wake me up when Tk can do that, but in the mean time I'll continue
>>using cursors...
>
>I don't think there's a clear winner regarding how to display the
>drag-and-drop token. I can think of three different approaches
>
> 1) window
> 2) cursor
> 3) xor-ing over the root window
>
>and each approach has its pluses and minuses.
>
>Using a window gives you the maximum flexibility in how to visually
>display the token. It can be as simple as a word of text or as
>complex as a full-color image. Token windows can, however, take a
>while to realize and map on slower hardware. And if the window is
>too large, it can obscure the user's view of target sites.
>
Not much we can do about the speed though - if you want multicolour
non-rectangular indicators, then under X you need to do some work...
>Cursors on the other hand can be very fast, especially if you have a
>hardware cursor. You can create tokens as simple outlines which you
>can see through (around), lessening the chance of obscuring a target
>site.
>
>Cursors also have limitations. You can only have one foreground and
>background color. Some X servers allow only relatively small cursors
>(16x16 pixels). It's harder to create or change tokens (especially
>from Tcl), because you need to generate a new bitmap (and a mask).
>
>This makes it hard to provide good visual cues. For example, you need
>another cursor to indicate when you're over a drop site and you need a
>couple more to indicate if the drop was good. Of course, many
>cursor-based implementations don't bother with this. But if you like
>the active background/foreground feature or Tk buttons and scrollbars,
>you'll understand how useful these visual cues are.
>
Providing visual clues is hard work anyway, and I don't think I've yet
used an X server which didn't let me use a cursor that was larger than
16x16. More info on this would be appreciated.
And you can do a lot with 2 colours, especially if you know that you
aren't stuck with black and white...
>Xor-ing over the root window (subwindow_mode set to IncludeInferiors)
>is slower than using cursors but it doesn't limit the size of the
>token. You really can't control the colors drawn. But it's
>relatively easy to generate the token (Xlib drawing procedures).
>
This reminds me of UI's from the early 80's. I think we can do better
than that...
>Right now, the drag-and-drop command in BLT uses windows. One of
>Michael's goals was to make blt_drag&drop simple, yet flexible. It
>gives the user a simple way to generate a token, without drastically
>limiting what the token can look like. The trade-off is that it can
>sometimes be slow and bulky. [BTW. Adding another approach (cursor,
>xor-ing) shouldn't be very hard.]
>
The token must be rectangular. That's quite a limitation... :^)
>The more interesting question is what drag-and-drop should be like.
>
>I take the slightly heretical view that interoperability with Motif,
>etc. is less important than a rich, powerful drag-and-drop mechanism.
>
Here, I think that we can have our cake and eat it. Motif d+d is
really quite good, but you need strong fingers to type in enough code
to use it properly...
I think that Tk drag-and-drop should be compatible Motif, even if this
is provided by an additional extension.
>Trouble is that the most common examples of drag-and-drop (Windows
>file manager, etc) are too simple. They don't do much more than
>transfer a filename or a text string. It's just a better way of doing
>selections. So they don't demonstrate the need for a more powerful
>drag-and-drop mechanism. Don't get me wrong. I like the feel of the
>Windows and Mac drag-and-drop. But if there was a decent shell and
>terminal window, I might use that instead to move, copy, and delete
>files/folders.
>
OK, wiseguy. What else would you transfer? (we can't really do binary
data without encoding it, so that messes things up a bit.)
>Drag-and-drop at its best, deals in abstract quantities. In a circuit
>simulator, I drop a circuit schematic on a graph and it displays the
>relevant waveforms. If you've never seen the program Simply3D, it
>lets you drag-and-drop complex items like objects, view ports, and light
>sources.
>
My mechanism can certainly handle that, though you'll need to define
your own data format... :^)
>What strikes me about the Motif drag-and-drop mechanism is how complex
>and limited the protocols are compared to a real language like Tcl.
>
Complex, yes. However, it isn't really limited as such. The real
problem is that most Motif apps don't have anything like send, due to
them being written in C or C++ (too much code already written by this
point, and no way to reall have scripts in it anyway)
>I see drag-and-drop like a telephone switchboard operator, connecting
>you (the drop source) with different parties (drop targets). After
>connecting, the two parties (source/target) manage the communication,
>not the operator.
>
This is all very well, but it puts a great onus on the programmers of
simple applications. I prefer to let the protocol handle a little
more, especially since one possible theng that could be transferred is
a connection... :^)
>In the Tk "send" command, we have what seems to be the perfect
>mechanism for this. The protocol (Tcl) is powerful, yet compact. The
>drag-and-drop source and target can send Tcl commands back and forth
>to mediate their own data transfers. You dispose of the entire notion
>of data interchange types and formats.
>
There is a big difference between what you can do with filename data
and textual data, and so you really still need some kind of type
system.
>Now I'm all for Tk's drag-and-drop inter-operating with Motif,
>Windows, Mac, etc. drag-and-drop. But I'd hate to be limited to just
>that, when here in the Tk world we have something much more powerful.
>
Tk is not much more powerful, as such, but it is a lot easier to get
applications that work together using Tk than it is with Motif.
John Chambers
>In article <3upjqo$p...@nn.fast.net>,
>George A. Howlett <ghow...@fast.net> wrote:
>>fell...@cs.man.ac.uk (Donal K. Fellows) wrote:
>This is all very well, but it puts a great onus on the programmers of
>simple applications. I prefer to let the protocol handle a little
>more, especially since one possible theng that could be transferred is
>a connection... :^)
Well, myself, the one major thing that I like about tcl/tk is that
I can program it. But then, I'm a programmer; I suppose I'm biased.
I like simple tools that do a single, well-defined job. Most of the
alternative approaches involve huge, complex monsters that try to do
everything for me, but I never quite understand what they are doing
or why. "Don't worry your little head about it; we'll take care of
the details for you" works when the details are what you want; if
they're not, you're outta luck.
>>In the Tk "send" command, we have what seems to be the perfect
>>mechanism for this. The protocol (Tcl) is powerful, yet compact. The
>>drag-and-drop source and target can send Tcl commands back and forth
>>to mediate their own data transfers. You dispose of the entire notion
>>of data interchange types and formats.
In attempting (successfully, I might add, with a bit of help from the
denizens of comp.lang.tcl) to implement drag&drop between a couple of
applications, I really only found one important thing missing. The
events are all passed to the owner of the "drag" window, while the
owner of the "drop" window sees no events. The only solution was to
have the owner of the drag window send messages to *all* possible
recipients (i.e., all tk applications), and have each of them test
the %X %Y coordinates to see if "That's one of my windows". This
is rather clumsy.
So IMHO the thing that's missing is a way of notifying the actual
recipient of the drop that the event has happened. There are several
ways I can imagine this being done.
For my applications, one simple solution would be to add yet another
bind variable. What it would contain would be the name of the process
that owns the target window, perhaps %O. It should be the string that
is to be used as the first arg to a "send" command. Then the owner of
a drag window could bind something like {send %O "Drop $object %X %Y"}
where $object was determined by the routine that handled the earlier
<Press> event.
This has a practical problem of using a lot of cpu, since every event
has to be intercepted by prog1, which has to do a send to prog2, which
has to wake up and process the send command. To make it even better,
it'd be nice if events (e.g., Enter, Motion and Release) would be given
to the owners of both windows. Then they could shake hands as soon
as the pointer entered a second window, and could come to a mutual
agreement about such things as what to draw for the cursor. And there
would be no need for cpu cycles inside prog1 after the pointer entered
prog2's window, unless there was a binding for an event.
Note that the latter extension doesn't require adding any new feeping
creatures to tcl/wish; it only requires making bindings work in both
applications. But as long as an application has done [bind . <Enter
...], it sorta makes sense that the lower-level code would honor the
binding, and tell it about Enter events. Suppressing <Enter> when
a button is down is a bit bizarre, no? And if only prog2 wants to
know about <Motion> events, why tell prog1 and not prog2 about them?
Mostly, I guess, I'm just suggesting that the binding mechanism be
made to work in a more straightforward manner: events should be
given to the owner of the window containing the pointer, if the
owner has bindings for the events. Currently this isn't true.
If prog1 and prog2 both have <ButtonPress-1> and <ButtonRelease-1>
bindings, and you press button 1 instide prog1's window and release
it inside prog2's window, only prog1's bindings are honored. This
strikes me as being simply a bug; if it were fixed, then most of
the discussion about drag&drop would be moot. The only thing needed
is a way that prog1 and prog2 can learn each others' names; the %O
mechanism above would take care of that.
>There is a big difference between what you can do with filename data
>and textual data, and so you really still need some kind of type
>system.
Well, now; I've never seen any problem with representing types via
textual data. Am I missing something?
In general, I see no value in trying to duplicate all of every
commercial GUI's drag&drop mechanism in tk. That would produce
a monster. Rather, we should continue the approach of building
simple, low-level tools that can be used to build the monsters.
Then when someone wants a particular flavor monster, we can tell
them to ftp it from someplace. No need to load wish down with
code to emulate every complicated package on every other system,
especially if you're using only one of them.
Andreas Leitgeb
: In attempting (successfully, I might add, with a bit of help from the
: denizens of comp.lang.tcl) to implement drag&drop between a couple of
: applications, I really only found one important thing missing. The
: events are all passed to the owner of the "drag" window, while the
: owner of the "drop" window sees no events. The only solution was to
: have the owner of the drag window send messages to *all* possible
: recipients (i.e., all tk applications), and have each of them test
: the %X %Y coordinates to see if "That's one of my windows". This
: is rather clumsy.
any mouse-events while dragging outside the clicked window.
(for example scrolling listboxes by dragging out of the bottom or top border)
so the only alternative I see is to introduce a new command like bind
or only a new option for bind, which tells it _not_ to grab the mouse
till a button-release ...
this would also preserve backwards-compatibility
and by the way: i can't think of ANY X-windows application that does _not_
automatically grab the mouse, when it leaves the window with a button
being depressed
and so i'm not even sure, whether the window-managers will allow
such a behaviour.
in case you need a drag&drop only within ONE tk-application,
you can calculate the current window under the dragging mouse
with sthg like: winfo containing [expr $x+[winfo rootx $w]] [...y]
where $w is the clicked window, and $x,$y are the %x and %y from the bind
(thus relative to the origin of the clicked window)
John Haxby
|> so the only alternative I see is to introduce a new command like bind
|> or only a new option for bind, which tells it _not_ to grab the mouse
|> till a button-release ...
|> this would also preserve backwards-compatibility
Even if it were a good idea, you cannot implement this since the grab is
part of the X11 protocol definition--I forget where in the X11 book it
says it, but it does say that the button release event goes to the same
window that got the button press event and gives some very good reasons
why this is so.
--
John Haxby J.H...@isode.com
ISODE Consortium +44 181 332 9091
These are my opinions and have nothing to do with my employer.
John Chambers
>In article <405i9s$s...@osiris.wu-wien.ac.at>, a...@csdec1.tuwien.ac.at (Andreas Leitgeb) writes:
>|> so the only alternative I see is to introduce a new command like bind
>|> or only a new option for bind, which tells it _not_ to grab the mouse
>|> till a button-release ...
>|> this would also preserve backwards-compatibility
>
>Even if it were a good idea, you cannot implement this since the grab is
>part of the X11 protocol definition--I forget where in the X11 book it
>says it, but it does say that the button release event goes to the same
>window that got the button press event and gives some very good reasons
>why this is so.
Minor logical quibble: While it's true that the release event generally
should go to the window where the press occurred, this does *not* mean
that it can't *also* go to to the window that contains the pointer. There
is no logical reason that an event can't be given to more than one window.
Granted, it may not be implemented in the low-level X libraries, but I
suspect that it is generally implementable in a higher-level library,
e.g., tk. All that is needed is for some routine in the stack to do
its level's equivalent of [winfo containing %X %Y], figure out which
process owns that window, and send it the event.
Of course, most processes wouldn't be interested in having something
dropped on them, and wouldn't know what to do with it. They can just
not have a release binding, or if they have one, to ignore it unless
there was an earlier press for the same button.
--
If the automobile industry had developed like the computer industry
over the past 30 years, a Rolls-Royce would now cost $5.00, would get
3000 miles to the gallon, and at random times would explode, killing
all its passengers.
George A. Howlett
: In article <3upjqo$p...@nn.fast.net>,: >I don't think there's a clear winner regarding how to display the
: >drag-and-drop token. I can think of three different approaches
: >
: > 1) window
: > 2) cursor
: > 3) xor-ing over the root window
: >
: >and each approach has its pluses and minuses.
: >Cursors also have limitations. You can only have one foreground and
: >background color. Some X servers allow only relatively small cursors
: >(16x16 pixels). It's harder to create or change tokens (especially
: >from Tcl), because you need to generate a new bitmap (and a mask).
: >
: >This makes it hard to provide good visual cues. For example, you need
: >another cursor to indicate when you're over a drop site and you need a
: >couple more to indicate if the drop was good. Of course, many
: >cursor-based implementations don't bother with this. But if you like
: >the active background/foreground feature or Tk buttons and scrollbars,
: >you'll understand how useful these visual cues are.
: Providing visual clues is hard work anyway, and I don't think I've yet
: used an X server which didn't let me use a cursor that was larger than
: 16x16. More info on this would be appreciated.
I can't remember what X servers I've seen where the cursor size was
limited to 16x16, but cursor limits do vary a lot. I have seen Sparc
2's running MIT X11R5 where the cursor can be no bigger than 32x32.
At home, my Linux box (running XFree 3.1.1 with a S3 964 card) can
support cursor sizes up to 64x64 (note that this is also at 116 dpi).
I don't know of any way of querying what is the maximum cursor size.
Having said all that, I think the limitation on cursor sizes is a
lesser problem. With a big cursor, users get easily confused as to
where the hot spot of the cursor is. Also big cursors tend to obscure
the drop targets (just like big windows).
You can also provide good visual cues and user feedback with cursors
(animated cursors come to mind). It's just not done at easily as with
windows because you're restricted to generating bitmaps.
: And you can do a lot with 2 colours, especially if you know that you
: aren't stuck with black and white...
Not if one of the cursor colors is the color of the window that the
cursor is over.
This is a lot bigger limitation. You'll notice how the standard X
cursors use their masks to create an outline around the cursor. So
even if the cursor passes over a window of the same color, it can
still be detected. It's easy to lose cursors, so in essence, you
really are limited to one color.
: >Xor-ing over the root window (subwindow_mode set to IncludeInferiors)
: >is slower than using cursors but it doesn't limit the size of the
: >token. You really can't control the colors drawn. But it's
: >relatively easy to generate the token (Xlib drawing procedures).
: >
: This reminds me of UI's from the early 80's. I think we can do better
: than that...
This is pretty amusing (I hope the irony was intended). After all,
we're talking about windows, cursors, drag-and-drop, etc. This *is*
the UI from the early 80's.
: >Right now, the drag-and-drop command in BLT uses windows. One of
: >Michael's goals was to make blt_drag&drop simple, yet flexible. It
: >gives the user a simple way to generate a token, without drastically
: >limiting what the token can look like. The trade-off is that it can
: >sometimes be slow and bulky. [BTW. Adding another approach (cursor,
: >xor-ing) shouldn't be very hard.]
: >
: The token must be rectangular. That's quite a limitation... :^)
This depends, I suppose, on your point of view. Yes, the shape of a
window must be rectangular (forgetting the SHAPE extension for a just
a minute). But what it can contain is virtually unlimited. Cursors
can take any shape, but their contents are limited to two (really one)
color. When the things I'm dragging have a well known icon (like a
folder), cursors seem best. When they're obscure and abstract like a
doping profile for a device simulator, windows seem like a good idea.
I simply maintain there's no clear winner regarding how to display the
drag-and-drop token.
--gah
Donal K. Fellows
The main problem that I've found with drag-and-drop with cursors and
windows together, is that the window lags behind the cursor and that
(at least in my experiments) it is possible to get the system's visual
indications confused by dragging onto the dragged window (I have hit
this problem on several OSs so I can't see an easy way round it that
doesn't cause massive flickering). Dropping still worked as it should
though.
> I simply maintain there's no clear winner regarding how to display the
> drag-and-drop token.
>
As far as I'm concerned, there is a clear winner for drag-and-drop
tokens, the shaped window (combined with hiding the cursor during the
operation). This is what is used in Motif and has exactly the right
effect (unless you have override-redirected windows positioning
themselves on top of the cursor on some non-user-generated event).
However, these aren't possible in Tk at the moment, so I'll stick with
cursors (letting the user define what size and colour they want) and
provide the hooks to allow them to have windows as well.
Of course, if X could handle many-coloured arbitrary-size cursors then
that would be what we'd be using...