Re: Standardization of Function Keys

["Jasper St. Pierre" <jstpierre mecheye net>]

On Thu, Jul 12, 2012 at 8:49 AM, Trans <transfire gmail com> wrote:
> Hi--
>
> I am new to the list and am a recent convert to Gnome 3. Out of all
> the latest DE's I've used (which is just about all of them) I think it
> is clearly the stand-out. Thanks for all the hard work!
>
> I have joined the mailing list b/c I would like to make a (serious) suggestion.
>
> A long time ago I used an early DOS-based application, I believe it
> was a spreadsheet, but I do not recall the exact program at this
> point. However I do recollect the interface which I thought was
> especially intuitive. Running along the bottom of the screen was a
> menu, and each menu item could be selected via a function key. F1 for
> the first menu item, F2 for the next, and so on. Pressing a function
> key might bring up a sub-menu, and the same correspondence applied to
> the sub-menu.
>
> I have always wanted to see a window manager that provided the same
> functionality. When pressing F1 the first menu would drop down --in
> modern applications this is typically the `File` menu. Pressing F1
> again would invoke the first sub-menu item, following the example, in
> many modern applications this would be `New`. To further improve upon
> this idea, Shift+Function Key would select menus in reverse order. So,
> function keys F1->F12 would apply from front-to-back/top-to-bottom,
> and Shift-F12->Shift-F1 would apply from back-to-front/bottom-to-top.
> The API for menus will need to allow for a way to carve out gaps for
> things like "most recent files", e.g. like GEdit's File menu provides.
> (These you might notice are already mapped to number keys.) These kind
> of dynamic menu items would simply be skipped in the consecutive
> mapping of function keys.

So now the rules are "F1-F12 map to the first twelve unchanging items
in the menu"? How am I supposed to know what those are, other than
blind guessing?

> So, why do I think this would be advantageous?
>
> Firstly, function keys are almost never utilized for application
> functions any more. Except for a couple of esoteric shortcuts that
> mostly came from the Windows world, like Alt-F4, or special laptop
> controls, Fn-{some icon}, they barely get touched. For instance, in my
> case, and I am a "computer expert", expect for F1, and F11 in certain
> apps, I have no idea what any function key does for any application I
> use. No one I know seems to know either --they don't even know about
> F1 and F11. The reason for this is probably pretty simple: There is no
> intuitive basis for their usage. The functions assigned to them are
> mostly haphazard and per-application, if at all. The only reliable
> exception being F1 which is usually mapped to `Help`. Yet 999/1000
> times I never even think about F1 if I need help. Like most people I
> suspect, I open up my browser and use a search engine. (I realize
> there will be exceptions. I am sure someone out there has all the
> function keys memorized and uses them all the time. But they must know
> how unique they are.) So the first clear advantage would be to remedy
> the current uselessness of function keys.

I use F5 in a web browser for refresh. I don't think I'm alone in this.

> The other big advantage is that is provides some useful constraints to
> designers. If for instance a menu has over 12 items, then it's an
> indication to start thinking about sub-menus. If a menu has over 24
> items then it's a big red flag that the menu is too big. Also, because
> the function keys select items in numerical order, it encourages
> designers to put effort into getting their menus "right" so they do
> not change often and users do not have to relearn mappings.
>
> The only disadvantage is that obviously this will come into conflict
> with applications currently defining mappings, e.g. F1 and F11. I
> would simply encourage developers to change those to Ctrl+F1 and
> Ctrl+F11 instead. I do not know if it's possible to automatically
> remap those, but that would be the best option if so. This issue
> should in no way be considered a show-stopper for the proposal. We
> will never progress, if we are constantly nailed down to decades old
> dysfunctional designs.

We're trying to remove large, complex menus altogether and switch to
simple, unnested menus in the Application Bar for application-global
things, and add more intuitive operations within the application
itself. Accepting your proposal would provide acceptance for complex
menu structures.

There's also the technical issues. This would only work for GTK+
applications which use a GMenuModel, unless we go playing large hacks
like Ubuntu/Unity does to gain Qt support.

> I hope my proposal is received positively. I think it would bring a
> small but very polished touch to what it in my opinion, the most
> excellent desktop experience available.
>
> Thanks,
>         trans
> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list gnome org
> https://mail.gnome.org/mailman/listinfo/gnome-shell-list



-- 
  Jasper