One extra detail, something I've learned from 20 years of working on dragging all kinds of objects around the GUI of Ardour [0]: handle ALL button press and release events as drag events where there is no movement. That is: press ALWAYS starts a drag that is finished by the release, and the code that handles release "special cases" the no-movement condition.
Draggable objects
81–90 of 147 posts
Re: Draggable objects
#82A fantastic site. When I originally took over teaching Intro to AI, I initially relied on the A* search closed/open set pseudocode explanation[1]. However, when it would come time to ask students to implement it, I was constantly finding students absolutely confused by the approach. Once I swapped over to Amit's A* explanation, the number of confused students dropped significantly. Forever thankful for their walkthro…
That's great to hear — thank you!
No thank you! If you're ever near the NC side of the US let me know, I'll gladly buy you lunch for all the help you've given me.
Re: Draggable objects
#83This article is about dragging, and I've run into all of the pitfalls and come to the same solutions that Amit talks about. Excellent article! One of the hardest things I have needed to code from scratch is drag-to-reorder. It seem so natural from a user perspective, but when you get into inconsistently sized items, having to create placeholders between items, detecting edges, going down rabbitholes of box-fitting al…
I have a trick for this that I love that is very general:
1. When a user begins dragging, calculate the layouts for all possible drop targets (or perhaps just those that are currently visible). 2. For each of those layouts record the position the dragged objects ends up in. 3. On each mouse movement, select from those positions the one that's closest to the dragged object's current position 4. Render the selected layout
This ends up feeling really good and works for any kind of complex layout / reflow.
Re: Draggable objects
#84Amit Patel is the man. I always say his last name like Matthew Patel says his name in Scott Pilgrim. Side note: Sebastian Lague is great too.
> I always say his last name like Matthew Patel says his name in Scott Pilgrim
One of the seven evil hexes :D
Re: Draggable objects
#85This article is about dragging, and I've run into all of the pitfalls and come to the same solutions that Amit talks about. Excellent article! One of the hardest things I have needed to code from scratch is drag-to-reorder. It seem so natural from a user perspective, but when you get into inconsistently sized items, having to create placeholders between items, detecting edges, going down rabbitholes of box-fitting al…
Oof, or drag-to-reorder while supporting nesting.
I've always been surprised that Apple added this functionality to the iOS home screen without having a solution to the reorder vs nesting UI problem. Trying to move an app into a folder often results in the folder deciding to fly out of the way and let the item take its place when you're really trying to drop something on the folder to insert it.
Re: Draggable objects
#86One extra detail, something I've learned from 20 years of working on dragging all kinds of objects around the GUI of Ardour [0]: handle ALL button press and release events as drag events where there is no movement. That is: press ALWAYS starts a drag that is finished by the release, and the code that handles release "special cases" the no-movement condition. [0] https://ardour.org/
What’s the rationale here?
Re: Draggable objects
#87This article is about dragging, and I've run into all of the pitfalls and come to the same solutions that Amit talks about. Excellent article! One of the hardest things I have needed to code from scratch is drag-to-reorder. It seem so natural from a user perspective, but when you get into inconsistently sized items, having to create placeholders between items, detecting edges, going down rabbitholes of box-fitting al…
I have a trick for this that I love that is very general: 1. When a user begins dragging, calculate the layouts for all possible drop targets (or perhaps just those that are currently visible). 2. For each of those layouts record the position the dragged objects ends up in. 3. On each mouse movement, select from those positions the one that's closest to the dragged object's current position 4. Render the selected lay…
Very nice
Re: Draggable objects
#88Drawflow is good
Re: Draggable objects
#89This article is about dragging, and I've run into all of the pitfalls and come to the same solutions that Amit talks about. Excellent article! One of the hardest things I have needed to code from scratch is drag-to-reorder. It seem so natural from a user perspective, but when you get into inconsistently sized items, having to create placeholders between items, detecting edges, going down rabbitholes of box-fitting al…
I had to tackle this problem for my index card app, Card Buddy. [1] It was definitely a fun challenge and I still found a better way to do it later.
What I ended up doing is when you pick up a card, I compute the layout as if the card was deleted from the board, and then it becomes easy. Wherever you hover the mouse, I just displace whatever is there.
There were still tons of edge cases I had to work out, though, especially when you start editing a new card that hasn’t been “committed” to the data model yet. I had to add the option to shift existing cards out of the way to make room for a phantom card.
It helps to recognize that there are just lots of edge cases you have to manually handle. If you try to tackle it as though there’s a more generic/homogeneous solution, you end up going around in circles a bit with the design. I should probably create a blog post on all the different edge cases.
As I said, though, I found an even better way to do my layout, which saves on unnecessary computations and makes the layout engine more flexible and user-friendly. (It’s amazing what a difference your choice of data model representation makes on your solution.) It’s been a fun puzzle to solve!
Re: Draggable objects
#90One extra detail, something I've learned from 20 years of working on dragging all kinds of objects around the GUI of Ardour [0]: handle ALL button press and release events as drag events where there is no movement. That is: press ALWAYS starts a drag that is finished by the release, and the code that handles release "special cases" the no-movement condition. [0] https://ardour.org/
What’s the rationale here?
Having separate code paths for "it's a press", "it's a release", "it's a drag" just turns into a nightmare when you actually use all 3 input events extensively. Remember that while the motion events of the drag might be the visually interesting part, for the most part the interesting stuff happens at the beginning and end of them - i.e. the press and release.
It becomes massively simpler conceptually (and even in the code) to treat any button press as a potential drag, and a simple click becomes just a drag-with-no-movement.