[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Reworking the Keyboard spoke



While addressing keyboard spoke, etc. There are a few points I would like to address.

I would like to bring up a reference to the first Anaconda beta version.  On the opening screen where all the languages were listed, there was no default keyboard established. The default was later selected after choosing the default language. Ergo, we chose the language, then on a following spoke we chose the keyboard layout to be used for installation. An implicit default was English.

Regarding keyboard layouts.

Many newer keyboards(1995) are of a PC105 model, with an extra physical key between the Z and the left Shift Key (Qwerty layout) At different times I use two keyboards, cafr and Latam. Old keyboards were PC101.

CAFR . EURO symbol should default to the E key. There is currently no Euro symbol on this layout. This is a good location, as many boards have the E keytop embossed with that symbol and it is already appearing along side the E key  on laptops sold in Quebec Canada. The key between Z and left shift contains regular case «» and  on shift, an ° 

The missing key bug has been in three successive bugzilla error reports (F18,19,20), repeated with each release since Fedora 18.

Latam  (Latin America) and Canadian French (ca(fr). These keyboards have the extra keytop between the Z key and the left shift key. This is not shown on the keyboard layout after Fedora 17. (It was OK with F17, as it was shown therein, but not with later Fedora versions.) The key between the Z and left shift for Latam is the less than and greater than < > .  Again, the images showing the layouts do not show this missing key. Its important because some people will want to visualize the keytop layout before exiting from this spoke. The layout should reflect the physical hardware for the language selected.

 

 
Regards

 Leslie
Mr. Leslie Satenstein
An experienced Information Technology specialist.
Yesterday was a good day, today is a better day,
and tomorrow will be even better.
lsatenstein yahoo com
SENT FROM MY OPEN SOURCE LINUX SYSTEM.



From: Adam Williamson <awilliam redhat com>
To: Discussion of Development and Customization of the Red Hat Linux Installer <anaconda-devel-list redhat com>
Sent: Thursday, January 23, 2014 1:25 PM
Subject: Re: Reworking the Keyboard spoke

On Thu, 2014-01-23 at 15:07 +0100, Vratislav Podzimek wrote:
> Hello everybody,
> in the lifetime of Fedora 18, 19 and 20 there have been some serious
> issues identified in our Keyboard spoke. The main issue is that with a
> one-level layout selection, it is not possible to list keyboard layouts
> for multiple languages (thus e.g. Belgian layout was not listed as
> Belgian, but as Dutch, because those two languages both use the layout).
> The other issue is that it's not obvious which of the layouts will be
> used by default (as the VConsole keymap) and last but not least it is
> not possible to preview the layout before adding it.
>
> For those reason, I've started thinking and working on the new version
> of the Keyboard spoke. The following link shows what I have right now:
> http://vpodzime.fedorapeople.org/reworked_keyboard_spoke.png
>
> Issues I'm aware of (and didn't make implementing them today):
> * there should be descriptive labels visually splitting the screen into
> two parts (something like "Available layouts:" and "Keyboard
> configuration:")
> * the default layout should be bold
> * layout switching label should be more visible (italics?)
> * the + and - buttons are probably not so catching as they should be
>  - Should the testing area and treeview with added layouts be swapped
>    and the +/- buttons replaced with the up/down arrows?
>  - or should they be marked as important and thus have the blue colour?
>
> Suggestions and comments welcome!

The main problem I see with this is it's unclear what 'default' means.

Our 'tricky' users here are, as always, those non-ASCII ones - to recap
for those who don't love keyboard trivia, languages like Russian where
the 'native' layout cannot input ASCII characters (like Latin letters),
so it *must* be switched with another layout (usually US) to input those
characters.

In Xkb, you actually have two separate layouts defined (each of which
can have its own third- and fourth- levels, if you like) and a key combo
switches between them. At the console (kernel/'kbd') you can only load
one layout at a time, and these layouts use third- and fourth- level
switching to implement the alternate layout.

So, our standard example user - a Russian - will usually expect to have
'en' and 'ru' layouts available in Xkb with a switcher key, and the
layout 'ru' used at the console.

We have also taken a straw poll recently and found, overwhelmingly, that
those users of such layouts who responded expect the default layout at
boot time to be the ASCII layout (us), not that native layout. That is,
when they boot the system, they expect the 'a' key to type 'a', not
whatever native character is mapped to the 'a' key in their native
layout.

Now, imagine I'm our intrepid Russian, and I'm looking at the bottom
half of that screen, and it says:

Layout                        Default

English (US)                    X
Russian

What exactly do I expect? Does 'default' indicate that it will be
selected at boot time - in which case I want it to be set to English
(US)? Or does 'default' also/instead indicate that the layout in
question will be loaded at the console - in which case I can't actually
achieve the 'correct' configuration (en and ru loaded in X with en as
the default, ru loaded at the console) at all?

And this isn't even considering the case where someone decides to pick
*three* layouts :/

In conclusion: kmscon can't arrive fricking fast enough.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list redhat com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]