Request: Specify where buttonbar wraps

[Clo]

2Hacker

Hi Roman !

What if there is not enough vertical space?

• Good point ! It's a reason for which I prefer scrolling…

 KR
Claude
Clo

[Lefteous]

2Hacker

What if there is not enough vertical space?

Well not providing such drop-downs would result in line-wrapping which means more button bar lines and more vertical space is required. So my idea is also a vertical space saver.
Applications should have a minimal height which should still display a minimal but usable set of UI elements.

2Clo
Sorry but I think scrolling is just cumbersome in this context. It's also visually distracting as button positions are changing when scrolling.

[JohnFredC]

2Christian

You wrote:

Total Commander 7.5 will support both a user-defined line break in the bar (command: -2) and an unlimited number of lines! It's already implemented.

Thank you very very much! Implementing that request is an effective bribe to ameliorate my vocal frustration in the forum!!!

TC is the greatest!

Thanks again!

[fenix_productions]

Maybe words are not good enough to describe this problem. There could be some mix for this forum's ideas. So not symbol for "wrap" but for "new line". The buttons which will not fit into bar would be shown in menu like XnView does it BUT for each line standalone. Scrolling is not a nice idea imho because you cannot see what is next easily. If the "new line" model would be implemented there could be the place for buttons right alignment too.

Or maybe multiple lines for XnV like menus would be too messy?

[Clo]

Lefteous

Again…

Sorry but I think scrolling is just cumbersome in this context.
It's also visually distracting as button positions are changing when scrolling.

• It's no more distracting than to look for a wanted icon in a menu-list…
If scrolling, I'll see it appearing necessarily without searching.
- Generally, I know (roughly) the order of my icons in a bar, and I've six bars.
-------------------------
fenix_productions

Hi !

…Or maybe multiple lines for XnV like menus would be too messy?

• In XnView you may get only one bar at once per view mode (empty “View” window, “View” with an open file, browser).
Yes, several lines are not desirable.

• There too, I'ld prefer scrolling, because when you have a very small window,
the menu-list showing the rest of icons is getting a bit monstruous.
- However, notice that the list is displayed “on-top” outside the main window,
thus there is no need for a minimal height of the window (it can be reduced down to zero).

KR
Claude
Clo

[m^2]

Lefteous

Again…

Sorry but I think scrolling is just cumbersome in this context.
It's also visually distracting as button positions are changing when scrolling.

• It's no more distracting than to look for a wanted icon in a menu-list…
If scrolling, I'll see it appearing necessarily without searching.
- Generally, I know (roughly) the order of my icons in a bar, and I've six bars.
-------------------------
fenix_productions

Hi !

…Or maybe multiple lines for XnV like menus would be too messy?

• In XnView you may get only one bar at once per view mode (empty “View” window, “View” with an open file, browser).
Yes, several lines are not desirable.

• There too, I'ld prefer scrolling, because when you have a very small window,
the menu-list showing the rest of icons is getting a bit monstruous.
- However, notice that the list is displayed “on-top” outside the main window,
thus there is no need for a minimal height of the window (it can be reduced down to zero).

KR
Claude
Clo

1. With menu, you can find and execute any entry with 2 clicks. With scrolling you have to move mouse right until you find the correct one, click and restore the normal buttonbar position.
2. I also find it distractive to have icons on different positions during scrolling.

[jb]

My idea would be a drop-down at the end of each line…

• We have it in XnView, but the icons are shown as their normal size (not reduced like on your pic).

• A couple of small scroll buttons could do the trick too, personally I would like that as well…
- I mean : scroll the visible portion of the bar < Bw ¦ Fw > in order to see all icons…

OpenOffice 2.2. does it almost exactly like XnView 1.92. I prefer this solution.
Even the old Microsoft Office 2000 does it similar, but shows only icons without text in the drop-down area.

