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

Hi Nicola,

I'm afraid this discussion gets missing the point. Nonetheless, let me go on, for I think it might somehow help others get some ideas to evaluate the proposed
text input system. ;-)

Nicola Pero wrote:

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

My argument on English was a sort of joke, you know. :-)

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.

Look at StandardKeyBinding.dict.  You don't need to refer to any document
all the way.  Although I admit it somewhat cryptic, but I don't think
it's not so unreadable as you claimed.

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.
Why not?  I thought user-friendness is your way.

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.

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?
If user-friendness is your point, why is Shift used exclusively?
What's the reason for ruling SHIFT and shift out?

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.

Then, in this particular case, we don't need Shift-Alt-D, right?

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

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.

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?  Use source?   You said
the five comparisons don't matter.  Yes it doesn't matter if our interest is
confined to that piece of code.  But think again about accumulation
of such pieces of code.  It does matter when someone else tries to make out
something from the code. (But who really takes care of someone coming after
him while he's writing some code? Almost none. I myself is not an exception.
So it's understandable, but not a good excuse, though. ;-)

My intention here is not to enlighten you.  Never.  I'm writing this way,
expecting cross-checking by each other can works effectively in this list.
So I'd be more than happy if you could have a look at my code a little bit
and give some comment on it.

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

I don't like to write any code like @"Shift" in the implementation
of NSInputManager because I do believe making it free from any key bindings is a right thing to do in order to guarantee the flexibility the Apple's document

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

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.


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

- Kazunobu Kuriyama

reply via email to

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