Dragging Panel Tasks/Icons Behaves Poorly

The current algorithm for swapping icons on the taskbar requires overlap between the items. This leads to the following problem where if you go past the end without hitting the last icon, the icon you’re dragging won’t swap itself at the end of the list.

drag

The correct algorithm is supposed to be:

  1. When the mouse moves, and we are dragging,

  2. Take the GridLayout which has all the icons and create a copy without including the one which is being dragged.

  3. Now, for(i) the length of the gridlayout, re-insert the item at the given (i)

    1. Layout the copy so that every item is in it’s final ‘x’ positions.

    2. Get the ‘x’ of the re-inserted element and compare it against the actual real draggingItemX

    3. Whichever index resulted in the least distance between the two, is the index we have to swap with

  4. Perform the element swap on the actual GridLayout, and animate items which moved.

A visualizer of the algorithm:
https://jmanc3.github.io/draggable-list-algorithm/

The actual swap algorithm source:
https://github.com/jmanc3/draggable-list-algorithm/blob/7947d135bf2946dbbd4c2f9e28267c0bdaa711f2/index.html#L179

The feel of dragging off the end of the list and having no swap occur, is really bad and needs to be fixed. The KDE panel cannot be the premier windows alternative and fail at the one things it’s supposed to do.

Now imagine that your intention is to drag this icon to elsewhere on the panel, and drop it, to create an icon widget there.

In your video, I see you move the icon one position to the right, then stop moving the icon by dragging the icon off the task manager widget, to your desktop, and then to an empty area of the panel. Dropping it in either of those places would create an icon there. Dragging back to the task manager will allow you to continue moving it if you want to do that.

I’m not so sure this is behaving poorly.

Edit:

To be more clear: You didn’t do that. You didn’t drag it off the end of the list. You dragged it off the middle. If you do drag it off the end of the list, it will move to the end of the list.

Edit2: While I’m doing late-edits: That visualiser is cool

Here’s a thought… Perhaps there is a problem here. Not quite the one you thought, but… yeh…

OK so with the floating panel, there’s this space below the panel where you can see the desktop:

If you click in that space, you will see that, in order to exploit Fitts’ Law, you do not actually click on the desktop, you click on the panel above it.
(“exploit Fitts’ Law” can be read as “slam the cursor into the bottom edge of your display and use that edge as a safety rail so you can have sloppy aim and still hit”)

BUT, when you drag over that area, it is NOT treated as panel, it is treated as desktop.

I think maybe the reason why you ‘missed’ with your mouse is that you’re expecting to be able to exploit Fitts’ Law with this panel - because the developer has gone to some lengths to ensure that generally does work… But, I guess it doesn’t work consistently between a click and a drag, so that might be causing some of the bad feels you had?

drag_actual

Here I keep the mouse inside the taskbar the entire time but it still misses the swap at the end.

I’ve looked at the source and can confirm the swap is overlap based, which means its very very easy to miss swaps; and of course, if you miss off the end, it’ll never get swapped until you overlap. You can even get ugly chugging within the tasks as I captured in the video above. (BTW, I know about the throttle in the code to slow down swaps, but even if overlap checking was was sped up, overlap based swapping always runs the risk of missing and leaving the taskbar in a junky state).

The lightweight copy of the GridLayout should only copy over the items sizing requirements (margin, padding, target_w, and so on), without copying any of the content of the task such as the icon texture.

The drag behaviour needs to be brought inline with mac/windows taskbars so that users first impression is good, expected ux. (It’s very important that this is fixed and dragging becomes a good experience).

(I tried looking into if I could fix it myself but I couldn’t figure out if qml let you create ‘non-shown’ copies and lay them out without putting them on the screen. If it doesn’t, you’d just copy over the sizing properties and do a basic layout manually. It’d probably end up around ~80 lines of code, but as I said, it’s important.)

That looks broken, but unrelated to the original problem you demonstrated. This is just the thing not updating on every frame, which it needs to do if it’s meant to be reacting to user input. If you do that exact same thing without moving the mouse so fast, it’ll work like you expected.

You should report this as a bug.

You just edited so obviously you already understand this:

even if overlap checking was was sped up,

And you edited again:

throttle in the code to slow down swaps

Yeh well, that’s a ‘feature’ then I guess. I don’t like it at all. I’d still report it as a bug.

but

overlap based swapping always runs the risk of missing and leaving the taskbar in a junky state

overlap based, which means its very very easy to miss swaps

I don’t see this problem. Aside from the above bug, are you able to demonstrate this? I can’t get it to fail. If I click, drag an icon, drag it off the panel as if I had missed, then drag it back on as if I were correcting myself, it works.

The drag behaviour needs to be brought inline with mac/windows taskbars

That wouldn’t make sense, since plasma panels function differently (eg my above example wouldn’t work on windows).

The lightweight copy of the GridLayout should only copy over the items sizing requirements (margin, padding, target_w, and so on), without copying any of the content of the task such as the icon texture.

