[google-web-toolkit commit] r369 - wiki

[codesite...@google.com]

Author: gwt.team.rdayal
Date: Tue Feb 6 13:43:39 2007
New Revision: 369

Modified:
wiki/DragAndDrop_RR.wiki

Log:
Edited wiki page through web user interface.

[Sandy McArthur]

Will this support using something other than the widget as the drag
indicator? The first place I'd use DnD is for one or more whole table
rows but they aren't widgets. The next best thing, at least
aesthetically IMO, is the summary view of the yui-ext project:

http://www.jackslocum.com/blog/2006/12/29/preview-drag-and-drop-enhancements-and-the-new-treepanel/

[mP]

There should be a factory method called whent he drag starts so the
deevloper can provide the widget that is being dragged.

I believe the dnd thing should send events to callbcks. It should not
be removing the dragged widget from its original place in the dom and
inserting it when it is dropped.

> http://www.jackslocum.com/blog/2006/12/29/preview-drag-and-drop-enhan...

[Jason Essington]

Not sure if this is the best place for these comments, but here goes...

My current usecase (which I do have a working implementation for)
allows multiple widgets to be selected (shift+click / ctrl+click)
then on drag start, begins dragging all of those widgets ... think
dual list with DnD support.

So it would be nice to have a DnD api that would somehow allow
multiple widgets to be dragged at once.

Also, it may be the case that you don't want to initially move the
widgets themselves, but rather an outline or some other
representation of the widget(s) being dragged to aid browser
rendering. I suppose the API should also somehow support that.

-jason

[Rajeev Dayal]

Hi,

Thanks for all of the comments, guys. Sorry about the state of the RR - as you could probably see, it was not completed as yet. But, it is nice that it has already stimulated some discussion.

@Sandy: I honestly had just thought about widgets as the drag indicator, but you do bring up a good point about table rows. In one of the code contributions that I have seen (in which I have encouraged the contributors to post to this group; the RR will contain a summary of their ideas), there is the idea of a Table which contains widgets. These widgets can be swapped with other widgets in the table by dragging and dropping. I am really hoping that the contributor posts to this group; it is far more instructive to see the demo. So, if you create a table which is 1 row x n columns, and each cell contains a widget, this table implementation would let you swap table rows, and would allow you to drag them outside of the table. But, this is really dumbing down the Table interface to support this feature, which is not the right thing to do. You have brought up a good point, and it needs to be thought about. Also, I will check out the link you have provided.

@Jason: I agree that we need to build in support for multiple selection/dragging multiple widgets. That would be slick, and it is probably going to be a feature that users of drag and drop will expect. I think you would be able to achieve the "outline" effect through a CSS style that applies to the widget when it is being dragged. Do you think it would be better to be more explicit about this?


@mP: I agree that the attaching/detaching idea should not be the only way that we implement drag and drop (if at all). I do not really see a need to do this. As you say, the detection of the dragging of one widget on top of another is the important point, in which case the widget below will receive and event. Also, can you elaborate a bit more on your Factory idea? I'm not sure that I understand it fully.


Rajeev

[Fred Sauer]

Here goes.

From the RR Goals:

• Allow any widget (meaning any class that extends Widget) which is visible on the screen to be dragged to any other position on the screen. This means that the Drag and Drop API must support making any existing widget "draggable".

Yes, but I would also like to be able to constrain the drag area to a panel smaller than the entire page (see demo here). I think containing the widget to a panel with "overflow: hidden" is more intuitive than allowing the draggable object to go anywhere in the browser window, but showing the international "no parking" symbol ( i.e. the circle with the slash through it). The user might be tempted to look for hidden drop zones where none exist.

Also, for the application developers:

1. "any existing widget" should mean that there is no Draggable class to extend or Draggable interface to implement.
2. Ideally we can even make a Widget draggable which does not implement SourcesMouseEvents.
   
