KeyScript replacement
KeyScript replacement
- Subject: KeyScript replacement
- From: Aki Inoue <email@hidden>
- Date: Tue, 21 Mar 2006 09:04:10 -0800
Hi,
I'm forwarding a message from one of our text input engineers
regarding our plan for replacing Script Manager in a future release.
This message is being cross-posted to carbon-dev and carbon-it.
Aki
Begin forwarded message:
Dear developers,
We* would like your suggestions on some plans for Leopard related to
text input management and Script Manager functionality (*Apple
engineers working on text input management, Text Services Manager,
and the remaining vestiges of the Script Manager).
One of many initiatives for Leopard is to provide modern replacements
for functionality that depends on Script Manager types such as
ScriptCode, RegionCode, etc. ScriptCode is ambiguous in that it has
been used sometimes to indicate script (e.g. Cyrillic vs Latin/
Roman), sometimes to indicate a particular repertoire and encoding
(e.g. MacRoman vs MacCentralEuropean), and sometimes even used
(indirectly) to indicate or derive language (via the default or
current language associated with every ScriptCode). Similarly, the
RegionCode has been used sometimes to indicate a particular region or
locale (e.g. verUS), sometimes to indicate a language, and sometimes
to indicate a particular orthography (e.g. verGermanReformed).
We would like to replace functionality dependent on these ambiguous
types with functionality that depends on types which are more
precisely specified and which also offer more flexibility for dealing
with special cases. For encoding we have TextEncoding/
CFStringEncoding; for character repertoire we have CFCharacterSet;
for language we have RFC-3066bis-type strings as used in CFLocale;
and for script we could used script tags as per ISO 15924 (see
<http://www.unicode.org/iso15924/>).
So now to the specific question at hand. The Script Manager function
KeyScript provides a way to programmatically select the "current
default" input source for a particular ScriptCode. For example, when
a user clicks in a text field that is supposed to have Japanese
input, an application can automatically switch the current input
source to be whatever the user last used for Japanese.
In Leopard, we would like to provide some kind of similar
functionality for developers, but oriented toward more modern types
and a Unicode world. If you are a current KeyScript client (or plan
to use similar functionality), we would like to hear from you about
your preference for a modern way to specify this functionality. For
example:
- Language: You specify a written language, and the system selects
the most-recently-used input source that can input that language.
(see note [1])
- Repertoire: You specify a character repertoire via CFCharacterSet,
and the system selects the most-recently-used input source that can
input that repertoire.
- Script: You specify a list of ISO 15924 script codes, and the
system selects the most-recently-used input source that can input
those scripts. (see note [2]).
- Something else?
We can't provide all of these. Please let us know which are most
important or useful for you.
General note: KeyScript will still be available for 32-bit
applications, but it will be deprecated; its presence in source will
produce a warning when compiling on Leopard and later.
Specific notes for options above:
- [1] Keep in mind that many keyboard layouts, for example, can input
languages other than the one for which they are intended. So if the
user has been using the U.S. layout and a program requests a keyboard
that can input French, that would probably be the U.S. layout (since
it can input French too). Note that an RFC-3066bis language tag can
indicate written language and thus script if necessary, so it could
distinguish between input sources for, say, sr-Cyrl (Serbian in
Cyrillic) and sr-Latn (Serbian in Latin script).
- [2] This might not be very precise in the case of some keyboards.
For example, the French and Polish keyboards can both input text in
the 'Latn' script, but they input different subsets/repertoires of
that script.
Thanks,
Peter Edberg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden