gnustep-dev
[Top][All Lists]
Advanced

[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: Fri, 02 Apr 2004 06:15:25 +0900
User-agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1

Hi Nicola,

When I read this first, it really got me mad.  But I changed my mind when I
read the last few lines.  So I humbly ask you, please read this to the last
line.

Nicola Pero wrote:

In this context, the grammar of
keybindings files contains the symbol 'Shift'.  It's a programming symbol,
like 'for' or 'while' in C.

Who said so?  The users will never consider Shift as a programming symbol
until someone tells them so.


OpenStep itself defines programming symbols for key names. NSUpArrowFunctionKey, NSDownArrowFunctionKey, NSPageUpFunctionKey, etc.

And what about Shift ?  Well, the modifier flag is called NSShiftKeyMask.

Most programming environments do this, X11 for example does it too, it
uses symbols/pseudo-English names too to refer to keys -- take a look at
the X sources or headers and you'll find very long lists of key names.

Don't fool yourself.  They are actually either enums or cpp macros, namely
they are all integers that the underlying OS or window systems recognize.
They don't know what "Shift" is.

The names used by gnustep-gui for keybindings are simply the names used by
OpenStep, after removing the 'NS' prefix and the 'FunctionKey' or
'KeyMask' suffix.

So, using Shift (with this capitalization) is quite consistent with the
rest of the system, and definitely with OpenStep.

I know. But it's no use of hearing the explanation now. The issue is when you
explained it.  In my understanding, you didn't until just now.

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.


So you mean a sort of user-friendly programming language?  Did you write
any document about it?  If it were written in BNF, I could precisely
implement the parser from the outset.  The fact is, I couldn't find
any document about it.  What do you expect me at the given situation?


Yes, it looks like there is no documentation available. But the grammar is trivial.

Rule 1. The basic key description is a letter or something referring to a
button you can click alone on your keyboard.  In particular,
OpenStep-friendly names for the common keyboard buttons are allowed, such
as Home or PageUp or Function9 (full list available in the source).

Rule 2. You can obtain a more complex key description, describing a key
pressed in conjunction with a modifier, by prepending any key description
with any of the following strings:

Shift-  (means to set the NSShiftKeyMask)
Alternate- (means to set the NSAlternateKeyMask)
Control- (means to set the NSControlKeyMask)
Command- (means to set the NSCommandKeyMask)
NumericPad- (means to set the NSNumericPadKeyMask)

I believe you can build a formal grammar from rules 1. and 2.  For
example, Shift-Alternate-PageUp is a valid key description.

Given that key descriptions in this form immediately map to the underlying
OpenStep C names (for example Shift-Alternate-PageUp means
'NSPageUpFunctionFunctionKey' pressed with a modifier mask of
NSShiftKeyMask & NSAlternateKeyMask), I find it simple, consistent and
user-friendly.

If instead of 'Shift-' you modify the grammar to use '$' (which is what
this Apple syntax is about), well you've changed nothing except that now
you need to know that '$' means NSShiftKeyMask and that if you want to
write NSShiftKeyMask you really have to write '$'.  It's an additional
(pointless) mapping to do in your mind to understand what the code means.


Now, I think you have a point in that the existing code is a bit
confusing/sloppy because for compatibility with Emacs and such, shorter
versions of the Shift-, Alternate-, etc strings were allowed, so that

S- can be used instead of Shift-
Crtl- or C- can be used instead of Control-
Alt- or A- or Meta- or M- can be used instead of Alternate-
Numeric- or N- can be used instead of NumericPad-
If you want to remove those abbreviations for the sake of simplicity and
consistency, you have a point, yes maybe we should remove them.

If it means we can reach an agreement, I'm happy if you remove those, and
since you correctly said we need a comprehensive description fo the key
description format, some rearrangements of my comments above can be such a
description.

Use BNF, please. But my writing a parser is different story.

If user-friendness is your point, why is Shift used exclusively?
What's the reason for ruling SHIFT and shift out?


Because the OpenStep name is NSShiftKeyMask.

Did you change your position?   Where's user friendness gone?

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


Don't exaggerate the things.  The symbol ~$D is a literal string, not a binary
encoding at all. :-)  If one is really a programmer, she/he doesn't feel bad
when she/he stumbles across ~$D (if she/he sleeps well everyday :-).


A *good* programmer feels very bad when she/he stumbles across ~$D. :-)

Don't get me involved in the Gorm-vs-Renaissance case.  I never enjoy
this sort of discussion.

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

I was talking about maintainability and extensibility, not about performance.
But if you really want to talk about it, think about accumulation caused by
such sloppy attitude.  Actually, the current input system is much slower
than mine (perhaps two magnitudes of order), though my purpose doesn't lie
in tuning performance anyway.


I'm happy to hear that your system is much faster, which is excellent. :-)

Are you OK?  Do you believe the comparison was done on different machines?

But parsing the keybindings file is done only once at load time, so it
shouldn't affect input performance.

I was talking about the current input management system *as a whole*.

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


If there's really a defined syntax of the current key binding dict, why don't
you put the specification in the source?  Trival?  How can other programmers
make up anything out of nothing in a reliable way?


You are absolutely right in this and it's my fault if I've never
documented it.  Do you think some rearrangements of the rules at the top
of this email would be enough as a documentation ?

I can't believe you designed the current input system based on the description
above.  Looks like a product made up in minutes.

But '$' is finally bound to ... NSShiftKeyMask.  So you could just write
'Shift' in the first place.  Using '$' doesn't add any flexibility.

Then, when a given string is divided into tokens { 'S', 'h', 'i', 'f', 't', 'a' },
how do I parse it?  I'm afraid your specfication tells nothing about this.
I'm not confident in implementing a parser on the basis of such a
specification.  Can you reach an agreement with yourself?  I'm afraid the
specication doesn't have quality enough to get someone else to work with it.

You still miss my point.  A particular symbol itself does not matter; the
benefit of its use is to save us from intrinsic ambiguity any natural languages
have, thereby making code much simpler and more competitive.  You are
changing your specification every time I point out its drawback.  It's not
fair.

I said, it's a responsibility of an input server. In NSInputManager,
I don't like to implement anything which makes it bound to particular,
pre-defined key bindings. I'd like to write it in a neutral way. In fact, my implementation of NSInputManager itself doesn't know anything about particular key bindings. What's wrong with this? I do think this is a right thing to do.


I'm not sure I follow you here.  Do you mean that it is the NSInputServer
which is interpreting the key-bindings, not the NSInputManager ?

If you want to do something different from standard, you can do it with
a subclass of NSInputServer or its delegate.  It's just for that purpose.

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


Really?  I wish I could hear it first, indeed. :-)


Sorry about the wrong approach then, I apologize, I do indeed encourage
you to go on with your work. :-)

Surprise. I accept it without any reservation. If you find something offensive
in my words, I apologize to it, too.

Anyway, I strongly feel the syntax of the current key bindings should be fixed before we go further. (But don't create a merged version. It's a nightmare.)

I think the desciption of key bindings above is a good tutorial (With this regards, I owe very much to you. ;-) I'd implement a default GNUstep input server as such
if you could elaborate the key-bindings desctiption to establish a real
specification of it for GNUstep programmers.

I'll read the description again after my head gets cooler. Also, I respectfully ask you to understand I can't do everything at once. :-) (Thus I said, "something
is not supported", but not like this: "something will never be supported". )

Later,
- Kazu





reply via email to

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