3. Any existing Widget should be able to become a drop target. Again, no interface to implement or class to extend.
4. If the drop target Widget happends to be a Panel, then more complex drop operations are allowed.
   

• The styling of the widget should be configurable through CSS on its selection for dragging, while being dragged, and after its release

The behavior of the draggable widget as it relates to the DOM should be configurable (and ultimately customizable through class extension) for each of the phases:

• drag start
• while dragging
• just before dropping (i.e. while engaging a potential drop target)
• on drop
• on cancel/veto of the drop

Out of the box we can consider some standard 'behaviors' which are provided, e.g.

1. Widget stays at original location during drag; some placeholder (such as an outline box) is dragged around; widget snaps to final location on drop
2. Same, but a deep copy of the original widget is dragged around instead of the outline; should probably not be the default behavior as deep copy must be defined and side-effects understood
3. Widget is removed from original location on drag, is moved around, but will snap back to original location on cancel/veto
4. others?
   

The behaviors should also define what happens:

1. When engaging a simple drop target (e.g. trash can), how does the target react to indicate contact or engagement? Maybe define an effect from that new effect framework which has been proposed? :-)
2. When engaging more complex drop targets I'd like to see the option for a positioning box which indicates where the draggable Widget would drop if you were to let go of the mouse button. This mostly makes sense when dragging/moving widgets around an AbsolutePanel on within the members of say FlowPanel.

• Events on the widget being dragged should fire at the start of the drag, during the drag itself, and at the end of the drag
  

Should we have a separate drag canceled event?

• Other widgets (if they so choose) should fire off events whenever a dragged widget has entered the other widget's boundaries, whenever a dragged widget has left the other widget's boundaries, and whenever the dragged widget is dropped on top of the other widget

I would include events when the dragged widget is moved while within the other widget's boundaries to support drag-and-move.

• The event implementation should follow the event-related patterns that are already present in GWT

There's another thread which talks about revamping and deprecating the current event handling in the core GWT classes and using Handler objects which are more future proof. Depending on where that discussion goes we may need both the old and new APIs, assuming there's a new Handler mechanism.

• Provide default implementations/styles of the most common drag and drop use cases

Agreed, we should have something more than say TabPanel has today, which doesn't look like tabs until you add your own CSS.

Do any of the GWT modules today provide additional default CSS which can be added by the application if they need it? I'm thinking here that you could have two CSS files. One is automatically included via the stylesheet tag in the dnd module .gwt.xml file while the other is available in the jar, but not automatically included unless explicitly specified in the application .gwt.xml file.

• Optimizations are important - an implementation of drag and drop that performs poorly is not a useful implementation. We must be sure that:
• The performance of widgets which are not participating in either being dragged, or reacting to a widget being dragged over top of itself should not be impacted by other widgets participating in a drag/drop interaction
• Bounds checking to detect whether or not a widget is on top of another widget must be implemented carefully as to avoid performance problems

Where possible it would be nice to use the browser event object to detect which objects are being targeted. This is straightforward on the drag and move by intercepting mouse events, but doesn't really work on the drop side.

On 2/6/07, Rajeev Dayal < rda...@google.com> wrote:

@Sandy: I honestly had just thought about widgets as the drag indicator, but you do bring up a good point about table rows. In one of the code contributions that I have seen (in which I have encouraged the contributors to post to this group; the RR will contain a summary of their ideas), there is the idea of a Table which contains widgets.[...]

I agree that table rows are important. Maybe we can deal with them via a special 'behavior'. A few considerations:

1. Need to recognize mouse events on the table row - need GWT hooks there if we want to avoid the application developer from extending a special DraggableTable class.
   
2. Need to support the various 'behaviors' during table row drag:
• table row removed and moved to a temporary single row draggable table?
• table row duplicated in the temporary single row draggable table
• some representation of the table row is dragged

