Ah. Well, you're making me work for things, thats for sure. Ha.
On Mon, May 17, 2010 at 9:37 PM, Luke Morton <luke.mor...@internode.on.net>wrote: > On Mon, 2010-05-17 at 20:38 -0700, Tyler Brainerd wrote: > > Actually, I added a (extremely rough) mock up of what gcalc might look > > like. Basically, the most commonly used options ought to be > > (categorically) available the easiest. > > I agree, although determining what's most commonly used is easier said > than done--it depends heavily on the user's habits and their particular > needs. > Agreed. Thats why I started with the calculator here, and with the already partially simplified Nautilus-Elementary. > > > In a tool like a calculator that doesn't have a lot going on as far as > > options its pretty easy to put these on a row of mode or view buttons. > > everything else can be found in the 'gearbox' options menu. Roughly > > like so:Calculator_027.jpg > > How would I access that with my keyboard? > > > This translates very well in simple apps, and with more work, could > > work well for more complex apps as well. > > With the keyboard shortcuts, particularly the insert command, > > ironically enough I'm using chromium, which does not allow for that > > command. > > The point of accessing the Insert menu (in Evolution) was to illustrate > the discoverability of a feature without having to know its accelerator > key ahead of time. > > > Presumably we could still allow similar behavior for common key > > presses of that sort, > > I would expect items in the toolbar to have accelerators--especially in > the absence of a menu. But how would I know what they were? And even if > they were standardised (say the cog icon is in your example is > accessible via Alt+S), how would I know what they were? > Pressing alt brings up hovering indicators perhaps? I don't disagree that these things ought to be discoverable, but honestly keyboard accessibility is nowhere near my strong suit, as I rarely use only the keyboard so I really don't know how to make it work and what doesn't. > > > and honestly some of it will be taken care of by a clean shearing of > > commands that are used for actual action (i.e., in a file browser > > relate to actual browsing instead of slightly less needed interface > > editing like "reset view to defaults" or history clearing) and menu > > items which do not directly relate to the task at hand. > > You lost me here. Are you making a case for well thought-out menus? If > so then yes, I agree menus should be well thought-out. > Um, yes. Well thought. :D. In the sense that chrome has "what I can do to this page" and "what I can do to the whole browser" as its two menus, then we would have "whats pertinent to the actions I am currently doing" and "what customizations to the nature of the program are available" > > > Again, Chrome is really a great example of giving context menus which > > are very dependent on the area clicked, and two very sparse clean > > menus, with all non-essential interface controls tucked away. > > Accessible in 3 or less clicks, but away. In addition, this would > > hopefully lower the levels of total overlap going on. > > None of the issues I raised pertain to clicking (using a pointing > device). But you are right about the Chromium menus being well > organised. And the use of context menus is good too. > Fair enough. :P > > However, Chromium also highlights one of the issues I menioned: how do > you open one of those menus without a mouse? I'll save you some > frustration for the "Customise and Control Chromium" menu: it's Alt+F. I > know that from trial and error--guessing key combinations until a menu > popped up. I'm yet to figure out how to duplicate a tab. You bring up good points, further illustrating to me that my idea as a whole is likely suitable as a modification, not as an attempt to alter vanilla ubuntu. > > On Mon, May 17, 2010 at 8:15 PM, Luke Morton > > <luke.mor...@internode.on.net> wrote: > > > > On Mon, 2010-05-17 at 18:47 -0700, Tyler Brainerd wrote: > > > I know, I know, we just had an announcement about changing > > menu's over > > > to global menu's for the UNE. But seriously, how necessary > > is 4 menus > > > in the calculator application "gcalctool"? The only menu > > options that > > > have anything to do with actual calculator options are under > > the view > > > menu. The rest is silly and redundant. > > > > > > > > > I just wrote a fairly long blog post on my blog here, along > > with > > > mockups and what not: > > > > > > http://tjamesubuntu.blogspot.com/2010/05/re-thinking-desktop.html > > > > > > > > > about how silly most apps menu's are. I'm hoping that we can > > maybe > > > pool some resources on looking at what is and what isn't > > necessary in > > > default applications in Ubuntu, although I'm not under any > > impression > > > that this will be something to be put directly in default > > Ubuntu. > > > However, I do think it is the sort of mod that can gain > > traction > > > similar to Nautilus-Elementary if we can get applications > > repackaged > > > with cleaned up and optimized menus. > > > > > > "Cleaned up and optimised"; sounds like a good idea. How would > > you do > > that for the gcalctool menus? (They seem pretty good to me.) > > > > General comments: > > (Pertaining to the removal of menus and replacement with > > toolbar menus > > as mentioned in your blog post.) > > > > 1. Menus provide access to functions that might be otherwise > > obscured, > > infrequently used or hard to access--especially for people who > > cannot > > use pointing devices. > > > > For example, I can tell that if I want to insert something > > into this > > email I can press Alt+I to get the insert menu, even though > > I've never > > used it before. If that menu were represented by an icon in a > > toolbar, > > how would I get to it without having to tab through the entire > > interface? > > > > 2. Menus provide a convenient reference list of keyboard > > accelerators. > > If that menu were represented by an icon in a toolbar, how > > would I get > > to it without having to tab through the entire interface? > > > > Take gcalctool for example. If it didn't have a menu, and you > > couldn't > > use your mouse, how would you switch to a different mode? Quit > > the > > application? Input an ASCII character? > > > > 3. A menu by itself takes up less space than a toolbar by > > itself > > > > Removing the menu in gcalctool in the same way that > > Nautilus-Elementary > > removes the menu would mean that we'd have to add a toolbar > > for the > > functions that have no-where else to go. (I don't think this > > is > > particularly important though.) > > None of these are absolute barriers to your idea, but they are > > things > > that need to be considered/resolved. > > > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~ayatana > > Post to : ayatana@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~ayatana > > More help : https://help.launchpad.net/ListHelp > > > > > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~ayatana > Post to : ayatana@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ayatana > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
