#161 closed defect (fixed)
FloatingPane widget should use the Drag and Drop system's event hooks to handle movement
Reported by: | alex | Owned by: | cal |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | Widgets | Version: | 0.1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
see tests/dnd/test_dragmove.html for details on how this might be accomplished.
Change History (10)
comment:1 Changed 15 years ago by
comment:2 Changed 15 years ago by
Actually, drag handles should now be supported. Still, you'll probably need a custom dnd subclass to take care of constraints and what have you.
comment:3 Changed 15 years ago by
There is an exmaple page in tests/dnd/ that outlines how to use drag handles with the DnD system, and there is a similar example for "drag movmement". Right now it doesn't have explicit support for a lot of these kinds of things, but is easily extensible to support them.
Regards
comment:4 Changed 15 years ago by
i'm definately confused somewhere. the demo i assume you mean is in /tests/dnd/test_draghandle.html
it uses a 3 parameter version of dojo.dnd.HtmlDragSource?(): new dojo.dnd.HtmlDragSource?(lis[x], null, lis[x].firstChild);
but the function doesn't appear to actually have a 3 arg version in it's definition in /src/dnd/HtmlDragAndDrop.js line 12: dojo.dnd.HtmlDragSource? = function(node, type){
perhaps whoever checked in test_draghandle.html forgot to check in a new version of the dnd class? (it was added by alex in r1354)
that would make sense, since the test doesn't actually work for me as i woudl expect - each item is draggable by any part of it, but just by the first child as the code would suggest.
comment:5 Changed 15 years ago by
The patch Alex submitted included changes to support the 3 argument constructor however they were backed out and the example got left as cruft.
Implementing a drag source which uses a handle is trivial, and I've outlined the code a couple of times before:
function DragHandleSource (dragSource, dragObject, type) { this.domNode = dragSource; this.dragObject = dragObject; // register us dojo.dnd.DragSource.call(this); // set properties that might have been clobbered by the mixin this.type = type || this.domNode.nodeName.toLowerCase(); } DragHandleSource.prototype.onDragStart = function (e) { return new dojo.dnd.HtmlDragObject(this.dragObject, this.type); }
Personally I'm not keen on overloading the constructor to the 3 argument signature that was suggested, I don't think it's at all obvious. I'm much more in favour of committing the above snippet of code as a seperate object; readability and discoverability win over code size in my book.
comment:6 Changed 15 years ago by
how about a patch like this:
Index: HtmlDragAndDrop.js =================================================================== --- HtmlDragAndDrop.js (revision 1901) +++ HtmlDragAndDrop.js (working copy) @@ -12,6 +12,8 @@ dojo.dnd.HtmlDragSource = function(node, type){ if(node){ this.domNode = node; + this.dragObject = node; + // register us dojo.dnd.DragSource.call(this); @@ -22,7 +24,10 @@ dojo.lang.extend(dojo.dnd.HtmlDragSource, { onDragStart: function(){ - return new dojo.dnd.HtmlDragObject(this.domNode, this.type); + return new dojo.dnd.HtmlDragObject(this.dragObject, this.type); + }, + setDragHandle: function(node){ + this.dragObject = node; } });
so we don't overload the constructor, but can set a drag handle later. or maybe we should chnage the default constructor to act differently if an array appears as arg[0], in which case we treat it as a k=>v arg list and do named args. is that more dojo-ish?
comment:7 Changed 15 years ago by
Owner: | changed from [email protected]… to cal |
---|
comment:8 Changed 15 years ago by
Milestone: | 0.2release → 0.3release |
---|
comment:9 Changed 15 years ago by
Milestone: | 0.3release → 0.2.2release |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Dustin fixed this a few weeks ago.
there are a couple of problems with that - at least two features the drag/drop system doesn't have.
firstly, it seems like you can't specify a drag handle - that is, one node which is responsible for dragging another (the dragbar in the case of the floating pane). this would seem to be an easy addition, but i'm not sure quite where you'd want that functionality added - more args to dojo.dnd.HtmlDragSource?(), an entirely seperate method, a property on the handle node to say what it drags, a property on the drag tagret node to say where it's handle is, etc etc
secondly, i need to optionally constrain the drag region - an overrideable method or callback function which gets called just before an object is move, to validate the position it's being moved to. similarly, i'd need drag start hooks to record container size (in the case of the floating pane) and maybe drag end hooks (although they're unused right now, it might be useful for draggable docking toolbars where you're need to resort children upon drag end - but that seems the realm of a drop target's ondrop handler)