@Jason: I agree that we need to build in support for multiple selection/dragging multiple widgets. That would be slick, and it is probably going to be a feature that users of drag and drop will expect. I think you would be able to achieve the "outline" effect through a CSS style that applies to the widget when it is being dragged. Do you think it would be better to be more explicit about this?

Definitely want this.

@mP: I agree that the attaching/detaching idea should not be the only way that we implement drag and drop (if at all). I do not really see a need to do this. As you say, the detection of the dragging of one widget on top of another is the important point, in which case the widget below will receive and event. Also, can you elaborate a bit more on your Factory idea? I'm not sure that I understand it fully.

See behaviors idea above, with some standard behaviors and (class/behavior) extensibility.

Fred

[Rajeev Dayal]

@Fred:

There is modified version of the RR that I just posted (still not complete, but more updated). Some of the goals are a bit clearer.

I think that having a constrained area for a widget to be dragged is a good idea. What would be the best way to implement this? With the API suggested by the goals, would you create a drop target for a draggable widget which is an encompassing panel, and then take advantage of the onDraggableWidgetLeave() event (made up name) of the drop target to prevent the widget from being dragged outside the bounds of the panel?

I agree with nearly all of your points for the Application Developers, although I think that the implementation of the drop operations is the same whether the drop target is a widget or a panel. In either case, you are going to be using the
onDraggableWidgetDrop() event to "do something" once the widget is dropped. Maybe you are talking about more interesting default behaviors in the case that a widget is dropped on a panel instead of another widget? Could you give me an example?

I agree with your point about the behavior of the widget being configurable through the different phases of drag; the updated RR reflects this.

As for the standard behaviors - I think that these are a good set to start with. However, the ending behavior (snap back, stay in new location, etc) also implies that these are standard behaviors with a draggable widget and some sort of encompassing panel being used as the drop target. This ties in with our statement about the behaviors defining what happens. We basically need both default draggable behaviors for widgets, and default droppable behaviors for other widgets. I can almost sense a "vulnerability" in the API at this point. The droppable behaviors for one widget/panel are unlikely to work as the droppable behavior of another widget/panel, but the API would probably let you use the same droppable implementation for two different widgets (both implementations may implement DropListener(), for example)! .

We definitely need some sort of "positioner" to indicate where the target will be dropped in the case of more complex drop targets. The problem is that this can be difficult to implement in all cases, as it does not generalize well (correct  me if I am wrong). For example, with the FlowPanel, you have to figure out where the browser would place the next widget that is added to the panel. We need to come up with a specific list of where we will support positioners. For DnD within Trees and Tables, we definitely need positioners.

DragCancelled is an interesting idea, but how do we detect that a drag was cancelled? Does this mean that you released the mouse button over an area that is not a drop target?

Can you tell me more about what you mean by "drag and move"? I am sorry, I am not familiar with the terminology.

I'm going to check out that thread RE Event Handling that you were talking about. Maybe we can take this chance to be more futuristic!

Right now, I do not think that GWT provides any sort of additional default CSS. There is definitely talk of needing something like this (think "themes"), as the TabPanel example makes clear. Your idea about including additional default CSS via the application module XML is an interesting one. A couple other GWT members are working more heavily with CSS; I'll mention this idea to them and see what they think. Most likely, this is going to be in their scope, but not in ours.

As for DnD in tables - we definitely need to look at how we can hook mouse events at the level of a table row (or, hook mouse events on the entire table, and then delegate to the appropriate row). As for behaviors, I was thinking:

- when you drag a table row above another table row, the dragged row is inserted right above the other table row
- when you drag a table row outside a table, create a 1-row table (what you said)
- support for dragging individual widgets inside and outside of table, with table cells acting as drop targets


Rajeev

[chung]

Hi guys,

I've been working on my own independent framework for drag and drop.
I'll put it up on a Google Hosted Project in the near future, but for
now you can see a demo here:

http://dragdrop.grapier.googlepages.com/DragDrop.html

