toolbar scrolling

[graham]

I really like this new feature - I guess if it were in Windows 7 it might be classed as gloss but very useful. If you could, say double click on the tool bar to get it to revert to the default start position then it would be fantastic.

Whilst saying nice things about this new feature the zoom is also, for me, very welcome - great stuff agian!

[TheQwerty]

If you could, say double click on the tool bar to get it to revert to the default start position then it would be fantastic.

I'd say middle click feels like it would be more natural, but that might just be because the click & drag method doesn't work here.

It's a pretty gloss, but it's not for me; I'd rather have that overflow button/menu. For me it's very important that the GUI is fairly static. That ensures that it's easy for the user to learn, grow habits with, and then it respectively gets the heck out of their way and let's them work!

Graham's suggestion helps with this since it makes it possible to start working with the toolbar from a familiar state each time, but I'd say the above is a very good reason to never make this scrolling the default behavior. It might also help if perhaps when enabled the toolbar becomes one button shorter, and that space is divided by stationary arrows on either side which serve as a visual clue; they could also allow fine-tuned scrolling by a single button.


Again, it's a neat effect and solution, just not for me. That said, don't take this as my declaration to be the first fool asking for the traditional overflow methods. I don't (yet) have a need for any of these and if/when I do that overflow button/menu is easy enough to build through scripting/CTB.


EDIT: After a restart and re-enable the dragging works, but middle click still feels like it would be better. Double-click could be an accidental single click on a button after all, or vice versa.

[j_c_hallgren]

I had posted this in the other thread but it's more approp here so moved following text:
---------------------

However, having tried it out now, there are some things that I'd love to see to make it (and related ) even better:

1) I wish there were a way to have some things fixed and others scollable, so that I could keep my core functions at left side unmoving yet scroll thru the lesser used items on right...this is one case where having a ">>" drop-down style (like quick launch) is better as nothing moves...not sure what to suggest but having my basic navigation icons shift around isn't helping when I need to do some other function briefly.

Maybe have a way to define (instead of plain separators) a ">>" and/or "<<" as bookends that would allow you to scoll just whatever part of TB that you wanted? This, combined with #2 below, would allow me to break up my TB/AB in 3 parts: fixed / scrollable / fixed width AB.
And if the area available for scrollable was less than the width of actual icons within that area, it would hide those to right initially....so I could have, let's say, 15 fixed/always shown icons, a "<<", 15 more icons, and a ">>" but with only enough screen area to show 25 icons total, the rightmost 5 would not show unless the ">>" was clicked.

2) When I add on extra TB icons, the AB gets pushed so far to the right that it totally goes off screen and vanishes! So...could we have a setting where we define the minimum width of AB in pixels?

[admin]

It's a pretty gloss, but it's not for me; I'd rather have that overflow button/menu. For me it's very important that the GUI is fairly static.

Yep, same here. After I finally finished the code and tried it in real life I found that it not that practical for me. I have a positional memory: My buttons may rather change their look than their position. Anyway, it does not harm to have it...

Conc. the click to go back to initial state: hm. My middle-click is programmed to do a double-click since ages and I think this is true for many users. So it could only be the double click, but I don't think this is a good solution.
A possibility would be to revert to the default start position when the mouse is outside the toolbar when releasing the button. But again, not an optimal solution. Hm.

Multiple scrollable areas: I expected this wish, but as suggested by j_c_hallgren, it's not possible (= too difficult). Easier would be to allow 2 toolbars in a row. But that's another chapter... later...

[j_c_hallgren]

Conc. the click to go back to initial state:

If there were a ">>" bookend to click to scroll, a right-click on that could be used as a reset...having this bookend would also give user a way to invoke scroll without any chance of accidently clicking on a icon when all you wanted to do was drag it.

Multiple scrollable areas: I expected this wish, but as suggested by j_c_hallgren, it's not possible (= too difficult). Easier would be to allow 2 toolbars in a row. But that's another chapter... later...

Yes, a 2nd row would help us who wouldn't mind losing some vertical space to see extra icons in a fixed place.

Any comments on the idea/request for a settable minimal width for AB when it appears on same line as TB? Which could then force excess TB icons to be hidden until scrolled.

[zer0]

While I welcome this general concept, I also feel that the way it is implement will benefit from the following improvements:

- Have an ability to enable/disable "cycle through" of buttons. As it stands, mouse wheeling keeps buttons cycling in a carousel in the space provided. Ala TheQwerty, this doesn't do much for it being static and only scrolling when there are more buttons than allocated space.
- Have an overflow button (again, like TheQwerty). If one does not have a mouse, and when I often travel with my laptop I either don't have a mouse or it's not ergonomically possible to use one, a user cannot scroll the toolbar (or is that possible?).
- Allow for more CTBs. This can be accomplished either by the way of adding another batch of vanilla buttons or to create one vanilla button that can be added an unlimited number of times.
- User-specified dynamic resizing of toolbar-allocated space. This is particularly applicable when toolbar is combined on the same row with either tabs/AB and will allow for more toolbar visibility.

