[Uim] How to turn on the input method as soon as the uc is created?

[TOKUNAGA Hiroyuki]

Sorry for no response, I forgot to reply...

On Mon, 12 Jul 2004 01:04:03 +1000
Paul.Hampson at anu.edu.au (Paul Hampson) wrote:

> > > > outside." His main opinion is about treatment of private data,
> > > > not how to export private data to outside.
> 
> > > > Personally, I'm thinking that maybe we should treat this state
> > > > as public. (Now I cannot draw a conclusion.)
> 
> > > Do all UIM input methods have an on/off state? I noticed that in
> > > SCIM, _English_ had an on-off state, with no appreciable change.
> 
> > No, several IMs of uim don't have on-off state. E.G. uim-anthy has
> > mode state and preedit state, but has no on-off state.
> 
> Maybe I got the terminology wrong? I think I meant the various
> conversion modes, rather than states. >_<

conversion state is contrasted with input state. (In uim-anthy, we use a
word 'compose state' instead of conversion state.) So I think we should
use conversion state rather than conversion mode. But to tell the truth,
I don't distinct them so strictly B-)

What should be treated as 'mode' and what should not is a difficult
problem for some input methods. For example, uim-anthy has 5 modes
'latin', 'wide-latin', 'hiragana' 'katakana' 'hankaku-katakana', but I
think kana-input mode or romaji-input mode is also should be treated as
'mode'. so strictly speaking, uim-anthy has two categories of mode.

I think the word 'mode' is easy to confuse, we should use other general
words such as state or property.

> _Perhaps_ a standard 'direct input'/last non-'direct' mode setting
> makes sense, like the NJStar word processor has? I assume most input
> methods have a mode where they just pass their keyboard data straight
> through, except fot the control keys.

Storing last non-direct mode doesn't seem good solution for me. I think
"All input methods must have a property on-off mode!" is better
solution. (But I think there is a more better solution somewhere. That's
a difficult problem...)

> > > I must say what I'm missing from the API (I haven't read the new
> > > API changes yet...) is a way of querying the current mode... The
> > > GTK helper has a '?' until you change modes, and for today's new
> 
> > That's a bug. Current mode should be shown immediately if you exec
> > helper-toolbar.
> 
> I'm using UIM 0.39, and as far as I can tell from reading
> helper/helper-toolbar-common-gtk.c, line 385 calls
> uim_helper_client_get_prop_list, and in the response to that, I don't
> see anything that indicates the _current_ mode. My brief playing with
> it indicates we only get notified of the current mode on mode-change
> events. On focus change and such, we get both prop_list_update _and_
> prop_label_update messages.
> 
> I haven't updated to 0.40 yet, waiting on the Debian package.
> ('cause I'm lazy. :-)

If you still have the problem with 0.4.2, please tell me.

-- 
TOKUNAGA Hiroyuki
http://kodou.net/