Scroll buttons have the following disadvantages compared to a drop-down button:
- Occupy more room (2 scroll buttons instead of 1 drop-down button)
- Generally you will not see all hidden buttons with one click.
- You have to scroll back to get the previous view. I consider this as disadvantage, others may consider it as benefit.

The scroll buttons approach is already used by some tab controls and I think it has NOT proved to be a good solution.

[Clo]

2jb

Hello !

…
- Occupy more room (2 scroll buttons instead of 1 drop-down button)

• Sorry, wrong. It can take the same room, simply as a button split into two parts : >> (top) and << (bottom).

…- Generally you will not see all hidden buttons with one click

.
• Where did I say “one click” ? That's not the way to use.
Click and keep pressed to scroll smoothly up to the wanted icon…
- It could work even without buttons (mouse gestures).

kR
Claude
Clo

[StickyNomad]

I'd strongly prefer a dropdown list here. After I have oped it, I can see the icons on one glance and click the desired one. Having to keep a scroll-button pressed until the icon drives by would be way to time consuming and distracting because of the moving buttons, as already stated.

About vertical space: Even when using a resolution of 640 x 480, there would be vertical room for about 15 icons (32x32), maybe one or two less because of TCs title and menu bar. When using 1024 x 768, the nr of icons increases to ~24. I think this should suffice for most cases.

If the vertical space needed for the wrapped icons really would exceed the available room (which would be quite seldom IMHO), I can see two possibilities:

1. At the top and bottom of the dropdownlist, up/down arrows could be displayed that would scroll that box vertically on Mouseover (I know I said that I don't like scrolling above, but this way the scrolling would be necessary only when vertical space is exceeded, and not in every case).

2. Display the dropdown using multiple columns

[nsp]

Why not having an automatic resizing, like the one of rocket dock Let say from 1x1 to 48x48 with zoom in tooltip and automatic scroll L/R !

But to be honest i think that too many button in the same interface is not productive, having "nested context toolbars" is probably smth to investigate also !

[JohnFredC]

We have been living for years with a single toolbar that wraps when the TC window becomes too narrow.

Since Mr. Ghisler says that soon we can have as many lines of toolbar as we want via the linebreak "button" (-2), surely we can populate our toolbars in such a way that the lines rarely if ever wrap?

I'm optimistic.

[jb]

If the vertical space needed for the wrapped icons really would exceed the available room (which would be quite seldom IMHO), I can see two possibilities:

1. At the top and bottom of the dropdownlist, up/down arrows could be displayed that would scroll that box vertically on Mouseover (I know I said that I don't like scrolling above, but this way the scrolling would be necessary only when vertical space is exceeded, and not in every case).

2. Display the dropdown using multiple columns

Possibility 1 seems to be common practice. Windows treats its Start menu this way and OpenOffice 2.2 treats the drop-down list for hidden buttons this way.

Possibility 2 is not "scalable", that is, even multiple columns do not guarantee that there is always enough space.

[ghisler(Author)]

Currently lines which become too long still wrap. Since the number of lines is now unlimited, this doesn't matter, you just get more lines.

I'm thinking about implementing something like TCmenu internally for those with really many buttons, but I'm not yet sure what to do when there are too many buttons. Use scrolling? Or have multiple columns?

[m^2]

I like neither current wrapping nor scrolling...but scrolling is definitely worse.

[JohnFredC]

I'm thinking about implementing something like TCmenu internally for those with really many buttons, but I'm not yet sure what to do when there are too many buttons. Use scrolling? Or have multiple columns?

An easily populated "drop-down menu" button-type in TC? My goodness! Let me sit down a moment and absorb that.

From my perspective, a simple solution to "too many buttons" would be to implement this "something like TCMenu internally" as a mechanism to display user-defined hierarchical menus, a la the current TC Start Menu.

That is, click (or hot-key) the button, get the user-defined hierarchical menu assigned to that button, displayed beneath the button.

Now that would be the cat's meow.