It's not quite as cool as Fred's awesome demo, but it has a good deal
of stuff. Specifically, it contains what Rajeev was referring to: a
table with widgets that you can reposition by drag-and-drop.

Enjoy!

Chung

> widgets (both implementations may implement DropListener(), for example).

> > > - Allow any widget (meaning any class that extends Widget) which

> > > is visible on the screen to be dragged to any other position on the screen.
> > > This means that the Drag and Drop API must support making any existing
> > > widget "draggable".
>
> > Yes, but I would also like to be able to constrain the drag area to a

> > panel smaller than the entire page (see demo here<http://code.google.com/p/gwt-dnd/>).

> > I think containing the widget to a panel with "overflow: hidden" is more
> > intuitive than allowing the draggable object to go anywhere in the browser
> > window, but showing the international "no parking" symbol ( i.e. the
> > circle with the slash through it). The user might be tempted to look for
> > hidden drop zones where none exist.
>
> > Also, for the application developers:
>

> > 1. "any existing widget" should mean that there is no Draggable

> > class to extend or Draggable interface to implement.

> > 2. Ideally we can even make a Widget draggable which does not
> > implement SourcesMouseEvents.
> > 3. Any existing Widget should be able to become a drop target.

> > Again, no interface to implement or class to extend.

> > 4. If the drop target Widget happends to be a Panel, then more

> > complex drop operations are allowed.
>

> > > - The styling of the widget should be configurable through CSS on

> > > its selection for dragging, while being dragged, and after its release
>
> > > The behavior of the draggable widget as it relates to the DOM should be
> > configurable (and ultimately customizable through class extension) for each
> > of the phases:
>

> > - drag start
> > - while dragging
> > - just before dropping (i.e. while engaging a potential drop target)
> > - on drop
> > - on cancel/veto of the drop

>
> > Out of the box we can consider some standard 'behaviors' which are
> > provided, e.g.
>

> > 1. Widget stays at original location during drag; some placeholder

> > (such as an outline box) is dragged around; widget snaps to final location
> > on drop

> > 2. Same, but a deep copy of the original widget is dragged around

> > instead of the outline; should probably not be the default behavior as deep
> > copy must be defined and side-effects understood

> > 3. Widget is removed from original location on drag, is moved

> > around, but will snap back to original location on cancel/veto

> > 4. others?

>
> > The behaviors should also define what happens:
>

> > 1. When engaging a simple drop target (e.g. trash can), how does the

> > target react to indicate contact or engagement? Maybe define an effect from
> > that new effect framework which has been proposed? :-)

> > 2. When engaging more complex drop targets I'd like to see the

> > option for a positioning box which indicates where the draggable Widget
> > would drop if you were to let go of the mouse button. This mostly makes
> > sense when dragging/moving widgets around an AbsolutePanel on within the
> > members of say FlowPanel.
>

> > > - Events on the widget being dragged should fire at the start of

> > > the drag, during the drag itself, and at the end of the drag
>
> > > Should we have a separate drag canceled event?
>

> > > - Other widgets (if they so choose) should fire off events

> > > whenever a dragged widget has entered the other widget's boundaries,
> > > whenever a dragged widget has left the other widget's boundaries, and
> > > whenever the dragged widget is dropped on top of the other widget
>
> > I would include events when the dragged widget is moved while within the
> > other widget's boundaries to support drag-and-move.
>

> > > - The event implementation should follow the event-related

> > > patterns that are already present in GWT
>
> > There's another thread which talks about revamping and deprecating the
> > current event handling in the core GWT classes and using Handler objects
> > which are more future proof. Depending on where that discussion goes we may
> > need both the old and new APIs, assuming there's a new Handler mechanism.
>

> > > - Provide default implementations/styles of the most common drag

