Repository navigation
drag heuristics can make it hard to place items (ex: web demo) #1094
Description
Is there a way to alter behavior when one widget is dragged on top of other? In the demo below I am trying to insert widget "7" between "9" and "2". If I drag it directly into the gap - it assumes I want insert "7" above "2" and pushes "2" down even thought I drag "7" thru the lower portion of "2". Only if I drag "7" all the way around and over "9" directly - it moves "9" down.
Is it possible to keep the widget that is being dragged over in place to a certain point (say when widget being dragged is at over 50% of its height) ?
Activity
adumesny commentedon Dec 16, 2019
I agree, the heuristics could use some tweaking, and be more like over the second half vs the first half - it's also not clear if it uses the mouse position or just the box outline (or something in between).
[-]Keep widget being dragged over in place[/-][+]drag heuristics can make it hard to place items (ex: web demo)[/+]ataft commentedon Feb 5, 2020
I'm having a similar issue when trying to drag to the bottom. As you can see in the demo below, I have to drag the widget about 90% over the bottom widgets in order for it to move:
Prid13 commentedon Sep 1, 2020
Any update on this? I'm looking into gridstack.js and it's quite promising, but the weird behavior when dragging and dropping is counter intuitive to me.
Like @ataft demonstrated, dragging an element below another requires about 90% of height to be below the target in order to work.
Any fix in the works, or options to tweak this as per personal preference? :)
adumesny commentedon Sep 1, 2020
on my very long todo list... but first get 2.0 out, then likely focus on this.
ranjeettamil commentedon Nov 3, 2020
@adumesny Waiting for features from very long time,
Please add this feature in upcoming release.
adumesny commentedon Nov 3, 2020
@ranjeettamil are you willing to pay for it ? there is a donate button (I sure didn't see your $$ contributions) and very few people bother contributing or helping with this project, yet expect things to be magically done for them for free... and silence...
Prid13 commentedon Nov 3, 2020
@adumesny: I'm sure he didn't mean it like that. How big of a donation are we talking about to get this feature in motion asap? I'm willing to chip in and @ranjeettamil maybe you are too? :)
adumesny commentedon Nov 14, 2020
@Prid13 only @ataft has donated $50 so far which is very much appreciated. heck, if most people that use gridstack would even give 'beer money', someone could possibly make this a fulltime gig... never heard from @ranjeettamil again.
If a few people are willing to back this one, I'll take a look. I'm pretty sure this is not an easy one at all... been tried before (a reason same bug #141 has been sitting for 5.5 years!)
ranjeettamil commentedon Nov 24, 2020
@adumesny I am developer and working for client, I already convey and shared the link to them.
Prid13 commentedon Nov 25, 2020
@adumesny I would also only be able to donate a $50 at max, unfortunately.
I'm thinking of using this in a Chrome extension I'm working on that I'm also hoping to monetize. If I ever make money off of it, I'll be sure to donate a generous amount towards the development of gridstack.js 😄
adumesny commentedon Dec 13, 2020
I may have some time during the holidays to work on this... I think I can get the instant swapping of items of the same size (rather than require 90% down) first - that would also solve the use case where the grid is full and you can't move anything in any directions, and having a 1 row of items and not being able to move sideways.
the two example with very different sized items and involving moving more than one collision is much more complicated and I don't fully understand the current collision check yet. And is not based on % coverage.
get that donation going!
26 remaining items
adumesny commentedon Feb 28, 2021
ok, I see it now. yep still an issue. this is getting incredibly hard and I need to take a break for all of this...
adumesny commentedon Mar 15, 2021
think I finally nailed it after spending the weekend (again! - code coming soon) on it fine tuning it and advanced cases I had not tried before ('load 3' is particularly tricky). Will be in v4
At some point I can further tune the 50% overage (so either shape will trigger) and if before or after the shape (tiny cell moving over the large case example could be improved).
20210314_195343.mp4
collision: more edge case fixes
collision: more edge case fixes
pawel-k-kazmierczak commentedon Apr 16, 2021
Hi,
I'm not sure wheather it is related to this issue but I notice unexped behaviour while drag and drop:
gridstack.drag.to.last.mp4
-for longer widget it works
-for shorter is not possible to drop it from top to bottom.
thanks
adumesny commentedon Apr 16, 2021
^^^ that's #219 (in your second example we need to add extra rows) which I've fixed in general as long as the cursor stays in the grid (we don't do shape leaving event, but cursor driven), but for some reason that page example isn't growing the grid. I noticed that too but have not looked at it. May want to post your vid to the other bug (and see mine similar that do work). AGain that webpage doesn't work as the other....
Ironically our webpage is the worst possible example showing all the collisions we've always had :)
pawel-k-kazmierczak commentedon Apr 19, 2021
Thank you! I reproduced it on not home page :)
collision: re-open 1094