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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote:
> > > > > Oops... attacfhed
>
> > > > > On 6/14/07, Gareth Evans <[EMAIL PROTECTED]> 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 [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
