Toolbar dropdown flaws

[zer0]

Thank you for adding a dropdown. No rush or anything but...

1. Dropdown doesn't respect icon size -- small icons are used even if large size is specified in TB' config.
2. TB name is displayed -- if a dropdown is meant to be a vertical extension of TB, then only icons need to be displayed (with caption text on mouseover).
3. Keyboard shortcuts shown in the dropdown even if that option is turned off.
4. Dropdown items are static as of the moment a dropdown is created -- scrolling TB items has no effect on items in the dropdown.

Cheers!

[admin]

Thank you for adding a dropdown. No rush or anything but...

1. Dropdown doesn't respect icon size -- small icons are used even if large size is specified in TB' config.
2. TB name is displayed -- if a dropdown is meant to be a vertical extension of TB, then only icons need to be displayed (with caption text on mouseover).
3. Keyboard shortcuts shown in the dropdown even if that option is turned off.
4. Dropdown items are static as of the moment a dropdown is created -- scrolling TB items has no effect on items in the dropdown.

Cheers!

1. standard like this. there are no big icons in a menu anyway.
2. standard like this
3. yep, will fix
4. aah, you mean wheeling (funny like many of you say scrolling when you mean wheeling -- but I'm getting used to it) -- yep, will fix

[zer0]

1. standard like this. there are no big icons in a menu anyway.

Not sure that I agree. I checked in Explorer on XP and, when you create an overflow, big icons remain

2. standard like this

Hmm, it creates a potentially unpleasant scenario of having a wide menu simply because of a single long button name

Also, just updated to build .0326 and on my Win 7 (haven't tested on XP yet) all icons of items in the overflow change to an icon of the very last item in that menu list

[serendipity]

I'll add one more here, though its not a flaw but a missing feature.
The overflowing buttons cannot be right-clicked and hence no menus. One can scroll and get them back on toolbar but maybe its possible to make the right-click on overflow work.

[admin]

I'll add one more here, though its not a flaw but a missing feature.
The overflowing buttons cannot be right-clicked and hence no menus. One can scroll and get them back on toolbar but maybe its possible to make the right-click on overflow work.

Yep, this is not possible technically.

[zer0]

In build .0327, overflow drop-down doesn't display an icon if Redo is greyed out.

I'll add one more here, though its not a flaw but a missing feature.
The overflowing buttons cannot be right-clicked and hence no menus. One can scroll and get them back on toolbar but maybe its possible to make the right-click on overflow work.

Yep, this is not possible technically.

But is it possible to have drop-down functionality for left-clicks while preserving showing of the menu ala drop-down for Views in Explorer?

P.S. There is no visual indication in the overflow menu that a menu item results in a drop-down menu list ala Views in Explorer's overflow.

P.P.S. When clicked from the overflow, the menu list for Views won't always derive from mouse pointer's tip, but may derive from where Views would be in the toolbar. So far, the only situation where I can reproduce this is when Views is 2nd from the left in TB arrangement and the whole TB is in the overflow menu.

[admin]

In build .0327, overflow drop-down doesn't display an icon if Redo is greyed out.

I'll add one more here, though its not a flaw but a missing feature.
The overflowing buttons cannot be right-clicked and hence no menus. One can scroll and get them back on toolbar but maybe its possible to make the right-click on overflow work.

Yep, this is not possible technically.

But is it possible to have drop-down functionality for left-clicks while preserving showing of the menu ala drop-down for Views in Explorer?

P.S. There is no visual indication in the overflow menu that a menu item results in a drop-down menu list ala Views in Explorer's overflow.

P.P.S. When clicked from the overflow, the menu list for Views won't always derive from mouse pointer's tip, but may derive from where Views would be in the toolbar. So far, the only situation where I can reproduce this is when Views is 2nd from the left in TB arrangement and the whole TB is in the overflow menu.

not possible
- there are 3 dots as visual indication...
-- confirmed and fixed

[zer0]

- there are 3 dots as visual indication...

Ellipsis is commonly used to indicate that further information needs to be provided. This is not the case with drop-down lists, so using ellipsis to indicate such is misleading at best. As a GUI aficionado, I think we should try -- if possible -- to nail down new UI features right in terms of best practices straight from the get-go

P.S. Is it possible to have Views menu in the overflow as a pull-out ala Menu bar -> View -> Current Tab -> Views? That would be spot on

[serendipity]

I'll add one more here, though its not a flaw but a missing feature.
The overflowing buttons cannot be right-clicked and hence no menus. One can scroll and get them back on toolbar but maybe its possible to make the right-click on overflow work.

Yep, this is not possible technically.

This is a limiting thing i would say. I guess thats why you gave us the scroll thing first. OK, overflow is not for me then.
Another idea would be to:
Say I have 30 buttons, only 20 are shown in my current toolbar and rest (10) are overflown. A shortcut key would show the 10 overflown buttons in the current toolbar. The same key would switch back to original 20 buttons.
In other words:
With the current toolbar scroll i find it confusing when my buttons move around. I would rather prefer a static toolbar with one set of buttons and the option to see all the overflown buttons with one key press (or some other way). So if i have 60 buttons, i see 1-20 buttons now, one key press: i see 21-40, another key press: 41-60. Its quicker to learn button positions this way than the current way, plus we will have right-click menus for all of them.

[zer0]

In other words:
With the current toolbar scroll i find it confusing when my buttons move around. I would rather prefer a static toolbar with one set of buttons and the option to see all the overflown buttons with one key press (or some other way).

I'm with serendipity on this one. If clicking the chevron would dynamically "compress" other items on the same row to reveal excess TB buttons, then it'd be quite useful. For layout with just the toolbar in that row the current architecture will do...but we're getting into the wishes here

[TheQwerty]

Say I have 30 buttons, only 20 are shown in my current toolbar and rest (10) are overflown. A shortcut key would show the 10 overflown buttons in the current toolbar. The same key would switch back to original 20 buttons.

I almost suggested something similar but, what if instead of scrolling by buttons it scrolled by "toolbars", which would work as you describe, but still with the mouse. A notch on the wheel corresponds with the next/previous "toolbar"

In fact I could see there being 2 actions:
A1) Scroll by Button
A2) Scroll by Toolbar