Why? Sounds ugly. Why not just move it all?

I couldn’t figure out if qml let you create ‘non-shown’ copies and lay them out without putting them on the screen

Have you figured out if that’s a good way to do it? That sounds like it could create a heavy workload prior to every potential move (meaning, on every click). Could it reliably complete in time on various hardware? Would it interfere with the other operations of the widget? Is it even necessary when all the ‘icons’ have the same dimensions? Etc etc.

How can it not be the intention of the user to move the icon to the end of the list, if they drag out the icon from slot 1, and then move their mouse in the empty section past the end of the list?

I don’t know of a single taskbar that doesn’t interpret that action as meaning the user wants to move the task to the end of the list.

The state of dragging in the panel right now is not a fashion statement like single-click to open is. It’s just poor UX.

Please refer to my first sentence of my first reply.

If you don’t understand, just try it. Grab the firefox icon for this window, drag it up out of the panel, and then back down into part of the panel which is to the right of the task manager, and drop. Look, you just created a ‘Quick Launch’ style icon.

Take note: You can put that icon wherever on the panel, whichever panel, or desktop, that you like. This is extremely pertinent to this particular discussion.

I don’t know of a single taskbar that doesn’t interpret that action as meaning the user wants to move the task to the end of the list.

Now you do :smiley:

There is a lot which is possible with KDE Panels which is not possible with Windows’ or MacOS’s taskbar. It makes sense on windows, to move the task, when you drop in that empty space - because it couldn’t do anything else. We don’t have that problem on KDE :grin:

That’s exactly my point. The area after the tasks IS part of the task manager region, as you yourself admit:

AKA: if you stay within the task manager region, only swaps should happen, and you need to go PAST the end of the task manager region to exhibit the pin behaviour you describe.

But what I’m saying is that if the user is dragging the task WITHIN the task manager region, the expected behaviour is that their icon will moved to the slot best represented by the users intention WITHIN THE TASK MANAGER REGION.

Do you understand what I’m saying?

No I didn’t admit to that, I think you’ve misinterpreted my replies, as I would not suggest that, because I know it not to be true. Sometimes it is, sometimes it is not. It’s up to the user how they configure it.

Yes I understand and have also responded to this already in an earlier reply:

I did get it to fail with one very specific usage:

  1. have a task manager widget which has empty space on the end
  2. leave the task manger widget during a drag (so, NOT WITHIN THE TASK MANAGER REGION. WHY ARE WE YELLING?)
  3. re-enter the empty space in the task manager widget

Is this specific set of criteria the one you have a problem with? I can’t tell. I’m trying to guess, which is why I asked you to demo. OR YOU COULD JUST KEEP YELLING. YOU’RE NOT MY REAL DAD
:rofl:

Yes, but leaving and coming back isn’t relevant. Even if the user never leaves the task manager region, if the user drags the task past the end of the current tasks, but still within the task manager region, the expected behaviour is for the task to be moved to the end as that’s the clear intention of the action of dragging anywhere WITHIN the task manager region. But yes dragging the task out and back in just makes it more clear that this is failing.

The blank space next to a Task Manager widget is sort of a no-man’s-land, The area could be used by it, as it needs to expand with open windows and added app pins. But it also is space used to add other widgets.

I could swear there used to be a drop-target when moving Task Manager icons, but I am very likley wrong, and confusion this with the one you get when dragging a widget to the panel or rearranging them, and a widget would slide out of the way.

I know I have helped more than a few folks who have tried to drag a task manager icon to the right or left, hoping to have it as a separate launcher.

2 Likes

Again I will ask you to demonstrate this. How else would they get to the empty space at the end without making the ‘overlap’ thus causing the move? (Ignoring the timing bug discussed above, of course)

The mouse positions qml reports can be separated by more pixels than the total width of an icon, thus skipping over tasks if the mouse is moving fast enough. It’s what the second video I posted shows? Either way, replacing the task swap overlap algorithm for something which accounts for moving past the end of the list will solve it either way so who cares as long as it gets fixed.

I think you missed a spot :rofl:

Edit- sorry I should have read to the end.

your reply didn’t answer this either:

Did you read any of it or just ignore it all and choose to argue?

You wanna fix both, right? If you fix the timing thing then this specificity is critical to reproducing the bug.

No it’s not. What if it’s a virtual mouse and doesn’t even poll. I can still reproduce that bug.

No. It’s about the polling rate of the mouse. If a mouse only reports positions every 10 ms. It’s entirely possible the user has moved more pixels than the width of an icon and will therefore cause the overlap based swap to miss.

Apologies, I screwed up my reply and was editing it when you replied. See above.

I don’t even have words. The only explanation is that you are AI.

You could outsmart AI.

Locking this thread to prevent further unproductive insults.

Feel free to start a new one, and avoid the rudeness there. Generally bringing an attitude isn’t conducive to getting a problem resolved, even when you feel frustrated.