Re: Problems with cedil

[Owen Taylor <otaylor redhat com>]

On Fri, 2003-10-03 at 14:00, Pablo Saratxaga wrote:
> Kaixo!
> 
> On Fri, Oct 03, 2003 at 12:07:25PM -0400, Owen Taylor wrote:
> 
> > These represent the languages that the user knows. Within this set,
> > it's likely that if you start using one of these languages in a 
> > window (or for tabbed-mdi, mdi tab) then you want to continue using
> > that language.
> 
> I don't think that is evident, the most used input method: switch of
> keyboard layouts, is global in all the OS I know; a per-windows or per-tab
> keyboard state is not something people would expect. And also, why not
> a per-windows state for capslock and similar things?

The gswitchit applet for GNOME implements per-toplevel groups, and
from what I here, Russian users consider it a really neat feature.

(And they'd really like to have per-tab group state, but that requires
GTK+ app and support)

I personally don't have a lot of experience with multiple-group
keyboards, so I can only go on what people tell me.

I think the answer about capslock is "nobody ever uses capslock, so
it doesn't matter".

> I know that the use of transliteration methods or CJK input servers is a
> bit different; but still, the most common case will be to switch globally.
> Havin per-window states means that the burden to keep track of the state
> is on the user; it is sometimes a pain to keep track of where the focus
> is when there are several windows opened, keeping track of the input
> method would be even worst.
>
> The local state of input method is clearly an exception
> 
> > Imagine chatting in two different xchat tabs. Or editing code in
> > one window and writing an email in another. 
> 
> Yes, but irc/im/mail/news is a small portion of the totality of available
> programs; imho those programs only should provide the ability to have
> local (per-tab) input states; or even better than per-window/per-tabe: 
> per-correspondant (that is, configurable in the preferences of the program,
> like xchat currently has the ability to configure on a per-channel basis
> the charset encodign to use, it could have an extra field to configure
> on a per-channel basis the input method (the default being to use the
> global one).
> Same for instant messaging (eg, gaim, on a per-buddy basis),
>
> news (on a per-newsgroup or per-hierarchy basis), and email.
> 
> But the usefulness in other programs is less evident.
> 
> I mean, if you know several languages using different scripts, it is perfectly
> possible that you get messages or emails in another script when you
> are working on something other, and you may want to reply withotu having
> to manually switch the input methods;
> But are there people that will do things like editing at the same time two
> (or more) text files into two (or more) different scripts?
> I mean: at the same time.

I think it's very plausible that I might be hacking code in one window
and replying to emails elsewhere. I do that all the time. Of course,
everything for me is in English. I guess I should defer to you as
more familiar with multilingual input usage :-)

> For the cases that are valid exeptions imho, what caracterize them is that
> they are somewhat interactive (you don't know in advance what you will
> read and reply to); this is particularly true for the instant messaging;
> but for tasks that the user is in full control, it would be a bit strange
> to to type and switch between scripts and tasks so frequently in a short
> period of time that manually switching the input methods would be a penalty.

I've been told that if, in Windows, you move the insertion cursor into
a piece of Russian/English text, the active group switches
automatically.  This is sort of a similar idea.

> > The only place where you need a global preference is for creation
> > of new windows.
> .. 
> >  - Use whatever input method you switched to last
> > 
> > In the interest of simplicity and avoiding settings, I think the second
> > is probably better, but either works.
> 
> I like that idea too (and I find it quite intuitive and user friendly too)
>  
> > One important thing here is having a global indication of what the
> > current IM / keyboard group is. If the user knows that that will always
> > be indicated on their panel (or wherever) then it's much easier to
> > switch as necessary then if they have to guess what is current.
> 
> given the number of possible input methods, I don't see how it could be
> easily indicated (or make the the icons for each method user-themable ?)

The observation is that a user is (almost) never going to want to switch
between Canna and Wnn, or between us and uk keyboards, so *among the
languages the user has configured*, a two letter langugage code works
well as an indicator. 

> And now, for something completly different (well, still a bit related).
>
> I would really love an "XIM" input method that would be configurable
> and accept multiple instances.
> 
> The things that could be configured would be, for example:
> - locale to use
> - xkb or real XIM
> - in case of real XIM:
>   - value for XMODIFIER
>   - pathname of xim program
> 
> then, it would be possible to switch between Japanese and Chinese input
> for example, using XIM input programs.
> 
> 
> That is what yudit (http://www.yudit.org/) actually does, and it works
> very well 

I tried to make GTK+ switch XIM methods on the fly when I first created
GtkIMContextXIM and it didn't work. The XFree86 Xlib at that point
simply couldn't handle it.

Maybe it works better if you are running with all UTF-8 locales; maybe
the xlib-i18n contributions from Sun have improved things.

I believe that Solaris handles switching input methods on the fly
through IIIMF, however. 

Regards,
						Owen