On 15/04/10 07:42, Chow Loong Jin wrote: > You are missing my point. I am not disputing the decision to use menus > as a model (like you said, that is for a different discussion). I am > saying that we should not keep ourselves locked to menus and menus > alone, rejecting all other features for the sole purpose of being a menu. Agreed. The question is not really one of principle, it's one of taste. > An indicator is not a menu, no matter how much you may attempt to model it after > a menu, and it serves a different purpose from that of the menus you are talking > about. > > For example, a normal menu has many actions, out of which only a small subset of > which are very frequently used. These would be abstracted out into toolbar icons > (one-click access), e.g. Back, Forward, Refresh, New Tab, etc, and/or given > keyboard accelerators, which can then be triggered as long as the window the > menu belongs to has focus. > > Now take a look at our application indicators. Each application indicator has > many actions, and most of them will have *one* frequently used one, i.e. > "Show/Hide Application". > > We cannot assign these actions keyboard shortcuts, because the "window" that > owns these menus is the panel, and it does not make sense to have to focus the > panel in order to trigger these keyboard shortcuts. An alternative would be to > use global keyboard shortcuts, but I do not foresee that ending well. > > We do not have a toolbar to abstract these actions out into. But wait! These > application indicators are *already* icons. They look and act more like toolbar > buttons that have menus (much like the Back/Forward history dropdown menu in > Firefox) than actual traditional text-based menus that you see at the top of > each window. So, why would it not make sense to provide one-click access to the > aforementioned frequently used action? > > The following point has probably been raised before and beaten to death before, > but the time taken to aim for one application indicator icon, click for menu to > open, then aim *again* for the menu item needed is significantly more than the > time it takes to aim for the application indicator icon and click *once*. I > would say that the former case would result in slightly less than twice the > time, and approximately twice the effort taken compared to the latter case. > I don't fault your logic. But I can disagree with your taste. I think it would be crass if we encouraged every app indicator to have a secret bunch of behaviours associated with specific clicks. I know that opening up a possibility like this results in a mess - an unusuable mishmash of secrets. We *will* have some hidden treasures, like the scrollwheel-on-volume. But they will be few and far between, and they will be on systemic indicators rather than app indicators, for the moment. Mark
Attachment:
signature.asc
Description: OpenPGP digital signature