Hello, please take a look at http://test.reasonmaker.com/sort/ where I made some hacks to allow for nested sortables. I need a hierarchical, sortable list, so I hacked away. It generally works quite nicely, but: ( - The code needs my debug stuff and failed attempts removed ) - The code needs to be adapted to also work with vertical sortables. It probably breaks vertical sortables. Shouldn''t be too hard to fix. Some if(constraint) I guess. - It may break normal draggable / droppable stuff. Anyone wants to do tests is very welcome. [ Frankly, I am quite exhausted from making the changes so far. I need a break from this stuff. ] - Can someone check how/if this works in Safari? I don''t have a Mac unfortunately. - In IE, moving a LI from the upper UL to the lower (move slowly) moves the LI under the lower UL until it is appended to the lower UL. Don''t know how to fix this. Anyone? - Dragging a LI up/down so that it causes scrolling (see below) makes dragging also select text from there on. IE only problem. Again, anyone knows a fix? - MAJOR PROBLEM: Performance is BAD in Firefox. I tried some caching and stuff, but it still hogs the CPU and makes it jerky. It is very fluid in Opera and IE. The puzzle demo also makes the pieces jump when moving fast and the CPU goes way up for me, so I guess it is not just my code. But I am clueless on what the problem is and how to fix it. My first try with the Venkman profiler wasn''t that useful. I''ll try again. Features: - Nested sortables. - Dropping on empty lists. - Automatic scrolling when moving to the upper/lower window edge while dragging (I expect my lists to be long, so I need this). - Better switching of elements, works better for elements of different height. Major technical bits: - I had to switch the "coordinate system" to the document based one as now the Sortables are also droppables and thus position: relative and moving elements between them wouldn''t work otherwise. - The coordinates used for checking whether the draggable is hovering over a droppable are no longer the mouse coordinates, but the upper edge of the draggable on the mouse moving up and the lower edge on the mouse moving down. Easier and consistent movement of the element, especially when traversing nested sortables. - Two LI in a UL switch position, when the dragged LI has made enough room for the other LI (Position.overlap2() ). The old code doesn''t work well for LI with different sizes, too much confusing stacking. - Moving a LI into a different UL happens on entering the UL, not when a LI in the new UL is reached. Makes it easier to move the items, earlier feedback. - Made onChange work. - Fixed Event.stop to cancel bubbling in IE. OK, that is it for now, I probably forgot loads of stuff. Bring on the beating :-) Bye, Martin
On 26/07/05, Caleb Buxton <adbust@gmail.com> wrote: Thanks for having a look.> safari: it crashes.Bad.> It crashes every time after using it for a bit -- length of time and > usage inconsistentReally bad.> And its the loveliest of crashes -- it adds the default bookmarks bar > bookmarks onto my current set (thankfully didn''t overwrite them)Great nasty bad. I didn''t know I could write such code ;-) No message of any kind about the cause? A browser should never crash because of anything done on the page (safe out-of-memory). But even if this is a genuine browser bug, it doesn''t help if it doesn''t work. There are no new DOM manipulations in the code. If it crashes Safari, the sortables on the demo page should crash it as well (maybe after a longer time). The only thing I could change is the code that moves the LI around. Currently, if just adds the LI to the new location. Maybe cloning it, removing it from the old location and adding the clone at the new location will be more stable.> As for scrolling... It works going down, but not up.So Safari indeed messes up the clientY event property. There is code at line 600 of dragdrop.js to handle this, but I wasn''t sure if it is really needed, so it is disabled so far. I will enable it.> And then > eventually it just always scrolls down.That is acceptable. Eventually, the user get tired of scrolling and releases the button whereas everything snaps into place again :-) As for the speed of things: Is it fluid on Safari? How about Firefox? I still hope it is just my box that is messed up... Bye, Martin
Am 26.07.2005 um 07:09 schrieb Martin Bialasinski:> The only thing I could change is the code that moves the LI around. > Currently, if just adds the LI to the new location. Maybe cloning it, > removing it from the old location and adding the clone at the new > location will be more stable.Cloning/removing/adding is the same as insertBefore (which does this implicitly). Maybe some strange Safari bug? Thomas
I haven''t looked too much at the actual code, but there is a SortableTree Class coming soon to script.aculo.us <http://script.aculo.us>, I have been working on it here and there for about 2 weeks now and it is working very nicely in all browsers and most performance issues have been worked out. the tree is also collapsible! Thomas if you like you can post a link to any test versions that you have up so that everyone can get a sneak peek. It would be good to have some extra testers, I would post a link to my test versions but i have it on a work server right now and don''t have the time to move it somewhere else. Jesse> Message: 5 > Date: Tue, 26 Jul 2005 03:38:37 +0200 > From: Martin Bialasinski <klingeling@gmail.com> > Subject: [Rails-spinoffs] My try on nested sortables > To: Ruby Spinoffs List <rails-spinoffs@lists.rubyonrails.org> > Message-ID: <1f788d0b05072518382c474e19@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello, > > please take a look at http://test.reasonmaker.com/sort/ where I made > some hacks to allow for nested sortables. I need a hierarchical, > sortable list, so I hacked away. > > It generally works quite nicely, but: > > ( - The code needs my debug stuff and failed attempts removed ) > > - The code needs to be adapted to also work with vertical sortables. > It probably breaks vertical sortables. Shouldn''t be too hard to fix. > Some if(constraint) I guess. > > - It may break normal draggable / droppable stuff. Anyone wants to do > tests is very welcome. > > [ Frankly, I am quite exhausted from making the changes so far. I need > a break from this stuff. ] > > - Can someone check how/if this works in Safari? I don''t have a Mac > unfortunately. > > - In IE, moving a LI from the upper UL to the lower (move slowly) > moves the LI under the lower UL until it is appended to the lower UL. > Don''t know how to fix this. Anyone? > > - Dragging a LI up/down so that it causes scrolling (see below) makes > dragging also select text from there on. IE only problem. Again, > anyone knows a fix? > > - MAJOR PROBLEM: Performance is BAD in Firefox. I tried some caching > and stuff, but it still hogs the CPU and makes it jerky. It is very > fluid in Opera and IE. The puzzle demo also makes the pieces jump when > moving fast and the CPU goes way up for me, so I guess it is not just > my code. But I am clueless on what the problem is and how to fix it. > My first try with the Venkman profiler wasn''t that useful. I''ll try again. > > > Features: > > - Nested sortables. > - Dropping on empty lists. > - Automatic scrolling when moving to the upper/lower window edge while > dragging (I expect my lists to be long, so I need this). > - Better switching of elements, works better for elements of different > height. > > Major technical bits: > > - I had to switch the "coordinate system" to the document based one as > now the Sortables are also droppables and thus position: relative and > moving elements between them wouldn''t work otherwise. > > - The coordinates used for checking whether the draggable is hovering > over a droppable are no longer the mouse coordinates, but the upper > edge of the draggable on the mouse moving up and the lower edge on the > mouse moving down. Easier and consistent movement of the element, > especially when traversing nested sortables. > > - Two LI in a UL switch position, when the dragged LI has made enough > room for the other LI (Position.overlap2() ). The old code doesn''t > work well for LI with different sizes, too much confusing stacking. > > - Moving a LI into a different UL happens on entering the UL, not when > a LI in the new UL is reached. Makes it easier to move the items, > earlier feedback. > > - Made onChange work. > > - Fixed Event.stop to cancel bubbling in IE. > > > OK, that is it for now, I probably forgot loads of stuff. > > Bring on the beating :-) > > Bye, > Martin > > > ------------------------------ > > > ------------------------------ > > Message: 8 > Date: Tue, 26 Jul 2005 07:09:06 +0200 > From: Martin Bialasinski <klingeling@gmail.com> > Subject: Re: [Rails-spinoffs] My try on nested sortables > To: Ruby Spinoffs List <rails-spinoffs@lists.rubyonrails.org> > Message-ID: <1f788d0b05072522092a47728e@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 26/07/05, Caleb Buxton <adbust@gmail.com> wrote: > > Thanks for having a look. > > > safari: it crashes. > > Bad. > > > It crashes every time after using it for a bit -- length of time and > > usage inconsistent > > Really bad. > > > And its the loveliest of crashes -- it adds the default bookmarks bar > > bookmarks onto my current set (thankfully didn''t overwrite them) > > Great nasty bad. I didn''t know I could write such code ;-) No message > of any kind about the cause? > > A browser should never crash because of anything done on the page > (safe out-of-memory). But even if this is a genuine browser bug, it > doesn''t help if it doesn''t work. > > There are no new DOM manipulations in the code. If it crashes Safari, > the sortables on the demo page should crash it as well (maybe after a > longer time). > > The only thing I could change is the code that moves the LI around. > Currently, if just adds the LI to the new location. Maybe cloning it, > removing it from the old location and adding the clone at the new > location will be more stable. > > > As for scrolling... It works going down, but not up. > > So Safari indeed messes up the clientY event property. There is code > at line 600 of dragdrop.js to handle this, but I wasn''t sure if it is > really needed, so it is disabled so far. I will enable it. > > > And then > > eventually it just always scrolls down. > > That is acceptable. Eventually, the user get tired of scrolling and > releases the button whereas everything snaps into place again :-) > > As for the speed of things: Is it fluid on Safari? How about Firefox? > I still hope it is just my box that is messed up... > > Bye, > Martin > > > ------------------------------ > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails-spinoffs/attachments/20050726/795052cc/attachment.html
Sure can do: http://mir.aculo.us/stuff/test-tree/tree.html Note, this is not the most current version of this, i''ll try to put something up later. :) Thomas Am 26.07.2005 um 15:26 schrieb Jesse McPherson:> I haven''t looked too much at the actual code, but there is a > SortableTree Class coming soon to script.aculo.us, I have been > working on it here and there for about 2 weeks now and it is > working very nicely in all browsers and most performance issues > have been worked out. the tree is also collapsible! Thomas if you > like you can post a link to any test versions that you have up so > that everyone can get a sneak peek. It would be good to have some > extra testers, I would post a link to my test versions but i have > it on a work server right now and don''t have the time to move it > somewhere else. > > Jesse > > > Message: 5 > Date: Tue, 26 Jul 2005 03:38:37 +0200 > From: Martin Bialasinski <klingeling@gmail.com> > Subject: [Rails-spinoffs] My try on nested sortables > To: Ruby Spinoffs List < rails-spinoffs@lists.rubyonrails.org> > Message-ID: <1f788d0b05072518382c474e19@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello, > > please take a look at http://test.reasonmaker.com/sort/ where I made > some hacks to allow for nested sortables. I need a hierarchical, > sortable list, so I hacked away. > > It generally works quite nicely, but: > > ( - The code needs my debug stuff and failed attempts removed ) > > - The code needs to be adapted to also work with vertical sortables. > It probably breaks vertical sortables. Shouldn''t be too hard to fix. > Some if(constraint) I guess. > > - It may break normal draggable / droppable stuff. Anyone wants to do > tests is very welcome. > > [ Frankly, I am quite exhausted from making the changes so far. I need > a break from this stuff. ] > > - Can someone check how/if this works in Safari? I don''t have a Mac > unfortunately. > > - In IE, moving a LI from the upper UL to the lower (move slowly) > moves the LI under the lower UL until it is appended to the lower UL. > Don''t know how to fix this. Anyone? > > - Dragging a LI up/down so that it causes scrolling (see below) makes > dragging also select text from there on. IE only problem. Again, > anyone knows a fix? > > - MAJOR PROBLEM: Performance is BAD in Firefox. I tried some caching > and stuff, but it still hogs the CPU and makes it jerky. It is very > fluid in Opera and IE. The puzzle demo also makes the pieces jump when > moving fast and the CPU goes way up for me, so I guess it is not just > my code. But I am clueless on what the problem is and how to fix it. > My first try with the Venkman profiler wasn''t that useful. I''ll try > again. > > > Features: > > - Nested sortables. > - Dropping on empty lists. > - Automatic scrolling when moving to the upper/lower window edge while > dragging (I expect my lists to be long, so I need this). > - Better switching of elements, works better for elements of > different height. > > Major technical bits: > > - I had to switch the "coordinate system" to the document based one as > now the Sortables are also droppables and thus position: relative and > moving elements between them wouldn''t work otherwise. > > - The coordinates used for checking whether the draggable is hovering > over a droppable are no longer the mouse coordinates, but the upper > edge of the draggable on the mouse moving up and the lower edge on the > mouse moving down. Easier and consistent movement of the element, > especially when traversing nested sortables. > > - Two LI in a UL switch position, when the dragged LI has made enough > room for the other LI ( Position.overlap2() ). The old code doesn''t > work well for LI with different sizes, too much confusing stacking. > > - Moving a LI into a different UL happens on entering the UL, not when > a LI in the new UL is reached. Makes it easier to move the items, > earlier feedback. > > - Made onChange work. > > - Fixed Event.stop to cancel bubbling in IE. > > > OK, that is it for now, I probably forgot loads of stuff. > > Bring on the beating :-) > > Bye, > Martin > > > ------------------------------ > > > ------------------------------ > > Message: 8 > Date: Tue, 26 Jul 2005 07:09:06 +0200 > From: Martin Bialasinski <klingeling@gmail.com > > Subject: Re: [Rails-spinoffs] My try on nested sortables > To: Ruby Spinoffs List <rails-spinoffs@lists.rubyonrails.org> > Message-ID: < 1f788d0b05072522092a47728e@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 26/07/05, Caleb Buxton <adbust@gmail.com> wrote: > > Thanks for having a look. > > > safari: it crashes. > > Bad. > > > It crashes every time after using it for a bit -- length of time and > > usage inconsistent > > Really bad. > > > And its the loveliest of crashes -- it adds the default bookmarks > bar > > bookmarks onto my current set (thankfully didn''t overwrite them) > > Great nasty bad. I didn''t know I could write such code ;-) No message > of any kind about the cause? > > A browser should never crash because of anything done on the page > (safe out-of-memory). But even if this is a genuine browser bug, it > doesn''t help if it doesn''t work. > > There are no new DOM manipulations in the code. If it crashes Safari, > the sortables on the demo page should crash it as well (maybe after a > longer time). > > The only thing I could change is the code that moves the LI around. > Currently, if just adds the LI to the new location. Maybe cloning it, > removing it from the old location and adding the clone at the new > location will be more stable. > > > As for scrolling... It works going down, but not up. > > So Safari indeed messes up the clientY event property. There is code > at line 600 of dragdrop.js to handle this, but I wasn''t sure if it is > really needed, so it is disabled so far. I will enable it. > > > And then > > eventually it just always scrolls down. > > That is acceptable. Eventually, the user get tired of scrolling and > releases the button whereas everything snaps into place again :-) > > As for the speed of things: Is it fluid on Safari? How about Firefox? > I still hope it is just my box that is messed up... > > Bye, > Martin > > > ------------------------------ > > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails-spinoffs/attachments/20050726/e6b80276/attachment-0001.html
On 26/07/2005, at 11:26 PM, Jesse McPherson wrote:> I haven''t looked too much at the actual code, but there is a > SortableTree Class coming soon to script.aculo.usVery impressive! Great work on making it so feature complete. Combine this with the two rails acts and it would be killer. One suggestion for improvement (while I think of it): hovering over a collapsed node could expand the node to allow you to drop into a nested tree. - tim lucas
I''m trying to achieve a drag from one div to another. When trying to drag the li out of it''s div, the element is clipped by the width/height: http://www.ohhodom.com/MT/archives/images/drag.png Are there any known tricks to achieving this? I need a long list on the right-hand-side, to allow dragging to a long list on the left- hand-side. Cheers, Rob
Hi, You probably have overflow:hidden (or something like that) set on the DIVs. The browser will do as told: clip the dragged element. If I get the time I''ll address this in one of the next releases of script.aculo.us. It''s a bit involving because some serious DOM manipulation is necessary (like creating invisible mock elements and other arcane things). :) Thomas Am 27.07.2005 um 00:59 schrieb Rob Wills:> I''m trying to achieve a drag from one div to another. > > When trying to drag the li out of it''s div, the element is clipped > by the width/height: > > http://www.ohhodom.com/MT/archives/images/drag.png > > Are there any known tricks to achieving this? I need a long list > on the right-hand-side, to allow dragging to a long list on the > left-hand-side. > > Cheers, > > Rob > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >
> > You probably have overflow:hidden (or something like that) set on > the DIVs. > The browser will do as told: clip the dragged element. >I set the class of each of the list divs to ''scrolling''. .scrolling { overflow: auto; border: 1px solid #000; padding: 0; margin: 0; }