[admin]

While I welcome this general concept, I also feel that the way it is implement will benefit from the following improvements:

- Have an ability to enable/disable "cycle through" of buttons. As it stands, mouse wheeling keeps buttons cycling in a carousel in the space provided. Ala TheQwerty, this doesn't do much for it being static and only scrolling when there are more buttons than allocated space.
- Have an overflow button (again, like TheQwerty). If one does not have a mouse, and when I often travel with my laptop I either don't have a mouse or it's not ergonomically possible to use one, a user cannot scroll the toolbar (or is that possible?).
- Allow for more CTBs. This can be accomplished either by the way of adding another batch of vanilla buttons or to create one vanilla button that can be added an unlimited number of times.
- User-specified dynamic resizing of toolbar-allocated space. This is particularly applicable when toolbar is combined on the same row with either tabs/AB and will allow for more toolbar visibility.

- Don't see the gain of this.
- I currently cannot add buttons that will not scroll themselves with the bar...
- If you don't have a mouse (or sth equivalent) you cannot use the toolbar anyway.
- Something along that line is planned.

[zer0]

- Don't see the gain of this.

I assume that you're referring to an ability to turn on/off "cycle through"? Isn't that wish reminiscent of how XYplorer handles tab scrolling as per this thread: http://www.xyplorer.com/xyfc/viewtopic.php?f=5&t=4294? I see no reason why the same concept(s) would not apply here.

- I currently cannot add buttons that will not scroll themselves with the bar...

Interesting, but having an overflow button is an alternative to scrolling. It is potentially more user-friendly. Or were you referring to having unlimited buttons? What would stop a button from scrolling with the bar?

- If you don't have a mouse (or sth equivalent) you cannot use the toolbar anyway.

No sweat, I found a way to scroll using a trackpad, so it's

[admin]

- Don't see the gain of this.

I assume that you're referring to an ability to turn on/off "cycle through"? Isn't that wish reminiscent of how XYplorer handles tab scrolling as per this thread: http://www.xyplorer.com/xyfc/viewtopic.php?f=5&t=4294? I see no reason why the same concept(s) would not apply here.

- I currently cannot add buttons that will not scroll themselves with the bar...

Interesting, but having an overflow button is an alternative to scrolling. It is potentially more user-friendly. Or were you referring to having unlimited buttons? What would stop a button from scrolling with the bar?

- If you don't have a mouse (or sth equivalent) you cannot use the toolbar anyway.

No sweat, I found a way to scroll using a trackpad, so it's

The unsolvable problems with overflow dropdown:
- no pushed state
- no context menu
- no menu button (like MyComputer)
- no arrow button (like Back, Forward)

Concerning the scrolling toolbar: let's see how it turns out it public practice... it's too early (too theoretical) to talk about changing details. Give the rough version some weeks...

[admin]

- Allow for more CTBs. This can be accomplished either by the way of adding another batch of vanilla buttons or to create one vanilla button that can be added an unlimited number of times.

Rather another batch. Advantage: you can remove the user buttons from the current toolbar while keeping the their definitions in store and ready for reshow.

[TheQwerty]

The unsolvable problems with overflow dropdown:
- no pushed state
- no context menu
- no menu button (like MyComputer)
- no arrow button (like Back, Forward)

Well they are solved by making the buttons smarter about when they are part of the overflow menu, after all they need to realize they have become menu items instead of toolbar buttons. And also by the fact that there needs to be an understanding that when a button is part of the overflow unfortunately some concessions must be made.

So pushed state becomes check marks.
Menu buttons become sub-menus.
Context menus (is this useful feature even found in other programs?) are unfortunately no longer accessible.
Arrow buttons lose their arrows and they and CTBs only have their default left-click action.


But I wonder if it wouldn't be possible for you to create an overflow toolbar instead of menu, so when it is clicked there is a temporary toolbar with these buttons?

[graham]

admin wrote:

Yep, same here. After I finally finished the code and tried it in real life I found that it not that practical for me. I have a positional memory: My buttons may rather change their look than their position. Anyway, it does not harm to have it...

Yes I prefer a normal static row of familiar positioned common use buttons but surely this scolling feature is only if you need access to additional buttons that are used less frequently. As such I do think this feature has merit but I too wish it always revert automatically to the normal static row after i have scrolled etc.

Another approach is to forget scrolling and have an 'overflow' button but this has the problem of a reduced number of overflow buttons whereas the scrolling approach could allow ALL available buttons to be accessed - now that is actually quite good as it means you don't have to go through the menus to 'activate' or searchout a button.

[zer0]

Rather another batch. Advantage: you can remove the user buttons from the current toolbar while keeping the their definitions in store and ready for reshow.

I can't see that being a good long-term solution. With extra list columns on the menu, my (and probably others') XYplorer window is destined to become wider, which translates into more space for CTBs. With multiple rows and small icons in mind, about 40-50 vanilla CTBs would be a good start