[Uim] TODO list until 0.4.6

[TOKUNAGA Hiroyuki]

On Wed, 12 Jan 2005 19:06:38 +0900
Etsushi Kato <ekato at ees.hokudai.ac.jp> wrote:

> On 2005/01/12, at 18:44, TOKUNAGA Hiroyuki wrote:
> 
> > On Tue, 11 Jan 2005 19:40:33 +0900
> > Etsushi Kato <ekato at ees.hokudai.ac.jp> wrote:
> >
> >> On gtk-immodule,
> >>
> >> What do you think about reset behavior about candidate window.
> >> Current implementation doesn't close (hide) the window on reset. 
> >It > seems annoying to me.
> >
> > I think there's no problem on immodule. When reset function in
> > immodule was called, immodule should call uim_reset_context only.
> > Closing candidate window when reset function was called is each
> > input method's business.
> 
> I see.  I'll add candidate closing feature upon reset in skk.

Thanks!

> But is there any principle (or documentation) of uim about which 
> functionality should be implemented in input method side or bridge 
> side?
> I'm confused about these separation sometimes.

If you confused, you should implement to input method side. Business of
bridge side is 'connecter between application and input method'. If
bridges implements their orignal features, user will be confused.

>From the point of this view, slave imcontext in GTK+ immodule and
compose key sequense support in uim-xim is bad idea. Why we allow this
is because:

 (1) There is a huge merit for users
 (2) User won't be confused in this case
 (3) We can't implement this feature in libuim for now because of the
     limitation of current implementation.

But this should be an exception and later this feature should be moved
to input method side.


Regards,

-- 
TOKUNAGA Hiroyuki
tkng at xem.jp
http://kodou.net/