Saturday, June 16, 2007

Customize Perspective is annoyingly inflexible...

I just read Kims post about removing removing the default visibility of the menu and toolbar Working Set items. It triggered once again one thing that annoys me from time to time, the inflexibility of the Customize Perspective dialog:

You can either enable both, Menubar and Toolbar items or nothing. That is very annoying, because it breaks the principle that the toolbar items are optional. Unless the provider of the actionSet defines two action sets, one for the toolbar and one for the menubar, you have the choice between all or nothing.... But providing two action sets would duplicate the number of item on the command tab, which is already overloaded.

I think it is not the responsibility of the plugin writer to decide which items the user wants to see in the toolbar! (See bug 182714)


  1. I can't agree more.

    I wish Eclipse had the toolbar/menu customizability of OOo for instance, where the toolbar set and the menu set have actually checkboxes in front of them to allow/disallow them individually. And where you can reorder them and move them into user-created action sets.

  2. Me Too. Early versions of ClearCase highlighted the problem, exposing 15 icons for my viewing pleasure. This invariably pushed the toolbar to 2 rows. Oddly, the workbench used to have compressable Coolbars which aleviated this issue to some extent.

  3. My toolbar is full of buttons I've never clicked, although I use the menu items very often - it's a matter of personal preference, I think. I for myself just don't use the toolbar, navigating through the menus and using key shortcuts instead without touching my mouse. The toolbar just occupies the workbench space and I can't get rid of it - a mess indeed!

  4. Yup, we the UI team feel the problem. I should also at this time fess up to being the one that pushed for removal of the working set tools.

    To follow on with your comment, "it breaks the principle that the toolbar items are optional", toolbars should represent frequently used actions. The action set approach was based on functional usage (features you either use or don't), which is a different problem. Because frequency is based on both our expectation of your usage and your actual patterns, finer grain control over visibility is needed. Furthermore, we'd like to reduce the number of toolbar items the SDK takes up because with Europa and other products many more will be contributed. Unfortunately supporting this granularity of enablement isn't a trivial change.