Hi Guys, Thomas particularly. I posted some time ago about a prob I was having where small sortables tended to jump around when I was sorting them with the mouse. I''ve done a bit more digging and narrowed the problem down to a better example. I will get an online ver up today if I get time, but I have a div containing many other divs. Inside each of these ''row'' divs, there are left floated divs with fixed widths (columns). The height of the row divs is what seems to matter. *Below 30px*, the issue occurs, once I increase the height to above 30px, the problem goes away. The problem exists in* both IE and FF*. As I drag a row up, above another row, it seems to swap position on every alternate pixel. On one pixel, it will be below the target (element I am dragging the selected row above) element, on the next, above it. *This only occurs when droponempty:true* If I turn dropOnEmpty to false, or increase the sortable row height, the problem disappears completely. I''m not sure whats going on, but it seems to be an error in the drop on empty code, that only rears with floatable divs and small height sortables. Fairly edge case but I''ve dug into the code and not having much luck following it. I will get a working example up asap, but until then- any suggestions? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Quite predictably my demo doesnt suffer from the problem. Maybe it''s the (gasp) nested sortables. I''ll build this in and see if I can get my test case to replicate the problem. Gareth On 6/1/07, Gareth Evans <agrath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Hi Guys, Thomas particularly. > > I posted some time ago about a prob I was having where small sortables > tended to jump around when I was sorting them with the mouse. > I''ve done a bit more digging and narrowed the problem down to a better > example. > I will get an online ver up today if I get time, but > > I have a div containing many other divs. Inside each of these ''row'' divs, > there are left floated divs with fixed widths (columns). > The height of the row divs is what seems to matter. > *Below 30px*, the issue occurs, once I increase the height to above 30px, > the problem goes away. > The problem exists in* both IE and FF*. > > As I drag a row up, above another row, it seems to swap position on every > alternate pixel. > On one pixel, it will be below the target (element I am dragging the > selected row above) element, on the next, above it. > *This only occurs when droponempty:true* > If I turn dropOnEmpty to false, or increase the sortable row height, the > problem disappears completely. > I''m not sure whats going on, but it seems to be an error in the drop on > empty code, that only rears with floatable divs and small height sortables. > Fairly edge case but I''ve dug into the code and not having much luck > following it. > > I will get a working example up asap, but until then- any suggestions? >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
any update on this? I am having exactly the same problem. I have two Div containers, one on top of the other, where you can drag from on to the other. Each div is large enough for 5 images to fit on one line. With less than 5 images, dragging and dropping is a pleasure, with everything looking great. However above 5 images in one container forces the images on to two rows, and then dragging problems start. The top row is still perfectly fine, but the second row and below it is very difficult to drag your image where you want it to land, due to constantly alternating drop positions every pixel you move... This problem only occurs with dropOnEmpty set to true, yet I must have the ability to empty these lists. help :D --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
My problem, while related to dropOnEmpty as well seems to only occur when my sortables are nested, which is why I can''t replicate it on my test page. I''ve been meaning to update my test page to prove it so I have a clean page to debug from within, that I can post up (it''s really hard to post up an internal [read:burried] page of a web application. I think there might be issues in the dropOnEmpty code. Perhaps we should team up to debug the solution at some point, What Instant Messaging tools do you use? On 6/13/07, junkmate <junkmate-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > any update on this? I am having exactly the same problem. > > I have two Div containers, one on top of the other, where you can drag > from on to the other. > Each div is large enough for 5 images to fit on one line. > > With less than 5 images, dragging and dropping is a pleasure, with > everything looking great. However above 5 images in one container > forces the images on to two rows, and then dragging problems start. > The top row is still perfectly fine, but the second row and below it > is very difficult to drag your image where you want it to land, due to > constantly alternating drop positions every pixel you move... > > This problem only occurs with dropOnEmpty set to true, yet I must have > the ability to empty these lists. > > help :D > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Okay, got a replication in an example page! http://202.49.89.140/SortableExample.html Drag the ''fejoa'' item upwards very slowly, one pixel at a time. In Firefox; the problem doesn''t occur in the test page.. but in IE(7) it does. In my actual application, the problem occurs in both (just verified) Its definitely related to nested sortables, floats and dropOnEmpty but I can''t find the exact combination to get true cross-browser buggyness. Gareth On 6/13/07, Gareth Evans <agrath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > My problem, while related to dropOnEmpty as well seems to only occur when > my sortables are nested, which is why I can''t replicate it on my test page. > I''ve been meaning to update my test page to prove it so I have a clean page > to debug from within, that I can post up (it''s really hard to post up an > internal [read:burried] page of a web application. > I think there might be issues in the dropOnEmpty code. > > Perhaps we should team up to debug the solution at some point, > What Instant Messaging tools do you use? > > > On 6/13/07, junkmate <junkmate-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > any update on this? I am having exactly the same problem. > > > > I have two Div containers, one on top of the other, where you can drag > > from on to the other. > > Each div is large enough for 5 images to fit on one line. > > > > With less than 5 images, dragging and dropping is a pleasure, with > > everything looking great. However above 5 images in one container > > forces the images on to two rows, and then dragging problems start. > > The top row is still perfectly fine, but the second row and below it > > is very difficult to drag your image where you want it to land, due to > > constantly alternating drop positions every pixel you move... > > > > This problem only occurs with dropOnEmpty set to true, yet I must have > > the ability to empty these lists. > > > > help :D > > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Heres my test page: http://www.oldsushi.com/testing.php Going there make your browser small enough so the images are on two lines, and you will see the problem when dragging around the second line and below. On Jun 12, 11:10 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> My problem, while related to dropOnEmpty as well seems to only occur when my > sortables are nested, which is why I can''t replicate it on my test page. > I''ve been meaning to update my test page to prove it so I have a clean page > to debug from within, that I can post up (it''s really hard to post up an > internal [read:burried] page of a web application. > I think there might be issues in the dropOnEmpty code. > > Perhaps we should team up to debug the solution at some point, > What Instant Messaging tools do you use? > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > any update on this? I am having exactly the same problem. > > > I have two Div containers, one on top of the other, where you can drag > > from on to the other. > > Each div is large enough for 5 images to fit on one line. > > > With less than 5 images, dragging and dropping is a pleasure, with > > everything looking great. However above 5 images in one container > > forces the images on to two rows, and then dragging problems start. > > The top row is still perfectly fine, but the second row and below it > > is very difficult to drag your image where you want it to land, due to > > constantly alternating drop positions every pixel you move... > > > This problem only occurs with dropOnEmpty set to true, yet I must have > > the ability to empty these lists. > > > help :D--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Yeah looks like the same bug to me, though much more accentuated on yours.
In dragdrop.js these lines appear to be responsible
You can see i''ve added some debug insertions.
What appears to happen is that as i move the item up, one pixel at at time,
it sometimes goes into the top branch, and occasionally into the middle
branch.
This code reads *completely* differently to the onHover function used when
dropOnEmpty:false.
if(children) {
var offset = Element.offsetSize(dropon, droponOptions.overlap) * (
1.0 - overlap);
for (index = 0; index < children.length; index += 1) {
if (offset - Element.offsetSize (children[index],
droponOptions.overlap) >= 0) {
offset -= Element.offsetSize (children[index],
droponOptions.overlap);
new
Insertion.Top(''debug'',''topbranch<br/>'')
} else if (offset - (Element.offsetSize (children[index],
droponOptions.overlap) / 2) >= 0) {
child = index + 1 < children.length ? children[index + 1] :
null;
new
Insertion.Top(''debug'',''midbranch<br/>'')
break;
} else {
child = children[index];
new
Insertion.Top(''debug'',''bottombranch<br/>'')
break;
}
}
}
I confess i''m not even sure what it''s doing... at this point.
Gareth
On 6/13/07, junkmate <junkmate-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:>
>
> Heres my test page: http://www.oldsushi.com/testing.php
>
> Going there make your browser small enough so the images are on two
> lines, and you will see the problem when dragging around the second
> line and below.
>
>
> On Jun 12, 11:10 pm, "Gareth Evans"
<agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > My problem, while related to dropOnEmpty as well seems to only occur
> when my
> > sortables are nested, which is why I can''t replicate it on my
test page.
> > I''ve been meaning to update my test page to prove it so I
have a clean
> page
> > to debug from within, that I can post up (it''s really hard to
post up an
> > internal [read:burried] page of a web application.
> > I think there might be issues in the dropOnEmpty code.
> >
> > Perhaps we should team up to debug the solution at some point,
> > What Instant Messaging tools do you use?
> >
> > On 6/13/07, junkmate
<junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >
> >
> > > any update on this? I am having exactly the same problem.
> >
> > > I have two Div containers, one on top of the other, where you can
drag
> > > from on to the other.
> > > Each div is large enough for 5 images to fit on one line.
> >
> > > With less than 5 images, dragging and dropping is a pleasure,
with
> > > everything looking great. However above 5 images in one container
> > > forces the images on to two rows, and then dragging problems
start.
> > > The top row is still perfectly fine, but the second row and below
it
> > > is very difficult to drag your image where you want it to land,
due to
> > > constantly alternating drop positions every pixel you move...
> >
> > > This problem only occurs with dropOnEmpty set to true, yet I must
have
> > > the ability to empty these lists.
> >
> > > help :D
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
yup I tracked it down to there too. I cant find the "onHover function when dropOnEmpty" is false though, so im unable to compare. ps. I find it interesting that this demo works completely fine: http://wiki.script.aculo.us/scriptaculous/page/print/SortableFloatsDemo On Jun 13, 12:05 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Yeah looks like the same bug to me, though much more accentuated on yours. > In dragdrop.js these lines appear to be responsible > > You can see i''ve added some debug insertions. > What appears to happen is that as i move the item up, one pixel at at time, > it sometimes goes into the top branch, and occasionally into the middle > branch. > > This code reads *completely* differently to the onHover function used when > dropOnEmpty:false. > > if(children) { > var offset = Element.offsetSize(dropon, droponOptions.overlap) * ( > 1.0 - overlap); > > for (index = 0; index < children.length; index += 1) { > if (offset - Element.offsetSize (children[index], > droponOptions.overlap) >= 0) { > offset -= Element.offsetSize (children[index], > droponOptions.overlap); > new Insertion.Top(''debug'',''topbranch<br/>'') > } else if (offset - (Element.offsetSize (children[index], > droponOptions.overlap) / 2) >= 0) { > child = index + 1 < children.length ? children[index + 1] : > null; > new Insertion.Top(''debug'',''midbranch<br/>'') > break; > } else { > child = children[index]; > new Insertion.Top(''debug'',''bottombranch<br/>'') > break; > } > } > } > > I confess i''m not even sure what it''s doing... at this point. > > Gareth > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > Heres my test page:http://www.oldsushi.com/testing.php > > > Going there make your browser small enough so the images are on two > > lines, and you will see the problem when dragging around the second > > line and below. > > > On Jun 12, 11:10 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > My problem, while related to dropOnEmpty as well seems to only occur > > when my > > > sortables are nested, which is why I can''t replicate it on my test page. > > > I''ve been meaning to update my test page to prove it so I have a clean > > page > > > to debug from within, that I can post up (it''s really hard to post up an > > > internal [read:burried] page of a web application. > > > I think there might be issues in the dropOnEmpty code. > > > > Perhaps we should team up to debug the solution at some point, > > > What Instant Messaging tools do you use? > > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > any update on this? I am having exactly the same problem. > > > > > I have two Div containers, one on top of the other, where you can drag > > > > from on to the other. > > > > Each div is large enough for 5 images to fit on one line. > > > > > With less than 5 images, dragging and dropping is a pleasure, with > > > > everything looking great. However above 5 images in one container > > > > forces the images on to two rows, and then dragging problems start. > > > > The top row is still perfectly fine, but the second row and below it > > > > is very difficult to drag your image where you want it to land, due to > > > > constantly alternating drop positions every pixel you move... > > > > > This problem only occurs with dropOnEmpty set to true, yet I must have > > > > the ability to empty these lists. > > > > > help :D--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
As far as I can tell, In Create, it does some stuff that when dropOnEmpty is true, it uses options_for_tree to create a droppable. This defines the onHover handler to be onEmptyHover. The default onHover handler is just onHover. Oohh here''s something interesting. I added an insertion for debug to both onHover and onEmptyHover and *both* are firing when it jitters. If one was calculating the location to be above, and the other below, under a certain condition- wouldn''t this cause the effect we saw, as they''d fire sequentially, one would move it up, the other would move it down... Gareth On 6/13/07, junkmate <junkmate-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > yup I tracked it down to there too. I cant find the "onHover function > when dropOnEmpty" is false though, so im unable to compare. > > ps. I find it interesting that this demo works completely fine: > http://wiki.script.aculo.us/scriptaculous/page/print/SortableFloatsDemo > > > On Jun 13, 12:05 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Yeah looks like the same bug to me, though much more accentuated on > yours. > > In dragdrop.js these lines appear to be responsible > > > > You can see i''ve added some debug insertions. > > What appears to happen is that as i move the item up, one pixel at at > time, > > it sometimes goes into the top branch, and occasionally into the middle > > branch. > > > > This code reads *completely* differently to the onHover function used > when > > dropOnEmpty:false. > > > > if(children) { > > var offset = Element.offsetSize(dropon, droponOptions.overlap) * > ( > > 1.0 - overlap); > > > > for (index = 0; index < children.length; index += 1) { > > if (offset - Element.offsetSize (children[index], > > droponOptions.overlap) >= 0) { > > offset -= Element.offsetSize (children[index], > > droponOptions.overlap); > > new Insertion.Top(''debug'',''topbranch<br/>'') > > } else if (offset - (Element.offsetSize (children[index], > > droponOptions.overlap) / 2) >= 0) { > > child = index + 1 < children.length ? children[index + 1] : > > null; > > new Insertion.Top(''debug'',''midbranch<br/>'') > > break; > > } else { > > child = children[index]; > > new Insertion.Top(''debug'',''bottombranch<br/>'') > > break; > > } > > } > > } > > > > I confess i''m not even sure what it''s doing... at this point. > > > > Gareth > > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > Heres my test page:http://www.oldsushi.com/testing.php > > > > > Going there make your browser small enough so the images are on two > > > lines, and you will see the problem when dragging around the second > > > line and below. > > > > > On Jun 12, 11:10 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > My problem, while related to dropOnEmpty as well seems to only occur > > > when my > > > > sortables are nested, which is why I can''t replicate it on my test > page. > > > > I''ve been meaning to update my test page to prove it so I have a > clean > > > page > > > > to debug from within, that I can post up (it''s really hard to post > up an > > > > internal [read:burried] page of a web application. > > > > I think there might be issues in the dropOnEmpty code. > > > > > > Perhaps we should team up to debug the solution at some point, > > > > What Instant Messaging tools do you use? > > > > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > any update on this? I am having exactly the same problem. > > > > > > > I have two Div containers, one on top of the other, where you can > drag > > > > > from on to the other. > > > > > Each div is large enough for 5 images to fit on one line. > > > > > > > With less than 5 images, dragging and dropping is a pleasure, with > > > > > everything looking great. However above 5 images in one container > > > > > forces the images on to two rows, and then dragging problems > start. > > > > > The top row is still perfectly fine, but the second row and below > it > > > > > is very difficult to drag your image where you want it to land, > due to > > > > > constantly alternating drop positions every pixel you move... > > > > > > > This problem only occurs with dropOnEmpty set to true, yet I must > have > > > > > the ability to empty these lists. > > > > > > > help :D > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
And a bit of evidence I added insertions to the onEmptyHover and onHover internal functions to identify when they were being called. I assigned an ''index'' attribute to every item in the dom... Then found all the insertBefore''s and got it to spit out the index... this is the output onEmptyHover Insertion @ 8 onHover onHover onHover onHover onHover onHover Insertion @ 7 onEmptyHover onEmptyHover Insertion @ 8 onHover onHover Insertion @ 7 onEmptyHover onEmptyHover Insertion @ 7 Looks like this is on the right track, agree? Gareth On 6/13/07, Gareth Evans <agrath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > As far as I can tell, > In Create, it does some stuff that when dropOnEmpty is true, it uses > options_for_tree to create a droppable. > This defines the onHover handler to be onEmptyHover. > The default onHover handler is just onHover. > > Oohh here''s something interesting. > > I added an insertion for debug to both onHover and onEmptyHover and *both* > are firing when it jitters. > > If one was calculating the location to be above, and the other below, > under a certain condition- wouldn''t this cause the effect we saw, as they''d > fire sequentially, one would move it up, the other would move it down... > > Gareth > > On 6/13/07, junkmate <junkmate-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > yup I tracked it down to there too. I cant find the "onHover function > > when dropOnEmpty" is false though, so im unable to compare. > > > > ps. I find it interesting that this demo works completely fine: > > http://wiki.script.aculo.us/scriptaculous/page/print/SortableFloatsDemo > > > > > > On Jun 13, 12:05 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Yeah looks like the same bug to me, though much more accentuated on > > yours. > > > In dragdrop.js these lines appear to be responsible > > > > > > You can see i''ve added some debug insertions. > > > What appears to happen is that as i move the item up, one pixel at at > > time, > > > it sometimes goes into the top branch, and occasionally into the > > middle > > > branch. > > > > > > This code reads *completely* differently to the onHover function used > > when > > > dropOnEmpty:false. > > > > > > if(children) { > > > var offset = Element.offsetSize(dropon, droponOptions.overlap) > > * ( > > > 1.0 - overlap); > > > > > > for (index = 0; index < children.length; index += 1) { > > > if (offset - Element.offsetSize (children[index], > > > droponOptions.overlap ) >= 0) { > > > offset -= Element.offsetSize (children[index], > > > droponOptions.overlap); > > > new Insertion.Top(''debug'',''topbranch<br/>'') > > > } else if (offset - ( Element.offsetSize (children[index], > > > droponOptions.overlap) / 2) >= 0) { > > > child = index + 1 < children.length ? children[index + 1] > > : > > > null; > > > new Insertion.Top(''debug'',''midbranch<br/>'') > > > break; > > > } else { > > > child = children[index]; > > > new Insertion.Top(''debug'',''bottombranch<br/>'') > > > break; > > > } > > > } > > > } > > > > > > I confess i''m not even sure what it''s doing... at this point. > > > > > > Gareth > > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > > Heres my test page:http://www.oldsushi.com/testing.php > > > > > > > Going there make your browser small enough so the images are on two > > > > lines, and you will see the problem when dragging around the second > > > > line and below. > > > > > > > On Jun 12, 11:10 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote: > > > > > My problem, while related to dropOnEmpty as well seems to only > > occur > > > > when my > > > > > sortables are nested, which is why I can''t replicate it on my test > > page. > > > > > I''ve been meaning to update my test page to prove it so I have a > > clean > > > > page > > > > > to debug from within, that I can post up (it''s really hard to post > > up an > > > > > internal [read:burried] page of a web application. > > > > > I think there might be issues in the dropOnEmpty code. > > > > > > > > Perhaps we should team up to debug the solution at some point, > > > > > What Instant Messaging tools do you use? > > > > > > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > any update on this? I am having exactly the same problem. > > > > > > > > > I have two Div containers, one on top of the other, where you > > can drag > > > > > > from on to the other. > > > > > > Each div is large enough for 5 images to fit on one line. > > > > > > > > > With less than 5 images, dragging and dropping is a pleasure, > > with > > > > > > everything looking great. However above 5 images in one > > container > > > > > > forces the images on to two rows, and then dragging problems > > start. > > > > > > The top row is still perfectly fine, but the second row and > > below it > > > > > > is very difficult to drag your image where you want it to land, > > due to > > > > > > constantly alternating drop positions every pixel you move... > > > > > > > > > This problem only occurs with dropOnEmpty set to true, yet I > > must have > > > > > > the ability to empty these lists. > > > > > > > > > help :D > > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
hmmm. definately does. its annoying as every time i think ive fixed it by getting the flickering to stop, it turns out that my modifications have simlply disabled the dropOnEmpty functionality of the function :( Will keep plodding on till I get there! Keep up the good work. On Jun 13, 1:20 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> And a bit of evidence > I added insertions to the onEmptyHover and onHover internal functions to > identify when they were being called. > I assigned an ''index'' attribute to every item in the dom... > Then found all the insertBefore''s and got it to spit out the index... this > is the output > > onEmptyHover Insertion @ 8 > onHover > onHover > onHover > onHover > onHover > onHover Insertion @ 7 > onEmptyHover > onEmptyHover Insertion @ 8 > onHover > onHover Insertion @ 7 > onEmptyHover > onEmptyHover Insertion @ 7 > > Looks like this is on the right track, agree? > > Gareth > > On 6/13/07, Gareth Evans <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > As far as I can tell, > > In Create, it does some stuff that when dropOnEmpty is true, it uses > > options_for_tree to create a droppable. > > This defines the onHover handler to be onEmptyHover. > > The default onHover handler is just onHover. > > > Oohh here''s something interesting. > > > I added an insertion for debug to both onHover and onEmptyHover and *both* > > are firing when it jitters. > > > If one was calculating the location to be above, and the other below, > > under a certain condition- wouldn''t this cause the effect we saw, as they''d > > fire sequentially, one would move it up, the other would move it down... > > > Gareth > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > yup I tracked it down to there too. I cant find the "onHover function > > > when dropOnEmpty" is false though, so im unable to compare. > > > > ps. I find it interesting that this demo works completely fine: > > >http://wiki.script.aculo.us/scriptaculous/page/print/SortableFloatsDemo > > > > On Jun 13, 12:05 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Yeah looks like the same bug to me, though much more accentuated on > > > yours. > > > > In dragdrop.js these lines appear to be responsible > > > > > You can see i''ve added some debug insertions. > > > > What appears to happen is that as i move the item up, one pixel at at > > > time, > > > > it sometimes goes into the top branch, and occasionally into the > > > middle > > > > branch. > > > > > This code reads *completely* differently to the onHover function used > > > when > > > > dropOnEmpty:false. > > > > > if(children) { > > > > var offset = Element.offsetSize(dropon, droponOptions.overlap) > > > * ( > > > > 1.0 - overlap); > > > > > for (index = 0; index < children.length; index += 1) { > > > > if (offset - Element.offsetSize (children[index], > > > > droponOptions.overlap ) >= 0) { > > > > offset -= Element.offsetSize (children[index], > > > > droponOptions.overlap); > > > > new Insertion.Top(''debug'',''topbranch<br/>'') > > > > } else if (offset - ( Element.offsetSize (children[index], > > > > droponOptions.overlap) / 2) >= 0) { > > > > child = index + 1 < children.length ? children[index + 1] > > > : > > > > null; > > > > new Insertion.Top(''debug'',''midbranch<br/>'') > > > > break; > > > > } else { > > > > child = children[index]; > > > > new Insertion.Top(''debug'',''bottombranch<br/>'') > > > > break; > > > > } > > > > } > > > > } > > > > > I confess i''m not even sure what it''s doing... at this point. > > > > > Gareth > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > Heres my test page:http://www.oldsushi.com/testing.php > > > > > > Going there make your browser small enough so the images are on two > > > > > lines, and you will see the problem when dragging around the second > > > > > line and below. > > > > > > On Jun 12, 11:10 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote: > > > > > > My problem, while related to dropOnEmpty as well seems to only > > > occur > > > > > when my > > > > > > sortables are nested, which is why I can''t replicate it on my test > > > page. > > > > > > I''ve been meaning to update my test page to prove it so I have a > > > clean > > > > > page > > > > > > to debug from within, that I can post up (it''s really hard to post > > > up an > > > > > > internal [read:burried] page of a web application. > > > > > > I think there might be issues in the dropOnEmpty code. > > > > > > > Perhaps we should team up to debug the solution at some point, > > > > > > What Instant Messaging tools do you use? > > > > > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > any update on this? I am having exactly the same problem. > > > > > > > > I have two Div containers, one on top of the other, where you > > > can drag > > > > > > > from on to the other. > > > > > > > Each div is large enough for 5 images to fit on one line. > > > > > > > > With less than 5 images, dragging and dropping is a pleasure, > > > with > > > > > > > everything looking great. However above 5 images in one > > > container > > > > > > > forces the images on to two rows, and then dragging problems > > > start. > > > > > > > The top row is still perfectly fine, but the second row and > > > below it > > > > > > > is very difficult to drag your image where you want it to land, > > > due to > > > > > > > constantly alternating drop positions every pixel you move... > > > > > > > > This problem only occurs with dropOnEmpty set to true, yet I > > > must have > > > > > > > the ability to empty these lists. > > > > > > > > help :D--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
FIXED: http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thread/eb4bd46a70ee9fe2 Make the few suggested changes there and all works fine for me! On Jun 13, 1:29 am, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> hmmm. definately does. > > its annoying as every time i think ive fixed it by getting the > flickering to stop, it turns out that my modifications have simlply > disabled the dropOnEmpty functionality of the function :( Will keep > plodding on till I get there! Keep up the good work. > > On Jun 13, 1:20 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > And a bit of evidence > > I added insertions to the onEmptyHover and onHover internal functions to > > identify when they were being called. > > I assigned an ''index'' attribute to every item in the dom... > > Then found all the insertBefore''s and got it to spit out the index... this > > is the output > > > onEmptyHover Insertion @ 8 > > onHover > > onHover > > onHover > > onHover > > onHover > > onHover Insertion @ 7 > > onEmptyHover > > onEmptyHover Insertion @ 8 > > onHover > > onHover Insertion @ 7 > > onEmptyHover > > onEmptyHover Insertion @ 7 > > > Looks like this is on the right track, agree? > > > Gareth > > > On 6/13/07, Gareth Evans <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > As far as I can tell, > > > In Create, it does some stuff that when dropOnEmpty is true, it uses > > > options_for_tree to create a droppable. > > > This defines the onHover handler to be onEmptyHover. > > > The default onHover handler is just onHover. > > > > Oohh here''s something interesting. > > > > I added an insertion for debug to both onHover and onEmptyHover and *both* > > > are firing when it jitters. > > > > If one was calculating the location to be above, and the other below, > > > under a certain condition- wouldn''t this cause the effect we saw, as they''d > > > fire sequentially, one would move it up, the other would move it down... > > > > Gareth > > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > yup I tracked it down to there too. I cant find the "onHover function > > > > when dropOnEmpty" is false though, so im unable to compare. > > > > > ps. I find it interesting that this demo works completely fine: > > > >http://wiki.script.aculo.us/scriptaculous/page/print/SortableFloatsDemo > > > > > On Jun 13, 12:05 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > Yeah looks like the same bug to me, though much more accentuated on > > > > yours. > > > > > In dragdrop.js these lines appear to be responsible > > > > > > You can see i''ve added some debug insertions. > > > > > What appears to happen is that as i move the item up, one pixel at at > > > > time, > > > > > it sometimes goes into the top branch, and occasionally into the > > > > middle > > > > > branch. > > > > > > This code reads *completely* differently to the onHover function used > > > > when > > > > > dropOnEmpty:false. > > > > > > if(children) { > > > > > var offset = Element.offsetSize(dropon, droponOptions.overlap) > > > > * ( > > > > > 1.0 - overlap); > > > > > > for (index = 0; index < children.length; index += 1) { > > > > > if (offset - Element.offsetSize (children[index], > > > > > droponOptions.overlap ) >= 0) { > > > > > offset -= Element.offsetSize (children[index], > > > > > droponOptions.overlap); > > > > > new Insertion.Top(''debug'',''topbranch<br/>'') > > > > > } else if (offset - ( Element.offsetSize (children[index], > > > > > droponOptions.overlap) / 2) >= 0) { > > > > > child = index + 1 < children.length ? children[index + 1] > > > > : > > > > > null; > > > > > new Insertion.Top(''debug'',''midbranch<br/>'') > > > > > break; > > > > > } else { > > > > > child = children[index]; > > > > > new Insertion.Top(''debug'',''bottombranch<br/>'') > > > > > break; > > > > > } > > > > > } > > > > > } > > > > > > I confess i''m not even sure what it''s doing... at this point. > > > > > > Gareth > > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > Heres my test page:http://www.oldsushi.com/testing.php > > > > > > > Going there make your browser small enough so the images are on two > > > > > > lines, and you will see the problem when dragging around the second > > > > > > line and below. > > > > > > > On Jun 12, 11:10 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote: > > > > > > > My problem, while related to dropOnEmpty as well seems to only > > > > occur > > > > > > when my > > > > > > > sortables are nested, which is why I can''t replicate it on my test > > > > page. > > > > > > > I''ve been meaning to update my test page to prove it so I have a > > > > clean > > > > > > page > > > > > > > to debug from within, that I can post up (it''s really hard to post > > > > up an > > > > > > > internal [read:burried] page of a web application. > > > > > > > I think there might be issues in the dropOnEmpty code. > > > > > > > > Perhaps we should team up to debug the solution at some point, > > > > > > > What Instant Messaging tools do you use? > > > > > > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > any update on this? I am having exactly the same problem. > > > > > > > > > I have two Div containers, one on top of the other, where you > > > > can drag > > > > > > > > from on to the other. > > > > > > > > Each div is large enough for 5 images to fit on one line. > > > > > > > > > With less than 5 images, dragging and dropping is a pleasure, > > > > with > > > > > > > > everything looking great. However above 5 images in one > > > > container > > > > > > > > forces the images on to two rows, and then dragging problems > > > > start. > > > > > > > > The top row is still perfectly fine, but the second row and > > > > below it > > > > > > > > is very difficult to drag your image where you want it to land, > > > > due to > > > > > > > > constantly alternating drop positions every pixel you move... > > > > > > > > > This problem only occurs with dropOnEmpty set to true, yet I > > > > must have > > > > > > > > the ability to empty these lists. > > > > > > > > > help :D--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
in fact, you dont need to do all that. The answer relates EXACTLY to
what you said my man, with the two things fighting each other...
The only thing you need to add is some if child==null brackets around
the end of the onEmptyHover function:
dropon.insertBefore(element, child);
Sortable.options(oldParentNode).onChange(element);
droponOptions.onChange(element);
CHANGE ABOVE TO BELOW:
if (child == null) {
dropon.insertBefore(element, child);
Sortable.options(oldParentNode).onChange(element);
droponOptions.onChange(element);
}
On Jun 13, 1:49 am, junkmate
<junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:>
FIXED:http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thr...
>
> Make the few suggested changes there and all works fine for me!
>
> On Jun 13, 1:29 am, junkmate
<junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > hmmm. definately does.
>
> > its annoying as every time i think ive fixed it by getting the
> > flickering to stop, it turns out that my modifications have simlply
> > disabled the dropOnEmpty functionality of the function :( Will keep
> > plodding on till I get there! Keep up the good work.
>
> > On Jun 13, 1:20 am, "Gareth Evans"
<agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > > And a bit of evidence
> > > I added insertions to the onEmptyHover and onHover internal
functions to
> > > identify when they were being called.
> > > I assigned an ''index'' attribute to every item
in the dom...
> > > Then found all the insertBefore''s and got it to spit out
the index... this
> > > is the output
>
> > > onEmptyHover Insertion @ 8
> > > onHover
> > > onHover
> > > onHover
> > > onHover
> > > onHover
> > > onHover Insertion @ 7
> > > onEmptyHover
> > > onEmptyHover Insertion @ 8
> > > onHover
> > > onHover Insertion @ 7
> > > onEmptyHover
> > > onEmptyHover Insertion @ 7
>
> > > Looks like this is on the right track, agree?
>
> > > Gareth
>
> > > On 6/13/07, Gareth Evans
<agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > > > As far as I can tell,
> > > > In Create, it does some stuff that when dropOnEmpty is true,
it uses
> > > > options_for_tree to create a droppable.
> > > > This defines the onHover handler to be onEmptyHover.
> > > > The default onHover handler is just onHover.
>
> > > > Oohh here''s something interesting.
>
> > > > I added an insertion for debug to both onHover and
onEmptyHover and *both*
> > > > are firing when it jitters.
>
> > > > If one was calculating the location to be above, and the
other below,
> > > > under a certain condition- wouldn''t this cause the
effect we saw, as they''d
> > > > fire sequentially, one would move it up, the other would
move it down...
>
> > > > Gareth
>
> > > > On 6/13/07, junkmate
<junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > > > > yup I tracked it down to there too. I cant find the
"onHover function
> > > > > when dropOnEmpty" is false though, so im unable to
compare.
>
> > > > > ps. I find it interesting that this demo works
completely fine:
> > > >
>http://wiki.script.aculo.us/scriptaculous/page/print/SortableFloatsDemo
>
> > > > > On Jun 13, 12:05 am, "Gareth Evans"
<agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > Yeah looks like the same bug to me, though much
more accentuated on
> > > > > yours.
> > > > > > In dragdrop.js these lines appear to be
responsible
>
> > > > > > You can see i''ve added some debug
insertions.
> > > > > > What appears to happen is that as i move the item
up, one pixel at at
> > > > > time,
> > > > > > it sometimes goes into the top branch, and
occasionally into the
> > > > > middle
> > > > > > branch.
>
> > > > > > This code reads *completely* differently to the
onHover function used
> > > > > when
> > > > > > dropOnEmpty:false.
>
> > > > > > if(children) {
> > > > > > var offset = Element.offsetSize(dropon,
droponOptions.overlap)
> > > > > * (
> > > > > > 1.0 - overlap);
>
> > > > > > for (index = 0; index <
children.length; index += 1) {
> > > > > > if (offset - Element.offsetSize
(children[index],
> > > > > > droponOptions.overlap ) >= 0) {
> > > > > > offset -= Element.offsetSize
(children[index],
> > > > > > droponOptions.overlap);
> > > > > > new
Insertion.Top(''debug'',''topbranch<br/>'')
> > > > > > } else if (offset - ( Element.offsetSize
(children[index],
> > > > > > droponOptions.overlap) / 2) >= 0) {
> > > > > > child = index + 1 < children.length
? children[index + 1]
> > > > > :
> > > > > > null;
> > > > > > new
Insertion.Top(''debug'',''midbranch<br/>'')
> > > > > > break;
> > > > > > } else {
> > > > > > child = children[index];
> > > > > > new
Insertion.Top(''debug'',''bottombranch<br/>'')
> > > > > > break;
> > > > > > }
> > > > > > }
> > > > > > }
>
> > > > > > I confess i''m not even sure what
it''s doing... at this point.
>
> > > > > > Gareth
>
> > > > > > On 6/13/07, junkmate <
junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > > > > > > Heres my test
page:http://www.oldsushi.com/testing.php
>
> > > > > > > Going there make your browser small enough so
the images are on two
> > > > > > > lines, and you will see the problem when
dragging around the second
> > > > > > > line and below.
>
> > > > > > > On Jun 12, 11:10 pm, "Gareth Evans"
<agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote:
> > > > > > > > My problem, while related to dropOnEmpty
as well seems to only
> > > > > occur
> > > > > > > when my
> > > > > > > > sortables are nested, which is why I
can''t replicate it on my test
> > > > > page.
> > > > > > > > I''ve been meaning to update my
test page to prove it so I have a
> > > > > clean
> > > > > > > page
> > > > > > > > to debug from within, that I can post up
(it''s really hard to post
> > > > > up an
> > > > > > > > internal [read:burried] page of a web
application.
> > > > > > > > I think there might be issues in the
dropOnEmpty code.
>
> > > > > > > > Perhaps we should team up to debug the
solution at some point,
> > > > > > > > What Instant Messaging tools do you use?
>
> > > > > > > > On 6/13/07, junkmate
<junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > > > > > > > > any update on this? I am having
exactly the same problem.
>
> > > > > > > > > I have two Div containers, one on
top of the other, where you
> > > > > can drag
> > > > > > > > > from on to the other.
> > > > > > > > > Each div is large enough for 5
images to fit on one line.
>
> > > > > > > > > With less than 5 images, dragging
and dropping is a pleasure,
> > > > > with
> > > > > > > > > everything looking great. However
above 5 images in one
> > > > > container
> > > > > > > > > forces the images on to two rows,
and then dragging problems
> > > > > start.
> > > > > > > > > The top row is still perfectly
fine, but the second row and
> > > > > below it
> > > > > > > > > is very difficult to drag your
image where you want it to land,
> > > > > due to
> > > > > > > > > constantly alternating drop
positions every pixel you move...
>
> > > > > > > > > This problem only occurs with
dropOnEmpty set to true, yet I
> > > > > must have
> > > > > > > > > the ability to empty these lists.
>
> > > > > > > > > help :D
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
Hey man
That was a good idea, I guess it fixed your prob but it doesnt seem to have
fixed mine
Check it out
http://202.49.89.140/SortableExample.html
There''s a if (child==null) { } around the 3 lines you suggested.
I''ll try applying the aforementioned patch.
Gareth
On 6/13/07, junkmate <junkmate-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:>
>
> in fact, you dont need to do all that. The answer relates EXACTLY to
> what you said my man, with the two things fighting each other...
> The only thing you need to add is some if child==null brackets around
> the end of the onEmptyHover function:
>
> dropon.insertBefore(element, child);
> Sortable.options(oldParentNode).onChange(element);
> droponOptions.onChange(element);
>
> CHANGE ABOVE TO BELOW:
>
> if (child == null) {
> dropon.insertBefore(element, child);
> Sortable.options(oldParentNode).onChange(element);
> droponOptions.onChange(element);
> }
>
>
>
> On Jun 13, 1:49 am, junkmate
<junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > FIXED:
> http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thr...
> >
> > Make the few suggested changes there and all works fine for me!
> >
> > On Jun 13, 1:29 am, junkmate
<junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > > hmmm. definately does.
> >
> > > its annoying as every time i think ive fixed it by getting the
> > > flickering to stop, it turns out that my modifications have
simlply
> > > disabled the dropOnEmpty functionality of the function :( Will
keep
> > > plodding on till I get there! Keep up the good work.
> >
> > > On Jun 13, 1:20 am, "Gareth Evans"
<agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > > > And a bit of evidence
> > > > I added insertions to the onEmptyHover and onHover internal
> functions to
> > > > identify when they were being called.
> > > > I assigned an ''index'' attribute to every
item in the dom...
> > > > Then found all the insertBefore''s and got it to
spit out the
> index... this
> > > > is the output
> >
> > > > onEmptyHover Insertion @ 8
> > > > onHover
> > > > onHover
> > > > onHover
> > > > onHover
> > > > onHover
> > > > onHover Insertion @ 7
> > > > onEmptyHover
> > > > onEmptyHover Insertion @ 8
> > > > onHover
> > > > onHover Insertion @ 7
> > > > onEmptyHover
> > > > onEmptyHover Insertion @ 7
> >
> > > > Looks like this is on the right track, agree?
> >
> > > > Gareth
> >
> > > > On 6/13/07, Gareth Evans
<agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > > > > As far as I can tell,
> > > > > In Create, it does some stuff that when dropOnEmpty is
true, it
> uses
> > > > > options_for_tree to create a droppable.
> > > > > This defines the onHover handler to be onEmptyHover.
> > > > > The default onHover handler is just onHover.
> >
> > > > > Oohh here''s something interesting.
> >
> > > > > I added an insertion for debug to both onHover and
onEmptyHover
> and *both*
> > > > > are firing when it jitters.
> >
> > > > > If one was calculating the location to be above, and
the other
> below,
> > > > > under a certain condition- wouldn''t this cause
the effect we saw,
> as they''d
> > > > > fire sequentially, one would move it up, the other
would move it
> down...
> >
> > > > > Gareth
> >
> > > > > On 6/13/07, junkmate
<junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > > > > > yup I tracked it down to there too. I cant find
the "onHover
> function
> > > > > > when dropOnEmpty" is false though, so im
unable to compare.
> >
> > > > > > ps. I find it interesting that this demo works
completely fine:
> > > > > >
> http://wiki.script.aculo.us/scriptaculous/page/print/SortableFloatsDemo
> >
> > > > > > On Jun 13, 12:05 am, "Gareth Evans"
<agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > > Yeah looks like the same bug to me, though
much more
> accentuated on
> > > > > > yours.
> > > > > > > In dragdrop.js these lines appear to be
responsible
> >
> > > > > > > You can see i''ve added some debug
insertions.
> > > > > > > What appears to happen is that as i move the
item up, one
> pixel at at
> > > > > > time,
> > > > > > > it sometimes goes into the top branch, and
occasionally into
> the
> > > > > > middle
> > > > > > > branch.
> >
> > > > > > > This code reads *completely* differently to
the onHover
> function used
> > > > > > when
> > > > > > > dropOnEmpty:false.
> >
> > > > > > > if(children) {
> > > > > > > var offset =
Element.offsetSize(dropon,
> droponOptions.overlap)
> > > > > > * (
> > > > > > > 1.0 - overlap);
> >
> > > > > > > for (index = 0; index <
children.length; index += 1) {
> > > > > > > if (offset - Element.offsetSize
(children[index],
> > > > > > > droponOptions.overlap ) >= 0) {
> > > > > > > offset -= Element.offsetSize
(children[index],
> > > > > > > droponOptions.overlap);
> > > > > > > new
Insertion.Top(''debug'',''topbranch<br/>'')
> > > > > > > } else if (offset - (
Element.offsetSize(children[index],
> > > > > > > droponOptions.overlap) / 2) >= 0) {
> > > > > > > child = index + 1 <
children.length ?
> children[index + 1]
> > > > > > :
> > > > > > > null;
> > > > > > > new
Insertion.Top(''debug'',''midbranch<br/>'')
> > > > > > > break;
> > > > > > > } else {
> > > > > > > child = children[index];
> > > > > > > new
Insertion.Top(''debug'',''bottombranch<br/>'')
> > > > > > > break;
> > > > > > > }
> > > > > > > }
> > > > > > > }
> >
> > > > > > > I confess i''m not even sure what
it''s doing... at this point.
> >
> > > > > > > Gareth
> >
> > > > > > > On 6/13/07, junkmate <
junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > > > > > > > Heres my test
page:http://www.oldsushi.com/testing.php
> >
> > > > > > > > Going there make your browser small
enough so the images are
> on two
> > > > > > > > lines, and you will see the problem when
dragging around the
> second
> > > > > > > > line and below.
> >
> > > > > > > > On Jun 12, 11:10 pm, "Gareth
Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org >
> wrote:
> > > > > > > > > My problem, while related to
dropOnEmpty as well seems to
> only
> > > > > > occur
> > > > > > > > when my
> > > > > > > > > sortables are nested, which is why
I can''t replicate it on
> my test
> > > > > > page.
> > > > > > > > > I''ve been meaning to
update my test page to prove it so I
> have a
> > > > > > clean
> > > > > > > > page
> > > > > > > > > to debug from within, that I can
post up (it''s really hard
> to post
> > > > > > up an
> > > > > > > > > internal [read:burried] page of a
web application.
> > > > > > > > > I think there might be issues in
the dropOnEmpty code.
> >
> > > > > > > > > Perhaps we should team up to debug
the solution at some
> point,
> > > > > > > > > What Instant Messaging tools do you
use?
> >
> > > > > > > > > On 6/13/07, junkmate
<junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > > > > > > > > > any update on this? I am
having exactly the same
> problem.
> >
> > > > > > > > > > I have two Div containers, one
on top of the other,
> where you
> > > > > > can drag
> > > > > > > > > > from on to the other.
> > > > > > > > > > Each div is large enough for 5
images to fit on one
> line.
> >
> > > > > > > > > > With less than 5 images,
dragging and dropping is a
> pleasure,
> > > > > > with
> > > > > > > > > > everything looking great.
However above 5 images in one
> > > > > > container
> > > > > > > > > > forces the images on to two
rows, and then dragging
> problems
> > > > > > start.
> > > > > > > > > > The top row is still perfectly
fine, but the second row
> and
> > > > > > below it
> > > > > > > > > > is very difficult to drag your
image where you want it
> to land,
> > > > > > due to
> > > > > > > > > > constantly alternating drop
positions every pixel you
> move...
> >
> > > > > > > > > > This problem only occurs with
dropOnEmpty set to true,
> yet I
> > > > > > must have
> > > > > > > > > > the ability to empty these
lists.
> >
> > > > > > > > > > help :D
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
Odd.. grabbed beta3, overwrote, added the if statement... all fixed. I''ll try in my actual application now. Gareth On 6/13/07, Gareth Evans <agrath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Hey man > > That was a good idea, I guess it fixed your prob but it doesnt seem to > have fixed mine > > Check it out > http://202.49.89.140/SortableExample.html > > There''s a if (child==null) { } around the 3 lines you suggested. > > I''ll try applying the aforementioned patch. > > Gareth > > > On 6/13/07, junkmate <junkmate-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > in fact, you dont need to do all that. The answer relates EXACTLY to > > what you said my man, with the two things fighting each other... > > The only thing you need to add is some if child==null brackets around > > the end of the onEmptyHover function: > > > > dropon.insertBefore(element, child); > > Sortable.options(oldParentNode).onChange(element); > > droponOptions.onChange(element); > > > > CHANGE ABOVE TO BELOW: > > > > if (child == null) { > > dropon.insertBefore(element, child); > > Sortable.options(oldParentNode).onChange(element); > > droponOptions.onChange (element); > > } > > > > > > > > On Jun 13, 1:49 am, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > FIXED:http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thr. > > .. > > > > > > Make the few suggested changes there and all works fine for me! > > > > > > On Jun 13, 1:29 am, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > hmmm. definately does. > > > > > > > its annoying as every time i think ive fixed it by getting the > > > > flickering to stop, it turns out that my modifications have simlply > > > > disabled the dropOnEmpty functionality of the function :( Will keep > > > > plodding on till I get there! Keep up the good work. > > > > > > > On Jun 13, 1:20 am, "Gareth Evans" < agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > And a bit of evidence > > > > > I added insertions to the onEmptyHover and onHover internal > > functions to > > > > > identify when they were being called. > > > > > I assigned an ''index'' attribute to every item in the dom... > > > > > Then found all the insertBefore''s and got it to spit out the > > index... this > > > > > is the output > > > > > > > > onEmptyHover Insertion @ 8 > > > > > onHover > > > > > onHover > > > > > onHover > > > > > onHover > > > > > onHover > > > > > onHover Insertion @ 7 > > > > > onEmptyHover > > > > > onEmptyHover Insertion @ 8 > > > > > onHover > > > > > onHover Insertion @ 7 > > > > > onEmptyHover > > > > > onEmptyHover Insertion @ 7 > > > > > > > > Looks like this is on the right track, agree? > > > > > > > > Gareth > > > > > > > > On 6/13/07, Gareth Evans <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > As far as I can tell, > > > > > > In Create, it does some stuff that when dropOnEmpty is true, it > > uses > > > > > > options_for_tree to create a droppable. > > > > > > This defines the onHover handler to be onEmptyHover. > > > > > > The default onHover handler is just onHover. > > > > > > > > > Oohh here''s something interesting. > > > > > > > > > I added an insertion for debug to both onHover and onEmptyHover > > and *both* > > > > > > are firing when it jitters. > > > > > > > > > If one was calculating the location to be above, and the other > > below, > > > > > > under a certain condition- wouldn''t this cause the effect we > > saw, as they''d > > > > > > fire sequentially, one would move it up, the other would move it > > down... > > > > > > > > > Gareth > > > > > > > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > yup I tracked it down to there too. I cant find the "onHover > > function > > > > > > > when dropOnEmpty" is false though, so im unable to compare. > > > > > > > > > > ps. I find it interesting that this demo works completely > > fine: > > > > > > > > > http://wiki.script.aculo.us/scriptaculous/page/print/SortableFloatsDemo > > > > > > > > > > On Jun 13, 12:05 am, "Gareth Evans" < agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > Yeah looks like the same bug to me, though much more > > accentuated on > > > > > > > yours. > > > > > > > > In dragdrop.js these lines appear to be responsible > > > > > > > > > > > You can see i''ve added some debug insertions. > > > > > > > > What appears to happen is that as i move the item up, one > > pixel at at > > > > > > > time, > > > > > > > > it sometimes goes into the top branch, and occasionally into > > the > > > > > > > middle > > > > > > > > branch. > > > > > > > > > > > This code reads *completely* differently to the onHover > > function used > > > > > > > when > > > > > > > > dropOnEmpty:false. > > > > > > > > > > > if(children) { > > > > > > > > var offset = Element.offsetSize(dropon, > > droponOptions.overlap) > > > > > > > * ( > > > > > > > > 1.0 - overlap); > > > > > > > > > > > for (index = 0; index < children.length; index += 1) > > { > > > > > > > > if (offset - Element.offsetSize (children[index], > > > > > > > > droponOptions.overlap ) >= 0) { > > > > > > > > offset -= Element.offsetSize (children[index], > > > > > > > > droponOptions.overlap); > > > > > > > > new Insertion.Top(''debug'',''topbranch<br/>'') > > > > > > > > } else if (offset - ( Element.offsetSize(children[index], > > > > > > > > droponOptions.overlap) / 2) >= 0) { > > > > > > > > child = index + 1 < children.length ? > > children[index + 1] > > > > > > > : > > > > > > > > null; > > > > > > > > new Insertion.Top(''debug'',''midbranch<br/>'') > > > > > > > > break; > > > > > > > > } else { > > > > > > > > child = children[index]; > > > > > > > > new Insertion.Top(''debug'',''bottombranch<br/>'') > > > > > > > > break; > > > > > > > > } > > > > > > > > } > > > > > > > > } > > > > > > > > > > > I confess i''m not even sure what it''s doing... at this > > point. > > > > > > > > > > > Gareth > > > > > > > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > Heres my test page:http://www.oldsushi.com/testing.php > > > > > > > > > > > > Going there make your browser small enough so the images > > are on two > > > > > > > > > lines, and you will see the problem when dragging around > > the second > > > > > > > > > line and below. > > > > > > > > > > > > On Jun 12, 11:10 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > > > wrote: > > > > > > > > > > My problem, while related to dropOnEmpty as well seems > > to only > > > > > > > occur > > > > > > > > > when my > > > > > > > > > > sortables are nested, which is why I can''t replicate it > > on my test > > > > > > > page. > > > > > > > > > > I''ve been meaning to update my test page to prove it so > > I have a > > > > > > > clean > > > > > > > > > page > > > > > > > > > > to debug from within, that I can post up (it''s really > > hard to post > > > > > > > up an > > > > > > > > > > internal [read:burried] page of a web application. > > > > > > > > > > I think there might be issues in the dropOnEmpty code. > > > > > > > > > > > > > Perhaps we should team up to debug the solution at some > > point, > > > > > > > > > > What Instant Messaging tools do you use? > > > > > > > > > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > > > any update on this? I am having exactly the same > > problem. > > > > > > > > > > > > > > I have two Div containers, one on top of the other, > > where you > > > > > > > can drag > > > > > > > > > > > from on to the other. > > > > > > > > > > > Each div is large enough for 5 images to fit on one > > line. > > > > > > > > > > > > > > With less than 5 images, dragging and dropping is a > > pleasure, > > > > > > > with > > > > > > > > > > > everything looking great. However above 5 images in > > one > > > > > > > container > > > > > > > > > > > forces the images on to two rows, and then dragging > > problems > > > > > > > start. > > > > > > > > > > > The top row is still perfectly fine, but the second > > row and > > > > > > > below it > > > > > > > > > > > is very difficult to drag your image where you want it > > to land, > > > > > > > due to > > > > > > > > > > > constantly alternating drop positions every pixel you > > move... > > > > > > > > > > > > > > This problem only occurs with dropOnEmpty set to true, > > yet I > > > > > > > must have > > > > > > > > > > > the ability to empty these lists. > > > > > > > > > > > > > > help :D > > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
your demo looks good to me mate! Hopefully that should solve our problems eh! right one job done, time for bed! Will check again in the morning to see how you got on. On Jun 13, 2:42 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Odd.. grabbed beta3, overwrote, added the if statement... all fixed. > I''ll try in my actual application now. > > Gareth > > On 6/13/07, Gareth Evans <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > Hey man > > > That was a good idea, I guess it fixed your prob but it doesnt seem to > > have fixed mine > > > Check it out > >http://202.49.89.140/SortableExample.html > > > There''s a if (child==null) { } around the 3 lines you suggested. > > > I''ll try applying the aforementioned patch. > > > Gareth > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > in fact, you dont need to do all that. The answer relates EXACTLY to > > > what you said my man, with the two things fighting each other... > > > The only thing you need to add is some if child==null brackets around > > > the end of the onEmptyHover function: > > > > dropon.insertBefore(element, child); > > > Sortable.options(oldParentNode).onChange(element); > > > droponOptions.onChange(element); > > > > CHANGE ABOVE TO BELOW: > > > > if (child == null) { > > > dropon.insertBefore(element, child); > > > Sortable.options(oldParentNode).onChange(element); > > > droponOptions.onChange (element); > > > } > > > > On Jun 13, 1:49 am, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > FIXED:http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thr. > > > .. > > > > > Make the few suggested changes there and all works fine for me! > > > > > On Jun 13, 1:29 am, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > hmmm. definately does. > > > > > > its annoying as every time i think ive fixed it by getting the > > > > > flickering to stop, it turns out that my modifications have simlply > > > > > disabled the dropOnEmpty functionality of the function :( Will keep > > > > > plodding on till I get there! Keep up the good work. > > > > > > On Jun 13, 1:20 am, "Gareth Evans" < agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > And a bit of evidence > > > > > > I added insertions to the onEmptyHover and onHover internal > > > functions to > > > > > > identify when they were being called. > > > > > > I assigned an ''index'' attribute to every item in the dom... > > > > > > Then found all the insertBefore''s and got it to spit out the > > > index... this > > > > > > is the output > > > > > > > onEmptyHover Insertion @ 8 > > > > > > onHover > > > > > > onHover > > > > > > onHover > > > > > > onHover > > > > > > onHover > > > > > > onHover Insertion @ 7 > > > > > > onEmptyHover > > > > > > onEmptyHover Insertion @ 8 > > > > > > onHover > > > > > > onHover Insertion @ 7 > > > > > > onEmptyHover > > > > > > onEmptyHover Insertion @ 7 > > > > > > > Looks like this is on the right track, agree? > > > > > > > Gareth > > > > > > > On 6/13/07, Gareth Evans <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > As far as I can tell, > > > > > > > In Create, it does some stuff that when dropOnEmpty is true, it > > > uses > > > > > > > options_for_tree to create a droppable. > > > > > > > This defines the onHover handler to be onEmptyHover. > > > > > > > The default onHover handler is just onHover. > > > > > > > > Oohh here''s something interesting. > > > > > > > > I added an insertion for debug to both onHover and onEmptyHover > > > and *both* > > > > > > > are firing when it jitters. > > > > > > > > If one was calculating the location to be above, and the other > > > below, > > > > > > > under a certain condition- wouldn''t this cause the effect we > > > saw, as they''d > > > > > > > fire sequentially, one would move it up, the other would move it > > > down... > > > > > > > > Gareth > > > > > > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > yup I tracked it down to there too. I cant find the "onHover > > > function > > > > > > > > when dropOnEmpty" is false though, so im unable to compare. > > > > > > > > > ps. I find it interesting that this demo works completely > > > fine: > > > >http://wiki.script.aculo.us/scriptaculous/page/print/SortableFloatsDemo > > > > > > > > > On Jun 13, 12:05 am, "Gareth Evans" < agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > Yeah looks like the same bug to me, though much more > > > accentuated on > > > > > > > > yours. > > > > > > > > > In dragdrop.js these lines appear to be responsible > > > > > > > > > > You can see i''ve added some debug insertions. > > > > > > > > > What appears to happen is that as i move the item up, one > > > pixel at at > > > > > > > > time, > > > > > > > > > it sometimes goes into the top branch, and occasionally into > > > the > > > > > > > > middle > > > > > > > > > branch. > > > > > > > > > > This code reads *completely* differently to the onHover > > > function used > > > > > > > > when > > > > > > > > > dropOnEmpty:false. > > > > > > > > > > if(children) { > > > > > > > > > var offset = Element.offsetSize(dropon, > > > droponOptions.overlap) > > > > > > > > * ( > > > > > > > > > 1.0 - overlap); > > > > > > > > > > for (index = 0; index < children.length; index += 1) > > > { > > > > > > > > > if (offset - Element.offsetSize (children[index], > > > > > > > > > droponOptions.overlap ) >= 0) { > > > > > > > > > offset -= Element.offsetSize (children[index], > > > > > > > > > droponOptions.overlap); > > > > > > > > > new Insertion.Top(''debug'',''topbranch<br/>'') > > > > > > > > > } else if (offset - ( Element.offsetSize(children[index], > > > > > > > > > droponOptions.overlap) / 2) >= 0) { > > > > > > > > > child = index + 1 < children.length ? > > > children[index + 1] > > > > > > > > : > > > > > > > > > null; > > > > > > > > > new Insertion.Top(''debug'',''midbranch<br/>'') > > > > > > > > > break; > > > > > > > > > } else { > > > > > > > > > child = children[index]; > > > > > > > > > new Insertion.Top(''debug'',''bottombranch<br/>'') > > > > > > > > > break; > > > > > > > > > } > > > > > > > > > } > > > > > > > > > } > > > > > > > > > > I confess i''m not even sure what it''s doing... at this > > > point. > > > > > > > > > > Gareth > > > > > > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > Heres my test page:http://www.oldsushi.com/testing.php > > > > > > > > > > > Going there make your browser small enough so the images > > > are on two > > > > > > > > > > lines, and you will see the problem when dragging around > > > the second > > > > > > > > > > line and below. > > > > > > > > > > > On Jun 12, 11:10 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > > > > wrote: > > > > > > > > > > > My problem, while related to dropOnEmpty as well seems > > > to only > > > > > > > > occur > > > > > > > > > > when my > > > > > > > > > > > sortables are nested, which is why I can''t replicate it > > > on my test > > > > > > > > page. > > > > > > > > > > > I''ve been meaning to update my test page to prove it so > > > I have a > > > > > > > > clean > > > > > > > > > > page > > > > > > > > > > > to debug from within, that I can post up (it''s really > > > hard to post > > > > > > > > up an > > > > > > > > > > > internal [read:burried] page of a web application. > > > > > > > > > > > I think there might be issues in the dropOnEmpty code. > > > > > > > > > > > > Perhaps we should team up to debug the solution at some > > > point, > > > > > > > > > > > What Instant Messaging tools do you use? > > > > > > > > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > > any update on this? I am having exactly the same > > > problem. > > > > > > > > > > > > > I have two Div containers, one on top of the other, > > > where you > > > > > > > > can drag > > > > > > > > > > > > from on to the other. > > > > > > > > > > > > Each div is large enough for 5 images to fit on one > > > line. > > > > > > > > > > > > > With less than 5 images, dragging and dropping is a > > > pleasure, > > > > > > > > with > > > > > > > > > > > > everything looking great. However above 5 images in > > > one > > > > > > > > container > > > > > > > > > > > > forces the images on to two rows, and then dragging > > > problems > > > > > > > > start. > > > > > > > > > > > > The top row is still perfectly fine, but the second > > > row and > > > > > > > > below it > > > > > > > > > > > > is very difficult to drag your image where you want it > > > to land, > > > > > > > > due to > > > > > > > > > > > > constantly alternating drop positions every pixel you > > > move... > > > > > > > > > > > > > This problem only occurs with dropOnEmpty set to true, > > > yet I > > > > > > > > must have > > > > > > > > > > > > the ability to empty these lists. > > > > > > > > > > > > > help :D--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Yeah, the demo is working but the fix *will not* work in my application... There must be more at play here... Gareth On 6/13/07, junkmate <junkmate-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > your demo looks good to me mate! Hopefully that should solve our > problems eh! > > right one job done, time for bed! > Will check again in the morning to see how you got on. > > > > On Jun 13, 2:42 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Odd.. grabbed beta3, overwrote, added the if statement... all fixed. > > I''ll try in my actual application now. > > > > Gareth > > > > On 6/13/07, Gareth Evans <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > Hey man > > > > > That was a good idea, I guess it fixed your prob but it doesnt seem to > > > have fixed mine > > > > > Check it out > > >http://202.49.89.140/SortableExample.html > > > > > There''s a if (child==null) { } around the 3 lines you suggested. > > > > > I''ll try applying the aforementioned patch. > > > > > Gareth > > > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > in fact, you dont need to do all that. The answer relates EXACTLY to > > > > what you said my man, with the two things fighting each other... > > > > The only thing you need to add is some if child==null brackets > around > > > > the end of the onEmptyHover function: > > > > > > dropon.insertBefore(element, child); > > > > Sortable.options(oldParentNode).onChange(element); > > > > droponOptions.onChange(element); > > > > > > CHANGE ABOVE TO BELOW: > > > > > > if (child == null) { > > > > dropon.insertBefore(element, child); > > > > Sortable.options(oldParentNode).onChange(element); > > > > droponOptions.onChange (element); > > > > } > > > > > > On Jun 13, 1:49 am, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > FIXED: > http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thr. > > > > .. > > > > > > > Make the few suggested changes there and all works fine for me! > > > > > > > On Jun 13, 1:29 am, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > hmmm. definately does. > > > > > > > > its annoying as every time i think ive fixed it by getting the > > > > > > flickering to stop, it turns out that my modifications have > simlply > > > > > > disabled the dropOnEmpty functionality of the function :( Will > keep > > > > > > plodding on till I get there! Keep up the good work. > > > > > > > > On Jun 13, 1:20 am, "Gareth Evans" < agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > And a bit of evidence > > > > > > > I added insertions to the onEmptyHover and onHover internal > > > > functions to > > > > > > > identify when they were being called. > > > > > > > I assigned an ''index'' attribute to every item in the dom... > > > > > > > Then found all the insertBefore''s and got it to spit out the > > > > index... this > > > > > > > is the output > > > > > > > > > onEmptyHover Insertion @ 8 > > > > > > > onHover > > > > > > > onHover > > > > > > > onHover > > > > > > > onHover > > > > > > > onHover > > > > > > > onHover Insertion @ 7 > > > > > > > onEmptyHover > > > > > > > onEmptyHover Insertion @ 8 > > > > > > > onHover > > > > > > > onHover Insertion @ 7 > > > > > > > onEmptyHover > > > > > > > onEmptyHover Insertion @ 7 > > > > > > > > > Looks like this is on the right track, agree? > > > > > > > > > Gareth > > > > > > > > > On 6/13/07, Gareth Evans <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > As far as I can tell, > > > > > > > > In Create, it does some stuff that when dropOnEmpty is true, > it > > > > uses > > > > > > > > options_for_tree to create a droppable. > > > > > > > > This defines the onHover handler to be onEmptyHover. > > > > > > > > The default onHover handler is just onHover. > > > > > > > > > > Oohh here''s something interesting. > > > > > > > > > > I added an insertion for debug to both onHover and > onEmptyHover > > > > and *both* > > > > > > > > are firing when it jitters. > > > > > > > > > > If one was calculating the location to be above, and the > other > > > > below, > > > > > > > > under a certain condition- wouldn''t this cause the effect we > > > > saw, as they''d > > > > > > > > fire sequentially, one would move it up, the other would > move it > > > > down... > > > > > > > > > > Gareth > > > > > > > > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > yup I tracked it down to there too. I cant find the > "onHover > > > > function > > > > > > > > > when dropOnEmpty" is false though, so im unable to > compare. > > > > > > > > > > > ps. I find it interesting that this demo works completely > > > > fine: > > > > > > > http://wiki.script.aculo.us/scriptaculous/page/print/SortableFloatsDemo > > > > > > > > > > > On Jun 13, 12:05 am, "Gareth Evans" < agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote: > > > > > > > > > > Yeah looks like the same bug to me, though much more > > > > accentuated on > > > > > > > > > yours. > > > > > > > > > > In dragdrop.js these lines appear to be responsible > > > > > > > > > > > > You can see i''ve added some debug insertions. > > > > > > > > > > What appears to happen is that as i move the item up, > one > > > > pixel at at > > > > > > > > > time, > > > > > > > > > > it sometimes goes into the top branch, and occasionally > into > > > > the > > > > > > > > > middle > > > > > > > > > > branch. > > > > > > > > > > > > This code reads *completely* differently to the onHover > > > > function used > > > > > > > > > when > > > > > > > > > > dropOnEmpty:false. > > > > > > > > > > > > if(children) { > > > > > > > > > > var offset = Element.offsetSize(dropon, > > > > droponOptions.overlap) > > > > > > > > > * ( > > > > > > > > > > 1.0 - overlap); > > > > > > > > > > > > for (index = 0; index < children.length; index > += 1) > > > > { > > > > > > > > > > if (offset - Element.offsetSize(children[index], > > > > > > > > > > droponOptions.overlap ) >= 0) { > > > > > > > > > > offset -= Element.offsetSize(children[index], > > > > > > > > > > droponOptions.overlap); > > > > > > > > > > new Insertion.Top(''debug'',''topbranch<br/>'') > > > > > > > > > > } else if (offset - ( Element.offsetSize > (children[index], > > > > > > > > > > droponOptions.overlap) / 2) >= 0) { > > > > > > > > > > child = index + 1 < children.length ? > > > > children[index + 1] > > > > > > > > > : > > > > > > > > > > null; > > > > > > > > > > new Insertion.Top(''debug'',''midbranch<br/>'') > > > > > > > > > > break; > > > > > > > > > > } else { > > > > > > > > > > child = children[index]; > > > > > > > > > > new Insertion.Top(''debug'',''bottombranch<br/>'') > > > > > > > > > > break; > > > > > > > > > > } > > > > > > > > > > } > > > > > > > > > > } > > > > > > > > > > > > I confess i''m not even sure what it''s doing... at this > > > > point. > > > > > > > > > > > > Gareth > > > > > > > > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > > Heres my test page:http://www.oldsushi.com/testing.php > > > > > > > > > > > > > Going there make your browser small enough so the > images > > > > are on two > > > > > > > > > > > lines, and you will see the problem when dragging > around > > > > the second > > > > > > > > > > > line and below. > > > > > > > > > > > > > On Jun 12, 11:10 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > > > wrote: > > > > > > > > > > > > My problem, while related to dropOnEmpty as well > seems > > > > to only > > > > > > > > > occur > > > > > > > > > > > when my > > > > > > > > > > > > sortables are nested, which is why I can''t replicate > it > > > > on my test > > > > > > > > > page. > > > > > > > > > > > > I''ve been meaning to update my test page to prove it > so > > > > I have a > > > > > > > > > clean > > > > > > > > > > > page > > > > > > > > > > > > to debug from within, that I can post up (it''s > really > > > > hard to post > > > > > > > > > up an > > > > > > > > > > > > internal [read:burried] page of a web application. > > > > > > > > > > > > I think there might be issues in the dropOnEmpty > code. > > > > > > > > > > > > > > Perhaps we should team up to debug the solution at > some > > > > point, > > > > > > > > > > > > What Instant Messaging tools do you use? > > > > > > > > > > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > > > > any update on this? I am having exactly the same > > > > problem. > > > > > > > > > > > > > > > I have two Div containers, one on top of the > other, > > > > where you > > > > > > > > > can drag > > > > > > > > > > > > > from on to the other. > > > > > > > > > > > > > Each div is large enough for 5 images to fit on > one > > > > line. > > > > > > > > > > > > > > > With less than 5 images, dragging and dropping is > a > > > > pleasure, > > > > > > > > > with > > > > > > > > > > > > > everything looking great. However above 5 images > in > > > > one > > > > > > > > > container > > > > > > > > > > > > > forces the images on to two rows, and then > dragging > > > > problems > > > > > > > > > start. > > > > > > > > > > > > > The top row is still perfectly fine, but the > second > > > > row and > > > > > > > > > below it > > > > > > > > > > > > > is very difficult to drag your image where you > want it > > > > to land, > > > > > > > > > due to > > > > > > > > > > > > > constantly alternating drop positions every pixel > you > > > > move... > > > > > > > > > > > > > > > This problem only occurs with dropOnEmpty set to > true, > > > > yet I > > > > > > > > > must have > > > > > > > > > > > > > the ability to empty these lists. > > > > > > > > > > > > > > > help :D > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Okay, so a bit more digging around... something appears to be weird with the offset calcuations. From my observations, the onHover handler and the onEmptyHover handler get fired. They both calculate where to insert an item, and one of them calculates it differently to the other. This results in the ''jitterbug'' i''ve referred to. The patch earlier described (and documented on trac, but its actually a patch for some other tree functionality) shows a if (child == null) conditional around the final ''insert'' statements. Because of this, I *think* that the for loop that appears above this if is not actually required and it''s sufficent to just check children.length == 0. Meaning, if there are no children elements then we want the onEmptyHover to insert the element. I''m not very familiar with the intricacies of Sortable, other than what i''ve played with to get this working, but when I check children.length == 0 instead of having the for loop using offsets to identify if where the item should go, the ''jitter'' effect goes away for me. As previously mentioned, both onHover and onEmptyHover fire when i''m doing a drag with dropOnEmpty:true. I''m trying to figure out what i''ve broken by removing the offset calculation, and if it''s going to be an issue for anything else I might do with Sortable later in my developments. Could one of the scripty gods read this thread and advise? I''ll attach a shortened version of my new dropOnEmpty code, which has some other modifications to allow a ''marker'' element, from Tankut Koray, and myself to make his code conditional. I haven''t touched made any modifications to scripty base dragdrop.jsfunctions other than onEmptyHover but unMark, onHover have been changed by Tankut, and markEmptyPlace and createGuide have been created by him. I''ve since added if statements before his code to read an options setting so I can turn his functionality off (I only need it on one page) This issue has been driving me mad for weeks so it''d be good to get this stuff sorted. http://dev.rubyonrails.org/ticket/7807 This patch is similar but doesn''t quite fix the functionality in my app... for some reason. (It adds the if (child==null) which worked for junkmate''s app, but didn''t work for mine, I had to go to the children.length == 0) Gareth On 6/13/07, Gareth Evans <agrath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Yeah, the demo is working but the fix *will not* work in my application... > There must be more at play here... > > Gareth > > > On 6/13/07, junkmate <junkmate-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > your demo looks good to me mate! Hopefully that should solve our > > problems eh! > > > > right one job done, time for bed! > > Will check again in the morning to see how you got on. > > > > > > > > On Jun 13, 2:42 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Odd.. grabbed beta3, overwrote, added the if statement... all fixed. > > > I''ll try in my actual application now. > > > > > > Gareth > > > > > > On 6/13/07, Gareth Evans <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > > Hey man > > > > > > > That was a good idea, I guess it fixed your prob but it doesnt seem > > to > > > > have fixed mine > > > > > > > Check it out > > > >http://202.49.89.140/SortableExample.html > > > > > > > There''s a if (child==null) { } around the 3 lines you suggested. > > > > > > > I''ll try applying the aforementioned patch. > > > > > > > Gareth > > > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > in fact, you dont need to do all that. The answer relates EXACTLY > > to > > > > > what you said my man, with the two things fighting each other... > > > > > The only thing you need to add is some if child==null brackets > > around > > > > > the end of the onEmptyHover function: > > > > > > > > dropon.insertBefore(element, child); > > > > > Sortable.options(oldParentNode).onChange(element); > > > > > droponOptions.onChange(element); > > > > > > > > CHANGE ABOVE TO BELOW: > > > > > > > > if (child == null) { > > > > > dropon.insertBefore(element, child); > > > > > Sortable.options(oldParentNode).onChange(element); > > > > > droponOptions.onChange (element); > > > > > } > > > > > > > > On Jun 13, 1:49 am, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > FIXED:http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thr > > . > > > > > .. > > > > > > > > > Make the few suggested changes there and all works fine for me! > > > > > > > > > On Jun 13, 1:29 am, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > hmmm. definately does. > > > > > > > > > > its annoying as every time i think ive fixed it by getting the > > > > > > > flickering to stop, it turns out that my modifications have > > simlply > > > > > > > disabled the dropOnEmpty functionality of the function :( Will > > keep > > > > > > > plodding on till I get there! Keep up the good work. > > > > > > > > > > On Jun 13, 1:20 am, "Gareth Evans" < agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > And a bit of evidence > > > > > > > > I added insertions to the onEmptyHover and onHover internal > > > > > functions to > > > > > > > > identify when they were being called. > > > > > > > > I assigned an ''index'' attribute to every item in the dom... > > > > > > > > Then found all the insertBefore''s and got it to spit out the > > > > > > > index... this > > > > > > > > is the output > > > > > > > > > > > onEmptyHover Insertion @ 8 > > > > > > > > onHover > > > > > > > > onHover > > > > > > > > onHover > > > > > > > > onHover > > > > > > > > onHover > > > > > > > > onHover Insertion @ 7 > > > > > > > > onEmptyHover > > > > > > > > onEmptyHover Insertion @ 8 > > > > > > > > onHover > > > > > > > > onHover Insertion @ 7 > > > > > > > > onEmptyHover > > > > > > > > onEmptyHover Insertion @ 7 > > > > > > > > > > > Looks like this is on the right track, agree? > > > > > > > > > > > Gareth > > > > > > > > > > > On 6/13/07, Gareth Evans < agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > As far as I can tell, > > > > > > > > > In Create, it does some stuff that when dropOnEmpty is > > true, it > > > > > uses > > > > > > > > > options_for_tree to create a droppable. > > > > > > > > > This defines the onHover handler to be onEmptyHover. > > > > > > > > > The default onHover handler is just onHover. > > > > > > > > > > > > Oohh here''s something interesting. > > > > > > > > > > > > I added an insertion for debug to both onHover and > > onEmptyHover > > > > > and *both* > > > > > > > > > are firing when it jitters. > > > > > > > > > > > > If one was calculating the location to be above, and the > > other > > > > > below, > > > > > > > > > under a certain condition- wouldn''t this cause the effect > > we > > > > > saw, as they''d > > > > > > > > > fire sequentially, one would move it up, the other would > > move it > > > > > down... > > > > > > > > > > > > Gareth > > > > > > > > > > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > > yup I tracked it down to there too. I cant find the > > "onHover > > > > > function > > > > > > > > > > when dropOnEmpty" is false though, so im unable to > > compare. > > > > > > > > > > > > > ps. I find it interesting that this demo works > > completely > > > > > fine: > > > > > > > > > > http://wiki.script.aculo.us/scriptaculous/page/print/SortableFloatsDemo > > > > > > > > > > > > > On Jun 13, 12:05 am, "Gareth Evans" < agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > wrote: > > > > > > > > > > > Yeah looks like the same bug to me, though much more > > > > > accentuated on > > > > > > > > > > yours. > > > > > > > > > > > In dragdrop.js these lines appear to be responsible > > > > > > > > > > > > > > You can see i''ve added some debug insertions. > > > > > > > > > > > What appears to happen is that as i move the item up, > > one > > > > > pixel at at > > > > > > > > > > time, > > > > > > > > > > > it sometimes goes into the top branch, and > > occasionally into > > > > > the > > > > > > > > > > middle > > > > > > > > > > > branch. > > > > > > > > > > > > > > This code reads *completely* differently to the > > onHover > > > > > function used > > > > > > > > > > when > > > > > > > > > > > dropOnEmpty:false. > > > > > > > > > > > > > > if(children) { > > > > > > > > > > > var offset = Element.offsetSize (dropon, > > > > > droponOptions.overlap) > > > > > > > > > > * ( > > > > > > > > > > > 1.0 - overlap); > > > > > > > > > > > > > > for (index = 0; index < children.length; index > > += 1) > > > > > { > > > > > > > > > > > if (offset - Element.offsetSize(children[index], > > > > > > > > > > > droponOptions.overlap ) >= 0) { > > > > > > > > > > > offset -= Element.offsetSize(children[index], > > > > > > > > > > > droponOptions.overlap); > > > > > > > > > > > new Insertion.Top(''debug'',''topbranch<br/>'') > > > > > > > > > > > } else if (offset - ( Element.offsetSize > > (children[index], > > > > > > > > > > > droponOptions.overlap) / 2) >= 0) { > > > > > > > > > > > child = index + 1 < children.length ? > > > > > children[index + 1] > > > > > > > > > > : > > > > > > > > > > > null; > > > > > > > > > > > new Insertion.Top(''debug'',''midbranch<br/>'') > > > > > > > > > > > break; > > > > > > > > > > > } else { > > > > > > > > > > > child = children[index]; > > > > > > > > > > > new Insertion.Top (''debug'',''bottombranch<br/>'') > > > > > > > > > > > break; > > > > > > > > > > > } > > > > > > > > > > > } > > > > > > > > > > > } > > > > > > > > > > > > > > I confess i''m not even sure what it''s doing... at this > > > > > point. > > > > > > > > > > > > > > Gareth > > > > > > > > > > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > > > > Heres my test page: > > http://www.oldsushi.com/testing.php > > > > > > > > > > > > > > > Going there make your browser small enough so the > > images > > > > > are on two > > > > > > > > > > > > lines, and you will see the problem when dragging > > around > > > > > the second > > > > > > > > > > > > line and below. > > > > > > > > > > > > > > > On Jun 12, 11:10 pm, "Gareth Evans" < > > agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > > > > > > wrote: > > > > > > > > > > > > > My problem, while related to dropOnEmpty as well > > seems > > > > > to only > > > > > > > > > > occur > > > > > > > > > > > > when my > > > > > > > > > > > > > sortables are nested, which is why I can''t > > replicate it > > > > > on my test > > > > > > > > > > page. > > > > > > > > > > > > > I''ve been meaning to update my test page to prove > > it so > > > > > I have a > > > > > > > > > > clean > > > > > > > > > > > > page > > > > > > > > > > > > > to debug from within, that I can post up (it''s > > really > > > > > hard to post > > > > > > > > > > up an > > > > > > > > > > > > > internal [read:burried] page of a web application. > > > > > > > > > > > > > I think there might be issues in the dropOnEmpty > > code. > > > > > > > > > > > > > > > > Perhaps we should team up to debug the solution at > > some > > > > > point, > > > > > > > > > > > > > What Instant Messaging tools do you use? > > > > > > > > > > > > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > > > > > > any update on this? I am having exactly the same > > > > > > > problem. > > > > > > > > > > > > > > > > > I have two Div containers, one on top of the > > other, > > > > > where you > > > > > > > > > > can drag > > > > > > > > > > > > > > from on to the other. > > > > > > > > > > > > > > Each div is large enough for 5 images to fit on > > one > > > > > line. > > > > > > > > > > > > > > > > > With less than 5 images, dragging and dropping > > is a > > > > > pleasure, > > > > > > > > > > with > > > > > > > > > > > > > > everything looking great. However above 5 images > > in > > > > > one > > > > > > > > > > container > > > > > > > > > > > > > > forces the images on to two rows, and then > > dragging > > > > > problems > > > > > > > > > > start. > > > > > > > > > > > > > > The top row is still perfectly fine, but the > > second > > > > > row and > > > > > > > > > > below it > > > > > > > > > > > > > > is very difficult to drag your image where you > > want it > > > > > to land, > > > > > > > > > > due to > > > > > > > > > > > > > > constantly alternating drop positions every > > pixel you > > > > > move... > > > > > > > > > > > > > > > > > This problem only occurs with dropOnEmpty set to > > true, > > > > > yet I > > > > > > > > > > must have > > > > > > > > > > > > > > the ability to empty these lists. > > > > > > > > > > > > > > > > > help :D > > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Oops... attacfhed On 6/14/07, Gareth Evans <agrath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Okay, so a bit more digging around... something appears to be weird with > the offset calcuations. > From my observations, the onHover handler and the onEmptyHover handler get > fired. > They both calculate where to insert an item, and one of them calculates it > differently to the other. > This results in the ''jitterbug'' i''ve referred to. > The patch earlier described (and documented on trac, but its actually a > patch for some other tree functionality) shows a if (child == null) > conditional around the final ''insert'' statements. > Because of this, I *think* that the for loop that appears above this if is > not actually required and it''s sufficent to just check children.length => 0. > Meaning, if there are no children elements then we want the onEmptyHover > to insert the element. > I''m not very familiar with the intricacies of Sortable, other than what > i''ve played with to get this working, but when I check children.length => 0 instead of having the for loop using offsets to identify if where the item > should go, the ''jitter'' effect goes away for me. > As previously mentioned, both onHover and onEmptyHover fire when i''m doing > a drag with dropOnEmpty:true. > > I''m trying to figure out what i''ve broken by removing the offset > calculation, and if it''s going to be an issue for anything else I might do > with Sortable later in my developments. > > Could one of the scripty gods read this thread and advise? > > I''ll attach a shortened version of my new dropOnEmpty code, which has some > other modifications to allow a ''marker'' element, from Tankut Koray, and > myself to make his code conditional. > I haven''t touched made any modifications to scripty base dragdrop.jsfunctions other than onEmptyHover but > unMark, onHover have been changed by Tankut, and markEmptyPlace and > createGuide have been created by him. I''ve since added if statements before > his code to read an options setting so I can turn his functionality off (I > only need it on one page) > > This issue has been driving me mad for weeks so it''d be good to get this > stuff sorted. > > http://dev.rubyonrails.org/ticket/7807 > This patch is similar but doesn''t quite fix the functionality in my app... > for some reason. > (It adds the if (child==null) which worked for junkmate''s app, but didn''t > work for mine, I had to go to the children.length == 0) > > Gareth > > On 6/13/07, Gareth Evans <agrath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Yeah, the demo is working but the fix *will not* work in my > > application... > > There must be more at play here... > > > > Gareth > > > > > > On 6/13/07, junkmate <junkmate-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > your demo looks good to me mate! Hopefully that should solve our > > > problems eh! > > > > > > right one job done, time for bed! > > > Will check again in the morning to see how you got on. > > > > > > > > > > > > On Jun 13, 2:42 am, "Gareth Evans" < agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Odd.. grabbed beta3, overwrote, added the if statement... all fixed. > > > > > > > I''ll try in my actual application now. > > > > > > > > Gareth > > > > > > > > On 6/13/07, Gareth Evans < agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > > > > > > Hey man > > > > > > > > > That was a good idea, I guess it fixed your prob but it doesnt > > > seem to > > > > > have fixed mine > > > > > > > > > Check it out > > > > >http://202.49.89.140/SortableExample.html > > > > > > > > > There''s a if (child==null) { } around the 3 lines you suggested. > > > > > > > > > I''ll try applying the aforementioned patch. > > > > > > > > > Gareth > > > > > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > in fact, you dont need to do all that. The answer relates > > > EXACTLY to > > > > > > what you said my man, with the two things fighting each other... > > > > > > > > > The only thing you need to add is some if child==null brackets > > > around > > > > > > the end of the onEmptyHover function: > > > > > > > > > > dropon.insertBefore(element, child); > > > > > > Sortable.options(oldParentNode).onChange(element); > > > > > > droponOptions.onChange(element); > > > > > > > > > > CHANGE ABOVE TO BELOW: > > > > > > > > > > if (child == null) { > > > > > > dropon.insertBefore(element, child); > > > > > > Sortable.options(oldParentNode).onChange(element); > > > > > > droponOptions.onChange (element); > > > > > > } > > > > > > > > > > On Jun 13, 1:49 am, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote: > > > > > > > FIXED:http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thr > > > . > > > > > > .. > > > > > > > > > > > Make the few suggested changes there and all works fine for > > > me! > > > > > > > > > > > On Jun 13, 1:29 am, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > hmmm. definately does. > > > > > > > > > > > > its annoying as every time i think ive fixed it by getting > > > the > > > > > > > > flickering to stop, it turns out that my modifications have > > > simlply > > > > > > > > disabled the dropOnEmpty functionality of the function :( > > > Will keep > > > > > > > > plodding on till I get there! Keep up the good work. > > > > > > > > > > > > On Jun 13, 1:20 am, "Gareth Evans" < agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > > wrote: > > > > > > > > > > > > > And a bit of evidence > > > > > > > > > I added insertions to the onEmptyHover and onHover > > > internal > > > > > > functions to > > > > > > > > > identify when they were being called. > > > > > > > > > I assigned an ''index'' attribute to every item in the > > > dom... > > > > > > > > > Then found all the insertBefore''s and got it to spit out > > > the > > > > > > index... this > > > > > > > > > is the output > > > > > > > > > > > > > onEmptyHover Insertion @ 8 > > > > > > > > > onHover > > > > > > > > > onHover > > > > > > > > > onHover > > > > > > > > > onHover > > > > > > > > > onHover > > > > > > > > > onHover Insertion @ 7 > > > > > > > > > onEmptyHover > > > > > > > > > onEmptyHover Insertion @ 8 > > > > > > > > > onHover > > > > > > > > > onHover Insertion @ 7 > > > > > > > > > onEmptyHover > > > > > > > > > onEmptyHover Insertion @ 7 > > > > > > > > > > > > > Looks like this is on the right track, agree? > > > > > > > > > > > > > Gareth > > > > > > > > > > > > > On 6/13/07, Gareth Evans < agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > > > As far as I can tell, > > > > > > > > > > In Create, it does some stuff that when dropOnEmpty is > > > true, it > > > > > > uses > > > > > > > > > > options_for_tree to create a droppable. > > > > > > > > > > This defines the onHover handler to be onEmptyHover. > > > > > > > > > > The default onHover handler is just onHover. > > > > > > > > > > > > > > Oohh here''s something interesting. > > > > > > > > > > > > > > I added an insertion for debug to both onHover and > > > onEmptyHover > > > > > > and *both* > > > > > > > > > > are firing when it jitters. > > > > > > > > > > > > > > If one was calculating the location to be above, and the > > > other > > > > > > below, > > > > > > > > > > under a certain condition- wouldn''t this cause the > > > effect we > > > > > > saw, as they''d > > > > > > > > > > fire sequentially, one would move it up, the other would > > > move it > > > > > > down... > > > > > > > > > > > > > > Gareth > > > > > > > > > > > > > > On 6/13/07, junkmate <junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > > > > yup I tracked it down to there too. I cant find the > > > "onHover > > > > > > function > > > > > > > > > > > when dropOnEmpty" is false though, so im unable to > > > compare. > > > > > > > > > > > > > > > ps. I find it interesting that this demo works > > > completely > > > > > > fine: > > > > > > > > > >http://wiki.script.aculo.us/scriptaculous/page/print/SortableFloatsDemo > > > > > > > > > > > > > > > > > > On Jun 13, 12:05 am, "Gareth Evans" < agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > > > > wrote: > > > > > > > > > > > > Yeah looks like the same bug to me, though much more > > > > > > accentuated on > > > > > > > > > > > yours. > > > > > > > > > > > > In dragdrop.js these lines appear to be responsible > > > > > > > > > > > > > > > > You can see i''ve added some debug insertions. > > > > > > > > > > > > What appears to happen is that as i move the item > > > up, one > > > > > > pixel at at > > > > > > > > > > > time, > > > > > > > > > > > > it sometimes goes into the top branch, and > > > occasionally into > > > > > > the > > > > > > > > > > > middle > > > > > > > > > > > > branch. > > > > > > > > > > > > > > > > This code reads *completely* differently to the > > > onHover > > > > > > function used > > > > > > > > > > > when > > > > > > > > > > > > dropOnEmpty:false. > > > > > > > > > > > > > > > > if(children) { > > > > > > > > > > > > var offset = Element.offsetSize (dropon, > > > > > > droponOptions.overlap) > > > > > > > > > > > * ( > > > > > > > > > > > > 1.0 - overlap); > > > > > > > > > > > > > > > > for (index = 0; index < children.length; > > > index += 1) > > > > > > { > > > > > > > > > > > > if (offset - Element.offsetSize(children[index], > > > > > > > > > > > > droponOptions.overlap ) >= 0) { > > > > > > > > > > > > offset -= Element.offsetSize(children[index], > > > > > > > > > > > > droponOptions.overlap); > > > > > > > > > > > > new Insertion.Top(''debug'',''topbranch<br/>'') > > > > > > > > > > > > } else if (offset - ( Element.offsetSize > > > (children[index], > > > > > > > > > > > > droponOptions.overlap) / 2) >= 0) { > > > > > > > > > > > > child = index + 1 < children.length ? > > > > > > children[index + 1] > > > > > > > > > > > : > > > > > > > > > > > > null; > > > > > > > > > > > > new Insertion.Top(''debug'',''midbranch<br/>'') > > > > > > > > > > > > break; > > > > > > > > > > > > } else { > > > > > > > > > > > > child = children[index]; > > > > > > > > > > > > new Insertion.Top (''debug'',''bottombranch<br/>'') > > > > > > > > > > > > break; > > > > > > > > > > > > } > > > > > > > > > > > > } > > > > > > > > > > > > } > > > > > > > > > > > > > > > > I confess i''m not even sure what it''s doing... at > > > this > > > > > > point. > > > > > > > > > > > > > > > > Gareth > > > > > > > > > > > > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > > > > > > > > > Heres my test page: http://www.oldsushi.com/testing.php > > > > > > > > > > > > > > > > > > > > Going there make your browser small enough so the > > > images > > > > > > are on two > > > > > > > > > > > > > lines, and you will see the problem when dragging > > > around > > > > > > the second > > > > > > > > > > > > > line and below. > > > > > > > > > > > > > > > > > On Jun 12, 11:10 pm, "Gareth Evans" < > > > agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > > > > > > > wrote: > > > > > > > > > > > > > > My problem, while related to dropOnEmpty as well > > > seems > > > > > > to only > > > > > > > > > > > occur > > > > > > > > > > > > > when my > > > > > > > > > > > > > > sortables are nested, which is why I can''t > > > replicate it > > > > > > on my test > > > > > > > > > > > page. > > > > > > > > > > > > > > I''ve been meaning to update my test page to > > > prove it so > > > > > > I have a > > > > > > > > > > > clean > > > > > > > > > > > > > page > > > > > > > > > > > > > > to debug from within, that I can post up (it''s > > > really > > > > > > hard to post > > > > > > > > > > > up an > > > > > > > > > > > > > > internal [read:burried] page of a web > > > application. > > > > > > > > > > > > > > I think there might be issues in the dropOnEmpty > > > code. > > > > > > > > > > > > > > > > > > Perhaps we should team up to debug the solution > > > at some > > > > > > point, > > > > > > > > > > > > > > What Instant Messaging tools do you use? > > > > > > > > > > > > > > > > > > On 6/13/07, junkmate < junkm...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > > wrote: > > > > > > > > > > > > > > > > > > > any update on this? I am having exactly the > > > same > > > > > > problem. > > > > > > > > > > > > > > > > > > > I have two Div containers, one on top of the > > > other, > > > > > > where you > > > > > > > > > > > can drag > > > > > > > > > > > > > > > from on to the other. > > > > > > > > > > > > > > > Each div is large enough for 5 images to fit > > > on one > > > > > > line. > > > > > > > > > > > > > > > > > > > With less than 5 images, dragging and dropping > > > is a > > > > > > pleasure, > > > > > > > > > > > with > > > > > > > > > > > > > > > everything looking great. However above 5 > > > images in > > > > > > one > > > > > > > > > > > container > > > > > > > > > > > > > > > forces the images on to two rows, and then > > > dragging > > > > > > problems > > > > > > > > > > > start. > > > > > > > > > > > > > > > The top row is still perfectly fine, but the > > > second > > > > > > row and > > > > > > > > > > > below it > > > > > > > > > > > > > > > is very difficult to drag your image where you > > > want it > > > > > > to land, > > > > > > > > > > > due to > > > > > > > > > > > > > > > constantly alternating drop positions every > > > pixel you > > > > > > move... > > > > > > > > > > > > > > > > > > > This problem only occurs with dropOnEmpty set > > > to true, > > > > > > yet I > > > > > > > > > > > must have > > > > > > > > > > > > > > > the ability to empty these lists. > > > > > > > > > > > > > > > > > > > help :D > > > > > > > > > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
I ran into the same problem, but with horizontal list. In my case, there are 3 rows containing 20 - 30 small icons (20 x 20px). In both versions, 1.7 and 1.7.1_beta3 the "shakeyness" starts after about the 6th or 7th icon. It seems that the error in the calculation for the drop position in dropOnEmpty gets larger and larger when there are more items in the row. At the 10th icon it''s about 25px left from the cursor, at the 20th icon - about 65px, etc. With the (child == null) fix, most icons behave properly, except the last 3-4. That comes from the same error in calculating the drop position, as when you hover over 1 or 2 icons before the last, dropOnEmpty calculated position is 80-90px left, so (child == null) fires. Unfortunately I''m not that good in js and can''t find where this error comes from (everything in the code looks good). As a workaround I''ve made a hidden last element with width:100px; float:right; margin- right:-110px; that compensates for the error and stops the "shakeyness" of the last few elements. Gareth, the (children.length == 0) didn''t work for me. It just disabled the dropOnEmpty functionality. Perhaps the markEmptyPlace and createGuide don''t work well in horizontal alignment. It also made dragging/hovering slower in IE6. On Jun 14, 12:23 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Oops... attacfhed > > On 6/14/07, Gareth Evans <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > Okay, so a bit more digging around... something appears to be weird with > > the offset calcuations. > > From my observations, the onHover handler and the onEmptyHover handler get > > fired. > > They both calculate where to insert an item, and one of them calculates it > > differently to the other. > > This results in the ''jitterbug'' i''ve referred to. > > The patch earlier described (and documented on trac, but its actually a > > patch for some other tree functionality) shows a if (child == null) > > conditional around the final ''insert'' statements. > > Because of this, I *think* that the for loop that appears above this if is > > not actually required and it''s sufficent to just check children.length => > 0. > > Meaning, if there are no children elements then we want the onEmptyHover > > to insert the element. > > I''m not very familiar with the intricacies of Sortable, other than what > > i''ve played with to get this working, but when I check children.length => > 0 instead of having the for loop using offsets to identify if where the item > > should go, the ''jitter'' effect goes away for me. > > As previously mentioned, both onHover and onEmptyHover fire when i''m doing > > a drag with dropOnEmpty:true. > > > I''m trying to figure out what i''ve broken by removing the offset > > calculation, and if it''s going to be an issue for anything else I might do > > with Sortable later in my developments. > > > Could one of the scripty gods read this thread and advise? > > > I''ll attach a shortened version of my new dropOnEmpty code, which has some > > other modifications to allow a ''marker'' element, from Tankut Koray, and > > myself to make his code conditional. > > I haven''t touched made any modifications to scripty base dragdrop.jsfunctions other than onEmptyHover but > > unMark, onHover have been changed by Tankut, and markEmptyPlace and > > createGuide have been created by him. I''ve since added if statements before > > his code to read an options setting so I can turn his functionality off (I > > only need it on one page) > > > This issue has been driving me mad for weeks so it''d be good to get this > > stuff sorted. > > >http://dev.rubyonrails.org/ticket/7807 > > This patch is similar but doesn''t quite fix the functionality in my app... > > for some reason. > > (It adds the if (child==null) which worked for junkmate''s app, but didn''t > > work for mine, I had to go to the children.length == 0) > > > Gareth >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Azaozz, I also Identified the problem myself as an increasing value in the dropOnEmpty iteration but I couldn''t trace where it was coming from other than the offset calculations. I think we have a general consensus that there is a bug here... I find it odd that junkmates fix worked for him, but not for me, my fix worked for me but not for you... I guess they''re workarounds rather than fixes. I need the guide code in my dragdrop for functionality on another screen so i''m willing to sacrifice a bit of performance for it... but I''m still not happy with my fixes to dragdrop- as I said, I wasn''t sure what else it would break, since I did no unit tests etc, it was mainly a quick hack to get things so they didn''t jitter... Anyone got any ideas here? Gareth On 6/21/07, azaozz <azaozz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > I ran into the same problem, but with horizontal list. In my case, > there are 3 rows containing 20 - 30 small icons (20 x 20px). In both > versions, 1.7 and 1.7.1_beta3 the "shakeyness" starts after about the > 6th or 7th icon. It seems that the error in the calculation for the > drop position in dropOnEmpty gets larger and larger when there are > more items in the row. At the 10th icon it''s about 25px left from the > cursor, at the 20th icon - about 65px, etc. > > With the (child == null) fix, most icons behave properly, except the > last 3-4. That comes from the same error in calculating the drop > position, as when you hover over 1 or 2 icons before the last, > dropOnEmpty calculated position is 80-90px left, so (child == null) > fires. > > Unfortunately I''m not that good in js and can''t find where this error > comes from (everything in the code looks good). As a workaround I''ve > made a hidden last element with width:100px; float:right; margin- > right:-110px; that compensates for the error and stops the > "shakeyness" of the last few elements. > > Gareth, the (children.length == 0) didn''t work for me. It just > disabled the dropOnEmpty functionality. Perhaps the markEmptyPlace and > createGuide don''t work well in horizontal alignment. It also made > dragging/hovering slower in IE6. > > On Jun 14, 12:23 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Oops... attacfhed > > > > On 6/14/07, Gareth Evans <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > Okay, so a bit more digging around... something appears to be weird > with > > > the offset calcuations. > > > From my observations, the onHover handler and the onEmptyHover handler > get > > > fired. > > > They both calculate where to insert an item, and one of them > calculates it > > > differently to the other. > > > This results in the ''jitterbug'' i''ve referred to. > > > The patch earlier described (and documented on trac, but its actually > a > > > patch for some other tree functionality) shows a if (child == null) > > > conditional around the final ''insert'' statements. > > > Because of this, I *think* that the for loop that appears above this > if is > > > not actually required and it''s sufficent to just check children.length=> > > 0. > > > Meaning, if there are no children elements then we want the > onEmptyHover > > > to insert the element. > > > I''m not very familiar with the intricacies of Sortable, other than > what > > > i''ve played with to get this working, but when I check children.length=> > > 0 instead of having the for loop using offsets to identify if where > the item > > > should go, the ''jitter'' effect goes away for me. > > > As previously mentioned, both onHover and onEmptyHover fire when i''m > doing > > > a drag with dropOnEmpty:true. > > > > > I''m trying to figure out what i''ve broken by removing the offset > > > calculation, and if it''s going to be an issue for anything else I > might do > > > with Sortable later in my developments. > > > > > Could one of the scripty gods read this thread and advise? > > > > > I''ll attach a shortened version of my new dropOnEmpty code, which has > some > > > other modifications to allow a ''marker'' element, from Tankut Koray, > and > > > myself to make his code conditional. > > > I haven''t touched made any modifications to scripty base > dragdrop.jsfunctions other than onEmptyHover but > > > unMark, onHover have been changed by Tankut, and markEmptyPlace and > > > createGuide have been created by him. I''ve since added if statements > before > > > his code to read an options setting so I can turn his functionality > off (I > > > only need it on one page) > > > > > This issue has been driving me mad for weeks so it''d be good to get > this > > > stuff sorted. > > > > >http://dev.rubyonrails.org/ticket/7807 > > > This patch is similar but doesn''t quite fix the functionality in my > app... > > > for some reason. > > > (It adds the if (child==null) which worked for junkmate''s app, but > didn''t > > > work for mine, I had to go to the children.length == 0) > > > > > Gareth > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
I think I''m on to something... The adding of a hidden element introduced some other "side effects". Instead I tried adding " - (children.length * 2)" to the offset calculation (line 763 in version 1.7.0) , so now it is: var offset = Element.offsetSize(dropon, droponOptions.overlap) * (1.0 - overlap) - (children.length * 2); That seems to fix it nicely, with or without the (child == null) patch. BTW in my previous post there''s an mistype. The offset calculation error happens on the right of the cursor, not left. On Jun 20, 3:43 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi Azaozz, > > I also Identified the problem myself as an increasing value in the > dropOnEmpty iteration but I couldn''t trace where it was coming from other > than the offset calculations. > I think we have a general consensus that there is a bug here... > I find it odd that junkmates fix worked for him, but not for me, my fix > worked for me but not for you... > I guess they''re workarounds rather than fixes. > > I need the guide code in my dragdrop for functionality on another screen so > i''m willing to sacrifice a bit of performance for it... but I''m still not > happy with my fixes to dragdrop- as I said, I wasn''t sure what else it would > break, since I did no unit tests etc, it was mainly a quick hack to get > things so they didn''t jitter... > > Anyone got any ideas here? > > Gareth > > On 6/21/07, azaozz <aza...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > I ran into the same problem, but with horizontal list. In my case, > > there are 3 rows containing 20 - 30 small icons (20 x 20px). In both > > versions, 1.7 and 1.7.1_beta3 the "shakeyness" starts after about the > > 6th or 7th icon. It seems that the error in the calculation for the > > drop position in dropOnEmpty gets larger and larger when there are > > more items in the row. At the 10th icon it''s about 25px left from the > > cursor, at the 20th icon - about 65px, etc. > > > With the (child == null) fix, most icons behave properly, except the > > last 3-4. That comes from the same error in calculating the drop > > position, as when you hover over 1 or 2 icons before the last, > > dropOnEmpty calculated position is 80-90px left, so (child == null) > > fires. > > > Unfortunately I''m not that good in js and can''t find where this error > > comes from (everything in the code looks good). As a workaround I''ve > > made a hidden last element with width:100px; float:right; margin- > > right:-110px; that compensates for the error and stops the > > "shakeyness" of the last few elements. > > > Gareth, the (children.length == 0) didn''t work for me. It just > > disabled the dropOnEmpty functionality. Perhaps the markEmptyPlace and > > createGuide don''t work well in horizontal alignment. It also made > > dragging/hovering slower in IE6. > > > On Jun 14, 12:23 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Oops... attacfhed > > > > On 6/14/07, Gareth Evans <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > Okay, so a bit more digging around... something appears to be weird > > with > > > > the offset calcuations. > > > > From my observations, the onHover handler and the onEmptyHover handler > > get > > > > fired. > > > > They both calculate where to insert an item, and one of them > > calculates it > > > > differently to the other. > > > > This results in the ''jitterbug'' i''ve referred to. > > > > The patch earlier described (and documented on trac, but its actually > > a > > > > patch for some other tree functionality) shows a if (child == null) > > > > conditional around the final ''insert'' statements. > > > > Because of this, I *think* that the for loop that appears above this > > if is > > > > not actually required and it''s sufficent to just check children.length=> > > > 0. > > > > Meaning, if there are no children elements then we want the > > onEmptyHover > > > > to insert the element. > > > > I''m not very familiar with the intricacies of Sortable, other than > > what > > > > i''ve played with to get this working, but when I check children.length=> > > > 0 instead of having the for loop using offsets to identify if where > > the item > > > > should go, the ''jitter'' effect goes away for me. > > > > As previously mentioned, both onHover and onEmptyHover fire when i''m > > doing > > > > a drag with dropOnEmpty:true. > > > > > I''m trying to figure out what i''ve broken by removing the offset > > > > calculation, and if it''s going to be an issue for anything else I > > might do > > > > with Sortable later in my developments. > > > > > Could one of the scripty gods read this thread and advise? > > > > > I''ll attach a shortened version of my new dropOnEmpty code, which has > > some > > > > other modifications to allow a ''marker'' element, from Tankut Koray, > > and > > > > myself to make his code conditional. > > > > I haven''t touched made any modifications to scripty base > > dragdrop.jsfunctions other than onEmptyHover but > > > > unMark, onHover have been changed by Tankut, and markEmptyPlace and > > > > createGuide have been created by him. I''ve since added if statements > > before > > > > his code to read an options setting so I can turn his functionality > > off (I > > > > only need it on one page) > > > > > This issue has been driving me mad for weeks so it''d be good to get > > this > > > > stuff sorted. > > > > >http://dev.rubyonrails.org/ticket/7807 > > > > This patch is similar but doesn''t quite fix the functionality in my > > app... > > > > for some reason. > > > > (It adds the if (child==null) which worked for junkmate''s app, but > > didn''t > > > > work for mine, I had to go to the children.length == 0) > > > > > Gareth--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
How interesting. I must have read that code a dozen times or more, trying to understand how it works... Why does the *2 work? And why does subtracting double the children work- maybe its something to do with padding? Gareth On 6/21/07, azaozz <azaozz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > I think I''m on to something... The adding of a hidden element > introduced some other "side effects". Instead I tried adding " - > (children.length * 2)" to the offset calculation (line 763 in version > 1.7.0) , so now it is: > var offset = Element.offsetSize(dropon, droponOptions.overlap) * (1.0 > - overlap) - (children.length * 2); > > That seems to fix it nicely, with or without the (child == null) > patch. > > BTW in my previous post there''s an mistype. The offset calculation > error happens on the right of the cursor, not left. > > On Jun 20, 3:43 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Hi Azaozz, > > > > I also Identified the problem myself as an increasing value in the > > dropOnEmpty iteration but I couldn''t trace where it was coming from > other > > than the offset calculations. > > I think we have a general consensus that there is a bug here... > > I find it odd that junkmates fix worked for him, but not for me, my fix > > worked for me but not for you... > > I guess they''re workarounds rather than fixes. > > > > I need the guide code in my dragdrop for functionality on another screen > so > > i''m willing to sacrifice a bit of performance for it... but I''m still > not > > happy with my fixes to dragdrop- as I said, I wasn''t sure what else it > would > > break, since I did no unit tests etc, it was mainly a quick hack to get > > things so they didn''t jitter... > > > > Anyone got any ideas here? > > > > Gareth > > > > On 6/21/07, azaozz <aza...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > I ran into the same problem, but with horizontal list. In my case, > > > there are 3 rows containing 20 - 30 small icons (20 x 20px). In both > > > versions, 1.7 and 1.7.1_beta3 the "shakeyness" starts after about the > > > 6th or 7th icon. It seems that the error in the calculation for the > > > drop position in dropOnEmpty gets larger and larger when there are > > > more items in the row. At the 10th icon it''s about 25px left from the > > > cursor, at the 20th icon - about 65px, etc. > > > > > With the (child == null) fix, most icons behave properly, except the > > > last 3-4. That comes from the same error in calculating the drop > > > position, as when you hover over 1 or 2 icons before the last, > > > dropOnEmpty calculated position is 80-90px left, so (child == null) > > > fires. > > > > > Unfortunately I''m not that good in js and can''t find where this error > > > comes from (everything in the code looks good). As a workaround I''ve > > > made a hidden last element with width:100px; float:right; margin- > > > right:-110px; that compensates for the error and stops the > > > "shakeyness" of the last few elements. > > > > > Gareth, the (children.length == 0) didn''t work for me. It just > > > disabled the dropOnEmpty functionality. Perhaps the markEmptyPlace and > > > createGuide don''t work well in horizontal alignment. It also made > > > dragging/hovering slower in IE6. > > > > > On Jun 14, 12:23 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Oops... attacfhed > > > > > > On 6/14/07, Gareth Evans <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > Okay, so a bit more digging around... something appears to be > weird > > > with > > > > > the offset calcuations. > > > > > From my observations, the onHover handler and the onEmptyHover > handler > > > get > > > > > fired. > > > > > They both calculate where to insert an item, and one of them > > > calculates it > > > > > differently to the other. > > > > > This results in the ''jitterbug'' i''ve referred to. > > > > > The patch earlier described (and documented on trac, but its > actually > > > a > > > > > patch for some other tree functionality) shows a if (child => null) > > > > > conditional around the final ''insert'' statements. > > > > > Because of this, I *think* that the for loop that appears above > this > > > if is > > > > > not actually required and it''s sufficent to just check > children.length=> > > > > 0. > > > > > Meaning, if there are no children elements then we want the > > > onEmptyHover > > > > > to insert the element. > > > > > I''m not very familiar with the intricacies of Sortable, other than > > > what > > > > > i''ve played with to get this working, but when I check > children.length=> > > > > 0 instead of having the for loop using offsets to identify if > where > > > the item > > > > > should go, the ''jitter'' effect goes away for me. > > > > > As previously mentioned, both onHover and onEmptyHover fire when > i''m > > > doing > > > > > a drag with dropOnEmpty:true. > > > > > > > I''m trying to figure out what i''ve broken by removing the offset > > > > > calculation, and if it''s going to be an issue for anything else I > > > might do > > > > > with Sortable later in my developments. > > > > > > > Could one of the scripty gods read this thread and advise? > > > > > > > I''ll attach a shortened version of my new dropOnEmpty code, which > has > > > some > > > > > other modifications to allow a ''marker'' element, from Tankut > Koray, > > > and > > > > > myself to make his code conditional. > > > > > I haven''t touched made any modifications to scripty base > > > dragdrop.jsfunctions other than onEmptyHover but > > > > > unMark, onHover have been changed by Tankut, and markEmptyPlace > and > > > > > createGuide have been created by him. I''ve since added if > statements > > > before > > > > > his code to read an options setting so I can turn his > functionality > > > off (I > > > > > only need it on one page) > > > > > > > This issue has been driving me mad for weeks so it''d be good to > get > > > this > > > > > stuff sorted. > > > > > > >http://dev.rubyonrails.org/ticket/7807 > > > > > This patch is similar but doesn''t quite fix the functionality in > my > > > app... > > > > > for some reason. > > > > > (It adds the if (child==null) which worked for junkmate''s app, but > > > didn''t > > > > > work for mine, I had to go to the children.length == 0) > > > > > > > Gareth > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Gareth, I''m still unclear where this error in calculating the offset
comes from. In theory, the code is fine. It just calculates where
you''re dropping. In practice when using small size Droppables, there
is an error of about 2px per Droppable, so by adding "-
(children.length * 2)", this error is corrected
("children.length" is
the number of children already in the container).
On Jun 20, 6:16 pm, "Gareth Evans"
<agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> How interesting.
> I must have read that code a dozen times or more, trying to understand how
> it works...
>
> Why does the *2 work?
> And why does subtracting double the children work- maybe its something to
do
> with padding?
>
> Gareth
>
> On 6/21/07, azaozz <aza...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
>
> > I think I''m on to something... The adding of a hidden element
> > introduced some other "side effects". Instead I tried adding
" -
> > (children.length * 2)" to the offset calculation (line 763 in
version
> > 1.7.0) , so now it is:
> > var offset = Element.offsetSize(dropon, droponOptions.overlap) * (1.0
> > - overlap) - (children.length * 2);
>
> > That seems to fix it nicely, with or without the (child == null)
> > patch.
>
> > BTW in my previous post there''s an mistype. The offset
calculation
> > error happens on the right of the cursor, not left.
>
> > On Jun 20, 3:43 pm, "Gareth Evans"
<agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > Hi Azaozz,
>
> > > I also Identified the problem myself as an increasing value in
the
> > > dropOnEmpty iteration but I couldn''t trace where it was
coming from
> > other
> > > than the offset calculations.
> > > I think we have a general consensus that there is a bug here...
> > > I find it odd that junkmates fix worked for him, but not for me,
my fix
> > > worked for me but not for you...
> > > I guess they''re workarounds rather than fixes.
>
> > > I need the guide code in my dragdrop for functionality on another
screen
> > so
> > > i''m willing to sacrifice a bit of performance for it...
but I''m still
> > not
> > > happy with my fixes to dragdrop- as I said, I wasn''t
sure what else it
> > would
> > > break, since I did no unit tests etc, it was mainly a quick hack
to get
> > > things so they didn''t jitter...
>
> > > Anyone got any ideas here?
>
> > > Gareth
>
> > > On 6/21/07, azaozz
<aza...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > > > I ran into the same problem, but with horizontal list. In my
case,
> > > > there are 3 rows containing 20 - 30 small icons (20 x 20px).
In both
> > > > versions, 1.7 and 1.7.1_beta3 the "shakeyness"
starts after about the
> > > > 6th or 7th icon. It seems that the error in the calculation
for the
> > > > drop position in dropOnEmpty gets larger and larger when
there are
> > > > more items in the row. At the 10th icon it''s about
25px left from the
> > > > cursor, at the 20th icon - about 65px, etc.
>
> > > > With the (child == null) fix, most icons behave properly,
except the
> > > > last 3-4. That comes from the same error in calculating the
drop
> > > > position, as when you hover over 1 or 2 icons before the
last,
> > > > dropOnEmpty calculated position is 80-90px left, so (child
== null)
> > > > fires.
>
> > > > Unfortunately I''m not that good in js and
can''t find where this error
> > > > comes from (everything in the code looks good). As a
workaround I''ve
> > > > made a hidden last element with width:100px; float:right;
margin-
> > > > right:-110px; that compensates for the error and stops the
> > > > "shakeyness" of the last few elements.
>
> > > > Gareth, the (children.length == 0) didn''t work for
me. It just
> > > > disabled the dropOnEmpty functionality. Perhaps the
markEmptyPlace and
> > > > createGuide don''t work well in horizontal
alignment. It also made
> > > > dragging/hovering slower in IE6.
>
> > > > On Jun 14, 12:23 am, "Gareth Evans"
<agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > Oops... attacfhed
>
> > > > > On 6/14/07, Gareth Evans
<agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > > > > > Okay, so a bit more digging around... something
appears to be
> > weird
> > > > with
> > > > > > the offset calcuations.
> > > > > > From my observations, the onHover handler and the
onEmptyHover
> > handler
> > > > get
> > > > > > fired.
> > > > > > They both calculate where to insert an item, and
one of them
> > > > calculates it
> > > > > > differently to the other.
> > > > > > This results in the ''jitterbug''
i''ve referred to.
> > > > > > The patch earlier described (and documented on
trac, but its
> > actually
> > > > a
> > > > > > patch for some other tree functionality) shows a
if (child => > null)
> > > > > > conditional around the final
''insert'' statements.
> > > > > > Because of this, I *think* that the for loop that
appears above
> > this
> > > > if is
> > > > > > not actually required and it''s sufficent
to just check
> > children.length=> > > > > > 0.
> > > > > > Meaning, if there are no children elements then we
want the
> > > > onEmptyHover
> > > > > > to insert the element.
> > > > > > I''m not very familiar with the
intricacies of Sortable, other than
> > > > what
> > > > > > i''ve played with to get this working, but
when I check
> > children.length=> > > > > > 0 instead of having the
for loop using offsets to identify if
> > where
> > > > the item
> > > > > > should go, the ''jitter'' effect
goes away for me.
> > > > > > As previously mentioned, both onHover and
onEmptyHover fire when
> > i''m
> > > > doing
> > > > > > a drag with dropOnEmpty:true.
>
> > > > > > I''m trying to figure out what
i''ve broken by removing the offset
> > > > > > calculation, and if it''s going to be an
issue for anything else I
> > > > might do
> > > > > > with Sortable later in my developments.
>
> > > > > > Could one of the scripty gods read this thread and
advise?
>
> > > > > > I''ll attach a shortened version of my new
dropOnEmpty code, which
> > has
> > > > some
> > > > > > other modifications to allow a
''marker'' element, from Tankut
> > Koray,
> > > > and
> > > > > > myself to make his code conditional.
> > > > > > I haven''t touched made any modifications
to scripty base
> > > > dragdrop.jsfunctions other than onEmptyHover but
> > > > > > unMark, onHover have been changed by Tankut, and
markEmptyPlace
> > and
> > > > > > createGuide have been created by him.
I''ve since added if
> > statements
> > > > before
> > > > > > his code to read an options setting so I can turn
his
> > functionality
> > > > off (I
> > > > > > only need it on one page)
>
> > > > > > This issue has been driving me mad for weeks so
it''d be good to
> > get
> > > > this
> > > > > > stuff sorted.
>
> > > > > >http://dev.rubyonrails.org/ticket/7807
> > > > > > This patch is similar but doesn''t quite
fix the functionality in
> > my
> > > > app...
> > > > > > for some reason.
> > > > > > (It adds the if (child==null) which worked for
junkmate''s app, but
> > > > didn''t
> > > > > > work for mine, I had to go to the children.length
== 0)
>
> > > > > > Gareth
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
I played a bit more with it and Gareth, you''re right. The extra pixels come from any margins between the Sortables. If you remove any distances between them, all works good, with or without the (child =null) patch. I wish this info was somewhere in the documentation: When creating many small size Sortables in a Droppable row or column, make sure there isn''t any margins between them, or the last few may jump around when trying to arrange them. So the "- (children.length * 2)" worked for me because there were 2px margins between them, but the proper way is to stack them without any distance and then use another element inside to make them "look nice". On Jun 20, 7:03 pm, azaozz <aza...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Gareth, I''m still unclear where this error in calculating the offset > comes from. In theory, the code is fine. It just calculates where > you''re dropping. In practice when using small size Droppables, there > is an error of about 2px per Droppable, so by adding "- > (children.length * 2)", this error is corrected ("children.length" is > the number of children already in the container). > > On Jun 20, 6:16 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > How interesting. > > I must have read that code a dozen times or more, trying to understand how > > it works... > > > Why does the *2 work? > > And why does subtracting double the children work- maybe its something to do > > with padding? > > > Gareth >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
ahh brilliant! I will modify my markup and return to using default scripty code... The margins between the objects should really be taken into account though! Gareth On 6/21/07, azaozz <azaozz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > I played a bit more with it and Gareth, you''re right. The extra pixels > come from any margins between the Sortables. If you remove any > distances between them, all works good, with or without the (child => null) patch. I wish this info was somewhere in the documentation: When > creating many small size Sortables in a Droppable row or column, make > sure there isn''t any margins between them, or the last few may jump > around when trying to arrange them. > > So the "- (children.length * 2)" worked for me because there were 2px > margins between them, but the proper way is to stack them without any > distance and then use another element inside to make them "look nice". > > On Jun 20, 7:03 pm, azaozz <aza...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Gareth, I''m still unclear where this error in calculating the offset > > comes from. In theory, the code is fine. It just calculates where > > you''re dropping. In practice when using small size Droppables, there > > is an error of about 2px per Droppable, so by adding "- > > (children.length * 2)", this error is corrected ("children.length" is > > the number of children already in the container). > > > > On Jun 20, 6:16 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > How interesting. > > > I must have read that code a dozen times or more, trying to understand > how > > > it works... > > > > > Why does the *2 work? > > > And why does subtracting double the children work- maybe its something > to do > > > with padding? > > > > > Gareth > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Guys, I face the same issue. I have a sortable with about 50 entries and the last one jumping around like crazy. Removing the margin seems to help, but is this the only way or is there a patch for this issue available? Cheers, Thomas On 21 Jun., 02:42, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> ahh brilliant! > I will modify my markup and return to using default scripty code... > The margins between the objects should really be taken into account though! > > Gareth > > On 6/21/07, azaozz <aza...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > I played a bit more with it and Gareth, you''re right. The extra pixels > > come from any margins between the Sortables. If you remove any > > distances between them, all works good, with or without the (child => > null) patch. I wish this info was somewhere in the documentation: When > > creating many small size Sortables in a Droppable row or column, make > > sure there isn''t any margins between them, or the last few may jump > > around when trying to arrange them. > > > So the "- (children.length * 2)" worked for me because there were 2px > > margins between them, but the proper way is to stack them without any > > distance and then use another element inside to make them "look nice". > > > On Jun 20, 7:03 pm, azaozz <aza...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Gareth, I''m still unclear where this error in calculating the offset > > > comes from. In theory, the code is fine. It just calculates where > > > you''re dropping. In practice when using small size Droppables, there > > > is an error of about 2px per Droppable, so by adding "- > > > (children.length * 2)", this error is corrected ("children.length" is > > > the number of children already in the container). > > > > On Jun 20, 6:16 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > How interesting. > > > > I must have read that code a dozen times or more, trying to understand > > how > > > > it works... > > > > > Why does the *2 work? > > > > And why does subtracting double the children work- maybe its something > > to do > > > > with padding? > > > > > Gareth--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hey We think that if your items need margin between them, you wrap them in an outer item that has no margin, and then the inner item (display only) has the margin. Therefore the draggable object has no Margin. Gareth On 7/17/07, Bart Simpson <thomas.fritzsche-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Hi Guys, > > I face the same issue. I have a sortable with about 50 entries and the > last one jumping around like crazy. Removing the margin seems to help, > but is this the only way or is there a patch for this issue available? > Cheers, > Thomas > > On 21 Jun., 02:42, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > ahh brilliant! > > I will modify my markup and return to using default scripty code... > > The margins between the objects should really be taken into account > though! > > > > Gareth > > > > On 6/21/07, azaozz <aza...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > I played a bit more with it and Gareth, you''re right. The extra pixels > > > come from any margins between the Sortables. If you remove any > > > distances between them, all works good, with or without the (child => > > null) patch. I wish this info was somewhere in the documentation: When > > > creating many small size Sortables in a Droppable row or column, make > > > sure there isn''t any margins between them, or the last few may jump > > > around when trying to arrange them. > > > > > So the "- (children.length * 2)" worked for me because there were 2px > > > margins between them, but the proper way is to stack them without any > > > distance and then use another element inside to make them "look nice". > > > > > On Jun 20, 7:03 pm, azaozz <aza...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Gareth, I''m still unclear where this error in calculating the offset > > > > comes from. In theory, the code is fine. It just calculates where > > > > you''re dropping. In practice when using small size Droppables, there > > > > is an error of about 2px per Droppable, so by adding "- > > > > (children.length * 2)", this error is corrected ("children.length" > is > > > > the number of children already in the container). > > > > > > On Jun 20, 6:16 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > How interesting. > > > > > I must have read that code a dozen times or more, trying to > understand > > > how > > > > > it works... > > > > > > > Why does the *2 work? > > > > > And why does subtracting double the children work- maybe its > something > > > to do > > > > > with padding? > > > > > > > Gareth > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---