> > > and drop use cases
>
> > Agreed, we should have something more than say TabPanel has today, which
> > doesn't look like tabs until you add your own CSS.
>
> > Do any of the GWT modules today provide additional default CSS which can
> > be added by the application if they need it? I'm thinking here that you
> > could have two CSS files. One is automatically included via the stylesheet
> > tag in the dnd module .gwt.xml file while the other is available in the jar,
> > but not automatically included unless explicitly specified in the
> > application .gwt.xml file.
>

> > > - Optimizations are important - an implementation of drag and drop

> > > that performs poorly is not a useful implementation. We must be sure that:

> > > - The performance of widgets which are not participating in

> > > either being dragged, or reacting to a widget being dragged over top of
> > > itself should not be impacted by other widgets participating in a drag/drop
> > > interaction

> > > - Bounds checking to detect whether or not a widget is on

> > > top of another widget must be implemented carefully as to avoid performance
> > > problems
>
> > > Where possible it would be nice to use the browser event object to
> > detect which objects are being targeted. This is straightforward on the drag
> > and move by intercepting mouse events, but doesn't really work on the drop
> > side.
>
> > On 2/6/07, Rajeev Dayal < rda...@google.com> wrote:
>
> > > @Sandy: I honestly had just thought about widgets as the drag indicator,
> > > but you do bring up a good point about table rows. In one of the code
> > > contributions that I have seen (in which I have encouraged the contributors
> > > to post to this group; the RR will contain a summary of their
>

> ...
>
> read more »

[gwt.team.rdayal]

Hi,

I have created a new thread in GWT Users:

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/d2e7f7c1ea93e423

Discussions with regard to use cases (things that we want drag and
drop to do/not do) should continue on this thread. I think that the
functionality of drag-and-drop is more of a user-facing problem. We
can keep the API discussions (which are more of a contributor-facing
problem) going on this thread.

Thanks,
Rajeev

[Jason Essington]

Just to keep things a bit together, here's another GWT implemented
DnD demo
http://jason.essington.googlepages.com/DualList.html

This one required a bit of hacking on ClickListener to get
onShiftClick, onCtrlClick and onDblClick events. <- that of course is
a discussion for another thread.

But this demo shows my primary DnD use case ... Multiple widget drag,
specified drop zones that can refuse to accept particular types of
widgets being dragged (not well demonstrated here) and auto canceling
of a drag when attempting to drop somewhere invalid.

-jason

[mP]

The way I did my dnd support was making all the different phases int
he dnd process events.
By making lots of stuff an event listeners can change the behaviour of
any part of the dnd process.

onClicked
listeners can control just how many widgets are selected.

onBeforeStart
listeners can veto if they dont want the widget to be dragged now.
onStart
when dragging has started.

onBeforeMove
whenever the widget is about to be moved. listeners can veto a
movement. This allows one to force a widget not to leave a zone.
onMove
after the widget has been moved. Listeners can use this event to
highlight a target drop zone if the mouse is hovering over it. Whyen
the widget moves again the same listener can cleanup and highlight
something else etc.

onBeforeDrop
listeners can veto if they dont want to the widget to be dropped.
onDrop
when the widget is dropped.

[mP]

> listeners can veto if they dont want to the widget to be dropped right now.

> onDrop
> when the widget is dropped.

onDropCancelled
if a widget is dropped on the wrong spot.

[Jason Essington]

I think that the events should probably work similarly to the way the
event system in Effects works ... using the handler pattern previously
discussed.

There are obviously several existing implementations at this point.
The trick is working out what the api should look like, then taking
what the different implementations have learned to make one really
complete implementation.

my implementation fires the following events:

onPreDrag (used to disable some default browser behavior)
onDragStart (fired before the first onDrag event to prepare the widget
for dragging)
onDragOver (fired when an item is dragged over something that could be
a drop target)
onDrag (Correlates directly to onMouseMove)
onDragOut (fired when the iterm is no longer over the drag target)
onDrop (fired when the item is dropped)
onCancelDrag (fired rather than onDrop when an item is dropped in an
invalid location)
onPostDrag (fired after widgets have been dropped or canceled to
reset certain browser default behavior)

This many different events are probably overkill, but at the time they
seemed to be the best way to handle the issues I ran up against while
working on my implementation.

The code I have is quite ugly, and not fit for use as a proper GWT
implementation, but there are some gems in it for dealing with some
platform specific weirdness.

What events do the other implementations fire?
Which ones do we really need?

-jason

[Fred Sauer]

On 2/8/07, Jason Essington <jason.e...@gmail.com> wrote:

What events do the other implementations fire?

On the drag controller side (which controls the draggable widgets) I
currently have events which deal with the drag and drop action as a
whole:onPreventDragStart
(essentially onPreDragStart)
onDragStart
onPreventDrop (essentially onPreDrop)
onDrop

On the drop controller side (which control the drop targets) I have:
onEnter (as the draggable engages a potential drop target)
onMove (moving around after engaging the target)
onLeave (the engagement ends without a drop)
onDrop (the drop actually happens)

[Luc Claes]

> What events do the other implementations fire?
> Which ones do we really need?

Our implementation fires the following events:

* DragSource
boolean onDragStart (vetoable by return value)

* DropTarget
void onDragEnter();
void onDragOver();
void onDragLeave();
void onDragFreeze(); called when the cursor stays motionless for a
certain amount of time above a droptarget - usefull to open
automatically a tree node for example.
void onDrop(List objects, int nDropAction);

Furthermore, the drag & drop manager uses, amongst other functions,
the following ones:
* DragSource
List getDraggedObjects();
Widget getDraggedWidget(); --> the widget moving with the cursor.
Could be a drag source clone, or whatever.

* DropTarget
boolean canAccept(List objects, int nDropAction); --> this is not
strictly an OnPreDrop. Could be called at onDragStart time to pre-
select some drop targets.

The drag&drop protocol in itself doesn't make any assumptions about
the logically dragged objects (generally, Model part of MVC)

[Rajeev Dayal]

Jason,

Thanks for putting this together. Nothing better to describe a use case than a specific example :).

