Faster Toolbar Setup & Use

Re: ...

Posted: Fri Dec 24, 2004 1:08 pm
Post subject: Toolbar Won't Change (Some) Display Icons
... To change icon right-click button on toolbar, Appearance->Change Icon. This is the only way to change icons on TLB. Changing icons from the Windows Shell (explorer) can be ignored by TLB. If you want to use the shell icons then try to right-click button on toolbar, Appearance->Reset Icon.

These instructions solved my problem. Now, I have some suggestions on making the process of setting-up a multi-button TLB faster, and easier to use.

. 1. The TLB context menu (right-click, menu-click) needs accelerator keys defined. Currently, it has none.

. 2. Allow context menus and submenus to remain open after a select-click (left-click), to allow clicks on other context menu items without having to re-open the menu after each select-click. For instance, in creating each of the 8 icons on my new TLB (see SNAG-0000.gif) I needed to uncheck "Appearance > Enable tip", followed by a select-click of "Appearance > Change Icon". The menu didn't need to always close on me after the first mouse action.

. 3. Allow a "simple browse" of user icon folders. My own icon folder contains ~1,000 icons, all labeled. The TLB icon browser ignores icon names, and thereby makes some icons very difficult to find, as I remember them with an accuracy of only 2 or 3 alphabetical letters (first characters of their names). It would be _much_ faster to browse my "Show in Groups" Windows XP folder, as I do now in almost all other applications which allow icon changes.

. 4. Please position the "Select Icon" window so it does not cover the TLB under construction.

. 5. Don't uncheck the "Save icon with toolbar" box every time it closes. Let the user's selection stick.

. 6. Allow accelerator key open/close toggling of collapsible menu section titles. For example (see SNAG-0001.gif), the "Utilities" section of the "Quick Shelf" menu button has its "U" underlined. However, Alt+U will not select the Separator line/title, nor will it toggle it open/closed. Given that Win+1 now opens the "Quick Shelf" menu, it would be faster to follow Win+1 with an Alt+U than to grab the mouse and select-click the tiny (on a 1600x1200 screen) "+" graphic. Or so it seems to me.

. 7. It would be a speed benefit to keyboard oriented menu users if the Spacebar were allowed to perform the same submenu launch function as Enter and Num-Enter now execute. I do not forsee any conflicts with using the Spacebar in this way, and it is much easier on my arthritic fingers because (most of the time) only my thumbs click the Spacebar.

There are some very good points there!

. 2. Allow context menus and submenus to remain open after a select-click (left-click), to allow clicks on other context menu items without having to re-open the menu after each select-click.

Except for this one...
Recently there was a nice thread about this on Opera beta newsgroup. It's completely unlogical and non-standard if a menu remains open after a mouse-click...

So I'd agree with all your points (though not with equal priority), except for the menu-stay-open-after-mouseclick-thingy...

Indeed, there are many good points there.

I'd like to see the accelerator keys be customisable in the contextmenu .ini files.

And I'd like menus that stay open...

For example, if I'm working on a set of graphics, it would be nice to keep the menu for a folder open so that I can work with the files in the folder, and would save me having to have an explorer window open.

With reference to Hourus' post, as well as Dracula's, maybe a feature inclusion approach everyone could agree on is "user defined options". As TLB evolves, I believe it would be to your marketing advantage to fully support Microsoft toolbar and menuing options, and give this support top billing when you advertise TLB features. Why? Because any employee who convinces his/her boss to buy a menuing system for Windows will want to use it productively right out of the box. Since (almost) everyone in the business and technical communities is compelled to use Microsoft Windows and Office (Word, PowerPoint, Excel, Outlook), they should be able to dive into TLB using their Microsoft toolbar and menuing skills, and remain productive in the eyes of their bosses while they explore TLB's value added options. Many of these options could become user defined wherever they produce TLB behavior which is different, but more productive for some folks, than Microsoft's.

I think you have already followed this approach well already, with only a few rough edges to tweak up in order to match Microsoft's default toolbar/menu behavior.

In summary, I would say: Support Microsoft behavior as your default, and advertise this widely. Over the course of time, let requested features become user defined for both mouse and keyboard.

Recently there was a nice thread about this on Opera beta newsgroup. It's completely unlogical and non-standard if a menu remains open after a mouse-click...

Thanks for the tip. Could you please post a pointer to this thread? I am not acquainted with Opera.

In the new year, may the TrueSoft team
"LIVE WELL AND PROSPER",
as the Vulcans say.

Thanks for the tip. Could you please post a pointer to this thread? I am not acquainted with Opera.

You can find that thread here: Delete private data dialog (btw, in the new beta version of Opera the issue discussed here has been resolved)