[haiku-development] Re: Keymaps application UI

On Mon, Aug 25, 2008 at 3:02 AM, Andreas Färber <andreas.faerber@xxxxxx> wrote:
> Am 24.08.2008 um 20:24 schrieb Jorge Mare:
>> On Sun, Aug 24, 2008 at 10:47 AM, Stephan Assmus <superstippi@xxxxxx>
>> wrote:
>>>> "Andreas Färber" <andreas.faerber@xxxxxx> wrote:
>>>> Am 24.08.2008 um 01:18 schrieb Stephan Assmus:
>>>>> I don't know what the purpose of the second listview is. Wouldn't it
>>>>> be much better to have a single list view that also lists user saved
>>>>> custom keymaps at the end of the list, behind a separator line
>>>>> perhaps? Then the list view would be more than twice the height.
>>>> Someone coming from a Windows/etc. background might misinterpret the
>>>> distinction between System and User as referring to a multi-user
>>>> context, where System determines the keyboard layout for the login
>>>> screen etc. and User the one used for the current user after login.
>>>> So it might make sense to keep two lists in some form, but for the
>>>> current use of only having "(Current)" and user-saved maps under User
>>>> I agree that we could merge them into the User list.
>>> I didn't mean to put the words "System" and "User" in there somewhere. I
>>> just wanted one list with the names of the system provided keymaps. There is
>>> no item "Current" or "User", but one of the keymaps is simply highlighted.
>>> If the user saved a custom keymap, then there would be a separator line at
>>> the bottom of the list and his personal keymap there with name that he gave
>>> to it. It probably has a default name of "Custom" or even "User" perhaps
>>> when the user is asked to save it or it is saved automatically when he
>>> changes the current keymap. Best would be if it would be "German - Modified"
>>> by default for example if the user first selected German and then changed
>>> some keys. Best not to even ask to save it but just do it.
>> I have been playing with the Haiku keymap applet a bit, and the more I
>> (try to) use it, the more I become inclined to think that it is
>> (unnecessarily?) confusing. This was probably compounded by the fact
>> that the drag-and-drop keymap customization does not seem to work (not
>> implemented yet? do we need a bug report?), but still, I think this
>> could be a lot simpler.
>> I think the problem with this applet is rooted in that it attempts to
>> use a single interface to perform two different functions: selecting a
>> keymap and creating custom (user-defined) keymaps.
>> Since Haiku strives to be simple, it may just be better to break this
>> two functions into separate interfaces, maybe by using tabs: one to
>> select the desired keymap and the other to create/manage custom
>> (user-defined) keymaps.
> Hm, I happen to like the graphical keyboard display in BeOS/Haiku and would
> hate banning that to an "invisible" place like a secondary tab... Or did I
> misunderstand you? The text field integrated into the keyboard image allows
> to directly test the chosen keymap - you don't have to open StyledEdit for
> testing then, since the Terminal is unsuited for the task (doesn't accept
> German Umlaut characters for instance). Disregarding the square characters
> for some functions keys, the keyboard display reacting to keypresses is
> really neat and unique!
> If you really want to separate the list from the keyboard, we might just as
> well move the keymap selection to a secondary tab of the Keyboard preflet
> (which doesn't do much currently) and rename the Keymap preflet to Keymaps
> and leave it as an editor, similar to now.

I agree that the graphical keyboard is neat and unique, and being able
to test keymaps w/o having to open another app is really useful.

But this is one visual element that serves two purposes (testing and
customizing) and does so without any cues that make it obvious to the
user when the it is performing one function or the other. This is
where I think it can become confusing.

If this applet were to be changed to have two tabs, perhaps the
existing visualization can be used in the default tab (where you
select and test keymaps), and a more "grid-like" keyboard graphic
could be used in the Custom tab, so as to visually imply the ability
to modify the mapping by DnD to the user.

Anyway, my suggestion to split keymap selection and keymap
customization may be a bit too radical, and certainly not something
that needs to be looked into before alpha 1, so I rest my case here.
In the meantime I would be happy if this applet worked as in R5. :)


Other related posts: