Library sidebar: customize hover expand delay

[ronso0]

The default 250 ms is too short for my taste and is a bit annyoing especially when using a trackpad where I not always hit the target on first attempt.
And when this came up in the forums recently I made it customizable.

IMO this is a property like the double-click interval that should be customizable to suits users's needs / capabilities.

Looks like this

[github-actions]

This PR is marked as stale because it has been open 90 days with no activity.

[daschuer]

The code looks good. Do we have a demand for a short delay especially? I can confirm that it is quite quick. So I think we should pick a higher value by default.

Testing all this, the behaviour does not feel 100 % natural.

• Playlist opens when you move over a long folder name which may take 250 ms.
  • here we may require to stop 250 ms at a single point or small area.
• Collapsing feels "random".
  • Maybe it is fixed with an even longer delay?
• The attempt to scroll to a crate below the viewing range is tricky, not reasonable do-able IMHO.
  • I have not yet testes it what the problem is. It somehow interferes with open and collapse.

The normal use case is:

• show the drop target, before dragging
• move to it
• done

Here collapse is counter intuitive.

[ronso0]

I have rebased to resolve the conflicts, and I also fixed restoring the value from config.

I also set the minimum to 500 ms

[ronso0]

Testing all this, the behaviour does not feel 100 % natural.

• Playlist opens when you move over a long folder name which may take 250 ms.

  • here we may require to stop 250 ms at a single point or small area.

• Collapsing feels "random".

  • Maybe it is fixed with an even longer delay?

• The attempt to scroll to a crate below the viewing range is tricky, not reasonable do-able IMHO.

  • I have not yet testes it what the problem is. It somehow interferes with open and collapse.

I can confirm something strange is going with the timer. After the cursor left the sidebar (drag canceled) I saw Crates expand, even though that shouldn't be possible (cursor pos can't be resolved to a sidebar item).
I'm trying with a singleshot QTimer instead of QBasicTimer, maybe that fixes it 🤷‍♂️

The normal use case is:

• show the drop target, before dragging
• move to it
• done

I don't understand, please explain.

Btw the original Qt implementation does only expand, but collapse does make sense in Mixxx in case you accidentally expanded a branch with loooooooots of items.
https://github.com/qt/qtbase/blob/15640cda50995c79e092ec99774385df48a0dc15/src/widgets/itemviews/qtreeview.cpp#L1268-L1275

[daschuer]

With normal use case I ment users that don't expect auto expand. This should be a first class citizen. Unintended open or closing branches create the annoyance.

[ronso0]

Got it.
Of course we could make auto-expand opt-in, but considering how long this feature exists that would be a breaking change. Not sure if users go to the preferences looking for a fix.

How about introducing that change in QML, like when the entire GUI is new to everyone?

[daschuer]

I don't mean to make it opt in. I actually would prefere to make the auto open feature work just "right" without any preference option. But I don't have stong demands.
Currently the timer solution kicks in even when the target crate is visible, this should not happen and is a test case here.

[ronso0]

Well, "just right" varies.. by I guess I konw what you mean.

Currently the timer solution kicks in even when the target crate is visible, this should not happen and is a test case here.

How should the sidebar know what the target is?
I noticed I start dragging a track without looking at the sidebar (let's say target is a playlist). Currently I'm somewhere deep in a Computer tree, but I don't care since I know that Playlists is above Computer and I can either hover Computer to collapse the tree (and thereby pull Playlists into the view) or do auto-scroll by hovering the top region of the sidebar.

I think an even longer delay would help avoid more accidents (1 s ??) while still keeping auto-expand/collapse functional for those how use it regularly.

[daschuer]

I need to test, but 500 ms sounds like a reasonable time reach the target crossing other folders without collapsing.
Not sure if I hit the timer issue you mentioned last time.
Probably one issue is that even hovering on the empty space behind the label open the folder.
Can we require to hover the label only?
My other idea was to require to pause the mouse movement. for open.

[ronso0]

Probably one issue is that even hovering on the empty space behind the label open the folder.

Hmm, I think this depends on the column width which is determined by the widest item, which is full view width by now (with the stretched items #15330)

[ronso0]

Can we require to hover the label only?

Sure that is feasible, just requires a QStyleOption and computing some of the item/text metrics to get the rect of what we see when the item is selected. Though a proper SidebarItemDelegate would be better, eg. to allow styling drag-hover only with qss.

[daschuer]

This does not sound like a no brainer. If you prefer to not spend the time any other improvement is also fine.
Just give a hint when I shall test.

[ronso0]

The delay customization is ready for testing.

[ronso0]

I did a test to get a stylable drag-only hover effect and it seems to work well. Will publish when it's ready.

FWIW I already added SidebarItemDelegate for #14508 and the Computer library data view PR. I think this is a solid base for the 'expand when hovering label only' function, but it may collide (UX-wise) with the full-width click responsiveness.

[ronso0]

This is ready btw, the issues we discovered are no regressions.