Rajeev

On 2/8/07, Jason Essington <jason.e...@gmail.com> wrote:

[Rajeev Dayal]

Hey Jason,

In this case, is onPreDrag basically a preview of the onDragStart event?


Rajeev

On 2/8/07, Jason Essington < jason.e...@gmail.com> wrote:

[Rajeev Dayal]

This is definitely the right approach.

On 2/8/07, mP <miroslav...@gmail.com> wrote:

[Rajeev Dayal]

Hey Luc,

I took a look at your demo - pretty cool stuff!

So, your DragSource does not fire any sort of onDrag() event that correlates with onMouseMove. Is there a default behavior for a dragged object?

I understand what DragSource and DropTarget do, but how are you using the Drag and Drop Manager?


Rajeev

[Jason Essington]

sorta...

Actually, my code for this one is really ugly, so the events that
I've mentioned may not be relevant at all ...

But, onPreDrag is fired onMouseDown, onDragStart is not fired until
the first onMouseMove() and just prior to the first onDrag()

Then onMouseUp, either onDrop() or onCancelDrag() is fired, followed
by onPostDrag()

onPreDrag and onPostDrag are not really even events, but rather hooks
used for disabling and re-enabling some browser specific drag/select
behavior ... did I mention that this code was ugly? These methods
really should have never been part of that interface.

-jason

[Fred Sauer]

I've updated the gwt-dnd demo (http://code.google.com/p/gwt-dnd/) to allow you to select between alternate drag behaviors at runtime. I need to add more behaviors, but for now I have:

Classic: widget is directly draggable
Proxy: a separate proxy widget is dragged

The other most recent addition to the demo is that of a NoOverlapDropController, which allows you to place widgets next to each other, but does not allow them to overlap.

Fred

