Re: [iSVG] "actuate" attribute on <i:drag> element

[Robin B. <ro...@kn...>]

On Friday 28 September 2001 16:08, Antoine Quint wrote:
> Kev (list-member !!!) suggested that it'd be nice to have the
> possibility to have drag changes applied when you click on the object
> rather than when you actually drag it.

This is totally necessary.

> What about doing something like:
>
> <i:drag actuate="onmousedown"> or <i:drag actuate="ondrag"> where
> "ondrag" would be the default value.

I think this is *not* going far enough. If possible -- and I think it is -- 
drag should be totally ignorant of how or why it is being selected.

What we want is an i:select module. The i:select module would be an 
intermediate between the selector (which is usually a mouse, but can also be 
for instance the key board: windows users, pick a non-fullscreen window, hit 
Alt+Space, arrow-down and select move, then move around with your arrow keys. 
Esc to stop, Enter to confirm. KDE users select move from the icon menu and 
do something similar. Other users do whatever) and the object, which we know 
can be anything but is taken care of by i:drag (in this case).

Having an i:select module would give us lots of benefits. First, it would 
take care of the actuate problem described above, which is likely to occur in 
other modules (buttons, pan, whatever). I would also allow us to do very 
nifty things like multiple selection.

An ugly but interesting example of this (for IE5+) is at 
http://www.microsoft.com/japan/developer/workshop/author/dhtml/dude/dude092298.asp 
. Forget the language (well, unless you can read it) and scroll down to 
"Drag-and-Resize example".

Right now multiple-selection would be painful to add to i:drag, and again 
we'd have to add it everywhere we need it.

Instead, any event occuring on an object that's part of the selection (stored 
in an dictionary by the i:select module) would be dispatched to all objects 
in the selection as if they were receiving it directly. For window-like 
objects we probably don't care too much, but for a drag-and-drop system 
(which is where i:drag is heading) it would be marvellous.

It would also take care of solving the problem of selecting overlapping 
objects. The default would be to take the one on top, but it could have an 
option to put up a menu (or something) listing the i:selectable object under 
the pointer, when there are several.

And of course, if we added new actuate styles, they'd be available to 
everything, and able to throw their own events (eg onfocus, which would be 
very cool for i:form if we decide to do it).

If any of you know some expert of GUI toolkits, I'd be interested in knowing 
how they do it there.

-- 
_______________________________________________________________________
Robin Berjon <ro...@kn...> -- CTO
k n o w s c a p e : // venture knowledge agency www.knowscape.com
-----------------------------------------------------------------------
Suicidal twin kills sister by mistake!