and 4 (really 8 ) events:
E1) Wheel Up/Down
E2) Ctrl (or another modifier)+Wheel Up/Down
E3) Click+Drag Left/Right
E4) Click+Drag Up/Down

By default E1/E3 would perform scroll by button, and E2/E4 would do scroll by toolbar.
And then we can argue over switching E1 and E2's default setting.

[serendipity]

Say I have 30 buttons, only 20 are shown in my current toolbar and rest (10) are overflown. A shortcut key would show the 10 overflown buttons in the current toolbar. The same key would switch back to original 20 buttons.

I almost suggested something similar but, what if instead of scrolling by buttons it scrolled by "toolbars", which would work as you describe, but still with the mouse. A notch on the wheel corresponds with the next/previous "toolbar"

In fact I could see there being 2 actions:
A1) Scroll by Button
A2) Scroll by Toolbar

and 4 (really 8 ) events:
E1) Wheel Up/Down
E2) Ctrl (or another modifier)+Wheel Up/Down
E3) Click+Drag Left/Right
E4) Click+Drag Up/Down

By default E1/E3 would perform scroll by button, and E2/E4 would do scroll by toolbar.
And then we can argue over switching E1 and E2's default setting.

Yup, sounds good to me. And one can argue either ways for E1 and E2 depending what you prefer most. I would say E1 and A2 should tie the knot.

[admin]

- there are 3 dots as visual indication...

Ellipsis is commonly used to indicate that further information needs to be provided. This is not the case with drop-down lists, so using ellipsis to indicate such is misleading at best. As a GUI aficionado, I think we should try -- if possible -- to nail down new UI features right in terms of best practices straight from the get-go

P.S. Is it possible to have Views menu in the overflow as a pull-out ala Menu bar -> View -> Current Tab -> Views? That would be spot on

IMO ellipsis is used when there will be another interface before any action happens.

PS: not possible.

[admin]

I see that not everybody is fully satisfied with the recent wonderful toolbar enhancements. However, I will leave it as it is for now and move on to other shores. There might be TB 2.0 one day...

[zer0]

There's still a little niggle -- if you have time to attend to it -- regarding an overflow chevron being able to cut off a part of left-most TB icon -- when resizing XY window manually -- as per screenshot attached

tb_overflow.png