XYplorer Beta Club

What exactly is the bug? What happens and what should happen instead? Or what doesn't happen that should happen?

It was expected that the right click button menu would work on the overflow dropdown (chevron drop down)
Having it interupt workflow on that occasion has made me consider if it would be advantageous if the selection of mouse or shift + mouse between scrolling toolbar buttons and scrolling button sets could be served by user preference to determine the action, as I can see others could well prefer the current setting.
It would be best if the overflow dropdown menu buttons could have the other mouse actions available.

Ian wrote: ↑28 Aug 2024 02:00 It was expected that the right click button menu would work on the overflow dropdown (chevron drop down)

Right button is not supported to allow hot select on mouseup (mouse down to open the menu, move to the desired menu item, mouseup to select it). This does not work if the menu supports right button clicks. Why not? Ask Microsoft.

Ian wrote: ↑28 Aug 2024 02:00 Having it interupt workflow on that occasion has made me consider if it would be advantageous if the selection of mouse or shift + mouse between scrolling toolbar buttons and scrolling button sets could be served by user preference to determine the action, as I can see others could well prefer the current setting.
It would be best if the overflow dropdown menu buttons could have the other mouse actions available.

Hmm, not sure what you are saying here. "shift + mouse between scrolling toolbar buttons" ???

admin wrote: ↑28 Aug 2024 08:59 Hmm, not sure what you are saying here. "shift + mouse between scrolling toolbar buttons" ???

I think what Ian is getting at is, if you have "Scrollable toolbar" checked in Toolbar options, then we are forced to use "shift scroll" to flip between toolbar button sets. It would be nice if we had the option to reverse that (i.e., with that "Scrollable toolbar" checked we could switch toolbar button sets with a clean scroll (no mod) and scroll the toolbar itself with shift scroll). Of course, this would be a tweak or option. I tend to agree only since switching toolbar button sets would be a higher priority than scrolling the toolbar.

Klownboy has the gist of one part of my comment. But the microsoft constraint mentioned by admin causes the main workflow break when in reduced XY window size, which I was sort of hoping would be possible to work around during this time, because of the reduced bug list.
Having quickly responded in the early hours it would seem useful to describe part of my working practices with the mouse to clarify and substantiate my wish and Klownboys comment.
On the toolbar a few button sweetspots exist (dependent upon the dual panes (and tabs) layout at the time - F10 key combinations). Many people appear to naturally group their most used buttons in those areas but frequently maintain purely logical visible groupings. My own learned preference is to place the most used buttons in those sweetspots across the four toolbar button sets, breaking up toolbar logical groupings, but gaining immediately accessible button positions in the sweetspot(s) at the most regularly used XY window size.
In that type of configuration moving between the most useful buttons in a given scenario becomes no more than a slight movement of the mousewheel button to change the button set and bring a desired button immediately into focus beneath the mouse cursor position. Minimal mouse movement/actions. Yes a similar situation can be achieved by mouse wheel scrolling the current toolbars more logically visible button layout, to bring a required button into position, but the necessary wheel movement is greatly increased.
What becomes lost is part of that visible button group layout logic within individual button sets in favour of a button layout across button sets based upon workflow. What is gained is a four dimensional sweetspot button layout (increasing useful buttons in those positions) making them more quickly accessible using a simple and very limited mousewheel movement.
An additional observation -- being a touch typist for many decades, the CKS's are really useful, but the mouse, coupled with various button scripting options in XY at times create various advantages.

I have a feeling that we might as well leave things as they are.

Ah well, thank you for considering it. I had hoped something like an optional undocked floating toolbar could have provided an answer.
{But anyway XY as ever has an alternative answer} so it is back to the additional scripting and toolbar command to solve it.
Keep up the good work as XY does enable many answers.