On Thursday 15,April,2010 01:24 PM, Cody Russell wrote: > On Thu, 2010-04-15 at 11:09 +0800, Chow Loong Jin wrote: >> Frankly speaking, I'm quite tired of this reasoning. "Menus don't do >> this", >> "Menus don't do that". Did you also realize that menus don't have >> icons as >> buttons? They have *text* buttons. > > It's never been common for menus to be used from icons, true, but we're > not the first. Chrome does it. I've seen it in some other random > places as well but I can't think of specific examples right now. > Indicators can be designed based on either text or icons, just like > menus can be.
Chrome and even Internet Explorer do it, yes. But do you notice something? Those menus are actually menus that come from toolbar buttons that have tooltips to describe their icons, but that's another whole different issue that deserves a thread of its own. > Regardless, using menus as a model was the original decision, and > implementation-wise that's what we're doing. It's a little late to try > to change course. If you think that was a bad decision, that's a > different conversation. But here we're talking about adding new > features to specific instances of menus.. if middle-click corresponds to > a particular action in an indicator menu, shouldn't the same thing be > possible in all menus? 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. 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. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Developer
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
