Re: [RFC] Text Input Management System

[Nicola Pero]

> >> In GNUstep, we already have these classes; however,
> >> (1) NSInputManager doesn't accept a file format of key-bindings as 
> >> seen in
> >> http://developer.apple.com/documentation/Cocoa/Conceptual/BasicEventHandling
> >> /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.

'Shift' is as much as a semantic symbol as '$' is, but it's easier to
remember. :-)

Everyone has to lookup ~$D in the documentation to understand it.  
Instead, maybe not all but many people (particularly programmers who are
the ones who more likely will edit such keybindings files) understand
Alt-Shift-D without the need to look it up in the documentation.

So I think that it is more user-friendly.


> 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. ;-)

You should not localize this stuff.  In this context, the grammar of
keybindings files contains the symbol 'Shift'.  It's a programming symbol,
like 'for' or 'while' in C.  You don't localize them.  They are the same
in all languages.  Yes, they are also English words, in the same way as
the C keywords 'float' or 'return' are also English words.

End-users will only interact with this stuff through a Preferences
application, which will be localized, so they will never see no matter
what symbol is used.

But programmers are very interested in keybindings usually, and they can
edit those files directly.  They benefit from a pseudo-English
syntax/grammar to specify key combinations.  Programmers are used to write
programs and code and lookup tables in pseudo-English.  And to be really
honest, it does make a huge different to write software using almost
binary encoding as in ~$D or using human readable pseudo-English text as
in Alt-Shift-D (obviously I think the human readable pseudo-English makes
enormously better software).

Doing five comparisons is certainly not a problem.  The difference in
performance is unmeasurable.

If you prefer ~$D, why don't you support both syntaxes ?

I definitely prefer writing stuff like "Control-x" to whatever syntax you
have to write to get the same result on Apple.



> >> 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.

I don't know.  But even if DefaultKeyBindings.dict is not using it, at a
quick look it looks like the functionality is currently there.

I suppose it's not really important ... but it looks so easy to do that 
it's probably not a huge change to add it to your changes. :-)

===

Btw, it's really nice that you are looking into this - I didn't mean to
discourage or disappoint you.