[Top][All Lists]

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

Re: [RFC] Text Input Management System

From: Kazunobu Kuriyama
Subject: Re: [RFC] Text Input Management System
Date: Thu, 01 Apr 2004 10:35:09 +0900
User-agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1

Nicola Pero wrote:

In GNUstep, we already have these classes; however,
(1) NSInputManager doesn't accept a file format of key-bindings as seen in
/Tasks/TextDefaultsAndBindings.html ,

... Are you really worried about this ? ;-)

I think that their keybindings file format is unreadable - not that it
matters, as keybindings should really be edited via a Preferences
application anyway. Compatibility of the file format used to store the
keybindings is of little relevance. It might help a little bit if you
want to copy your keybindings file from GNUstep to Apple (or viceversa),
but it's orders of magnitude less important than API compatibility.

I assume you are proposing to extend the GNUstep key-bindings file format
to support the unreadable Apple keybindings expressions such as ~$D, *in
addition* to supporting the nice, clear and readable GNUstep keybindings
expressions such as Alt-Shift-D ... am I correct ? :-)

On behalf of non-English speaking people of the world, namely, most of
human-beings, I must say, "Alt-Shift-D is as *unreadable* (sic) as ~$D". :-)

Seriously, you should understand each key on a keyboard by its functionality,
not by its name.  If you think "Alt-Shift-D" is user-friendly, I'm afraid
it's wrong. Rather, defining some symbols is more suitable for that purpose,
because every person of the world can understand each key by its semantics,
not by its name.

Above all, the code of the current implementation strongly supports my
argument.  To interpret the key denoted "~" in the Apple's document above,
you need five comparisons, namely, @"Alternate", @"Alt", @"A", @"Meta", and
@"M".  How do you deal with localized strings?  As you already notice,
it's just a style OOP deprecates. (Said that, I must admit I'm often temped
to write such code. ;-)

For the format, take a look at StandardKeyBinding.dict. Nested dictionaries
are allowed to use. "One key binding for dispatching multiple methods" is
not supported.

Why not ? It was quite a nice feature, and easily implemented. You can
just use the code/implementation which is already there, can't you ?

I didn't say it's not nice nor deprecated.  It's a responsiblity of an
input server in the proposed input system.  Once you write an input server
for that particular functionality, you can write anything you want in
the server's key bindings dictionary.  You lose nothing. ;-)

By the way, why is that *nice* feature disabled in the current
DefaultKeyBindings.dict?  If it were not, I would implement that
functionality as default.

- Kazunobu Kuriyama

reply via email to

[Prev in Thread] Current Thread [Next in Thread]