[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: The Ctrl-A controversy
From:       Dawit Alemayehu <adawit () earthlink ! net>
Date:       1999-12-18 0:42:36
[Download RAW message or body]


On Sat, 18 Dec 1999, Andreas Pour wrote:
> There is a huge difference between all the example I have heard (cultural
> differneces, how to drive a car, how to start a fire) and what we are
> talking about.  None of the above is easily tailored to an individual (well,
> some things in cars are, like seat position and mirror position, and those
> can be easily configured).

Right.

> But we are talking about a desktop.  Indeed, a desktop that proclaims itself
> to be "object-oriented" and hence to benefit from abstract class design and
> inheritance.  To simplify even further, there is already a class that does
> key bindings.

More like three ( KAccel, KStdAccel & KGloablAccel ). Just nitpicking :)

> Bearing in mind that things like shortcuts are functional and effect
> productivity, it seems to me that the style-guide should not say what keys
> are used but should say, "The programmer should use the KStdKeys class".
> Then that class will undertake to make key bindings based on what is best
> for the particular user (just like there is a keyboard class and the
> programmer does not have to worry about which *physical* key on a keyboard 
> in struck to get a desired effect, the KStdKeys class means the programmer
> does not need to worry about which *logical* key is struck to get a desired
> effect).

This is not the actually problem as the classes you mentioned above could
easily handle this.  The main problem is the QT widgets have hard coded
key-bindings.  Hence, in order to allow for configurability there are two
options :

1.) Inherit these widgets (at least the most used ones) and override the
eventFilter() methods to process the keys based on the configuration (current
solution for a couple of widgets which I am doing KLineEdit & KComboBox).

2.) Get the trolls to change the widgets so that they do not have hard-coded
key-bindings.  AFAIK they said this is planned, but it will probably not make
it into 2.1.

>  > The X Window System has long supported this approach with .Xdefaults files.
> I see no reason why this should be abandoned.  And in fact it would make KDE
> better than Mac/Windows/whatever, b/c each user could pick.  If someone
> wants to translate key bindings, they can; we don't have to dictate whether
> it is bad or good (whether MS or Mac was right).  Some distributor can make
> a set of translations, and if the user wants to use them, they can, if not,
> they use the defaults.

This is exactly what the keys section in the control panel is for.  The only
thing it is missing is some mechanism like the Theme module that allows you to
load these bindings easily.

> The only thing needed to make *everyone* happy is a nice "kcmkeycuts" module
> which like themes allows you to scroll through a list of "standard" bindings
> (like "Windows-Like", "Mac-Like", etc.) and an area that shows which
> keystrokes accomplish the desired effect (e.g., Ctrl-A for Select All).
> This would be similar to the Themes control module.  In fact, the module
> could have a set of menus there, and when you click on them it shows the
> bindings for the standard entries which are part of the class.  Then, a user
> could configure even these standard bindings to suit himself or herself and
> save these bindings (so e.g. they can be saved on a homepage and whenever
> he/she goes anywhere they can be easily accessed and used to configure a
> local machine elsewhere).

This is already there !! Control Panel->keys.  It just needs the enhancement to
allow for loading pre-configured bindings like the theme-module does.  Also
adding it to the style-guide so that developers can follow it and do not hard
code the key-bindings.  For example, kfm followed these changes in the
Control-Panel (try it out).

> Even this customization could be made easy, like GTK toolkit does for changing
> menu entries -- when you have highlighted a menu entry, clicking a key
> will make that the binding for that entry (and if  another entry had that
> binding that binding would be undone).

This has been discussed before and decided against for reasons I do not recall.
But IIRC that is why the keys configuration was provided in the control panel.

> This to me is the most elegant, flexible and user-friendly solution.

Well this is debatable.  I personally do not mind which way it is done
as long as you CAN do it.  Some people however will disagree with you
that being able to change key-bindings while highlighting the menu item
is the "most elegant, flexible and user-friendly solution".  Also you seem to
forget that some key-bindings do not exactly correspond to menu items.
A good example is the items found in Control Panel->Keys->Global Keys.  How
would the user configure these under this scheme ??  If you then say the
globals should be configured through the control panel, then you just introduced
inconsistencies which lead to many problems to the end-users as well as
programmers...

Regards,
Dawit A.

[prev in list] [next in list] [prev in thread] [next in thread]