[gwt.team.rdayal]

Hey Jason,

Thanks for the clarification.

I was wondering, since some widgets can both have an onClick event and
can also be draggable, would the onPreDrag/onPostDrag interfere with
the onClick behavior? What is some of the browser-specific behavior
that you are modifying with these hooks?

Rajeev

On Feb 12, 2:32 pm, Jason Essington <jason.essing...@gmail.com> wrote:
> sorta...
>
> Actually, my code for this one is really ugly, so the events that
> I've mentioned may not be relevant at all ...
>
> But, onPreDrag is fired onMouseDown, onDragStart is not fired until
> the first onMouseMove() and just prior to the first onDrag()
>
> Then onMouseUp, either onDrop() or onCancelDrag() is fired, followed
> by onPostDrag()
>
> onPreDrag and onPostDrag are not really even events, but rather hooks
> used for disabling and re-enabling some browser specificdrag/select
> behavior ... did I mention that this code was ugly? These methods
> really should have never been part of that interface.
>
> -jason
>
> On Feb 12, 2007, at 11:44 AM, Rajeev Dayal wrote:
>
> > Hey Jason,
>
> > In this case, is onPreDrag basically a preview of the onDragStart
> > event?
>
> > Rajeev
>

> > On 2/8/07, mP < miroslav.poko...@gmail.com> wrote:
>
> > > On Feb 9, 1:43 pm, "mP" <miroslav.poko...@gmail.com > wrote:
> > > > The way I did my dnd support was making all the different
> > phases int
> > > > he dnd process events.
> > > > By making lots of stuff an event listeners can change the
> > behaviour of
> > > > any part of the dnd process.
>
> > > > onClicked
> > > > listeners can control just how many widgets are selected.
>
> > > > onBeforeStart
> > > > listeners can veto if they dont want the widget to be dragged
> > now.
> > > > onStart
> > > > when dragging has started.
>
> > > > onBeforeMove
> > > > whenever the widget is about to be moved. listeners can veto a
> > > > movement. This allows one to force a widget not to leave a zone.
> > > > onMove
> > > > after the widget has been moved. Listeners can use this event to

> > > > highlight a targetdropzone if the mouse is hovering over it.

[gwt.team.rdayal]

Hey all,

I have removed the RR for Drag and Drop from the Wiki, as it was not a
good example of an RR. The RR was incomplete, and looked more along
the lines of 'musings on how we want Drag and Drop to work', which is
exactly what this thread is for (along with the other thread on the
users group). The Wiki should only contain relatively complete
documents (subject to refinement, of course).

Once we have fleshed out most of the API ideas (and functionality
ideas on the other group), then I will put together a complete RR and
post it.

Let me know if you have any questions, and I am sorry for the
confusion.

Rajeev

[Jason Essington]

Re onclick

On Feb 15, 2007, at 11:11 AM, gwt.team.rdayal wrote:

> Thanks for the clarification.

no problem.

> I was wondering, since some widgets can both have an onClick event and
> can also be draggable, would the onPreDrag/onPostDrag interfere with
> the onClick behavior?

Nope, it didn't seem to. My demo, shows that I use both onClick and
onDblClick in addition to the DnD behavior.

> What is some of the browser-specific behavior
> that you are modifying with these hooks?

The default drag (text selection) behavior on some browsers (IE)
can't be suppressed with a regular call to DOM.eventPreventDefault()
or DOM.eventCancelBubble(). The only way to suppress it was to use
some JSNI to return false from the $doc.body.ondrag and
$doc.body.onselectstart functions.

-jason

[Alexino [pleyo.com]]

Hello everybody,

Just to announce an (other) developer is working on a Drag and Drop, I
created a groups and a code.google so that you can DL it:
http://code.google.com/p/dragmovedrop/

I'm just working everyday on it, 10hours per days, and I think I'm
making something really huge, so that it can answer all use cases,

Alex Gorisse