Size Change: +317 B (0%)

Total Size: 1.19 MB

_{compressed-size-action}

Hey Adam (I am looking at the UI approach.)

This is what I see:

Dragging the widget over the Footer 2 closed widget area, creates a sudden jerk/push downward of the cursor. Here it would be better to calmly drag a widget over the closed area, and have the area open downward. It should not affect the drag only the area.

Here is the old Widget screen in comparison:

What is great about the old method is that it does nothing with the drag as it happens.
It only opens the widget areas smoothly with a short delay and shows the space to where one can drop it into. (For the newer version we have the blue line.)
If one decides not to drop it into the new widget area and moves the cursor back to the initial widget area the second area automatically closes. Go for something similar to the old method.

@paaljoachim my thoughts exactly! That's what I meant by asking:

I wonder if we should add a timeout and some indication that the widget area is about to uncollapse @mapk ?

If the user wants to drag the widget from sidebar number 1 to sidebar 8, the current jerk will make it pretty hard so I think we should indicate that the area is about to open, but still give user a chance to keep dragging. I'm not sure how that indication would look like, hence I pinged @mapk :-)

@paaljoachim I think your suggestion to makes collapsing/uncollapsing smooth would make a great feature not just here, but also for the Panel component.

Hey 👋 there. I really like auto-expanding the area when dragging over it! I do also agree with @paaljoachim's feedback. The jump that occurs right now is confusing.

I wonder if we should add a timeout and some indication that the widget area is about to uncollapse @mapk ?

I don't think we need an indicator necessarily. The expansion of the area seems to be a sufficient. Moving the dragged block into a collapsed area should open it but retain its positioning on screen and not jump to a particular point. Dragging it back out of the area should collapse that area again. I like how it works in the Classic Widget screen that Paal shared. When opening up an area on drag, the blue line drop indicator should appear above any existing widgets in that area if the user is dragging downward from one area to another area below. This should reverse when dragging up from an area below to an area above.

There is some similar code in the navigation-link block that might be reusable (cc @kevin940726), but still think this works well enough as a first iteration.

I think it's nearly there, the last part is smooth panel animation - let's make it a separate PR.

I just gave this a go again! Really close! I'm still noticing a jump when dragging into a longer widget area. Can we just expand the widget area downward without the jump? I also saw that when leaving a widget area that expanded, it doesn't collapse again. Is this possible?

Testing this, I'm still unable to drag a widget into an empty widget area. Even though the empty now opens when dragged over, there's no drop indicator and dropping a widget on it doesn't work. How easy would it be to fix it in this PR? Or better to open another issue?

@tellthemachines The fix was only recently merged - #26051

It's either that this PR needs to be rebased, or it might also need to be updated to account for the selectors mentioned here:
#25992 (comment)

I tested this and for me it did not work.

I tested again. Either I am not testing correctly as it seems to be showing an older commit.
I use this testing method for testing a commit (I tested the bottom commit):
git fetch origin pull/25992/head
git checkout 83919b51665b6c3fc0732d2e23b1a2c256e02e1c
npm run build

This is what I see:

There is still a jumpiness when dragging from one widget area to another. As it jumps too far down.
I just looked closer at the gif and there seems to be some jumpiness also with the drop zone. I believe it might have to do with holding the cursor close to the top widget/block. As the blue line can come and go.