[Uim] Replacing property handling codes with property.scm

Kazuki Ohta mover at hct.zaq.ne.jp
Wed Oct 20 20:08:18 EEST 2004


Hi, Hiroyuki.

I have a comment on one point.
> > > 2. Property isn't always used to indicate state.
>
> (snip)
>
> > I think that we should simply replace the property handlings
> > with current property.scm, for now.
>
> Sorry, that's confusing. I wrote previous mail without elaboration
> (because I hurried). Please forget content of previous mail.
>
> What I want to say was, there's something which is property but not
> state. Here I mean property as 'an attribute, quality, or
> characteristic'. Current property.scm assumes existence of default value
> for each property. This means property.scm assumes also each property
> will take a value defined by state definitions. But there is a case
> which is not applicable.
>
> For example, uim-anthy will have a dicitionary manager, it can be deemed
> as property, but it's not state of uim-anthy. State such as input mode
> will transit, but the infomation 'uim-anthy have a dicitionary manager'
> will never transit.
>
> In old implementation, label and lists are distincted. So we could add
> dictionary manager in this way.
>
> branch dictionary
>    leaf  add a word to dictionary
>    leaf  edit user dictionary
>
> But property.scm assumes that branch value is some one of leaf value.
>
> I cannot describe well... Could you understand this writing? If not,
> I'll write another example.
I think this should be dealt with in toolbar level implementation. Such GUI is 
written in only Gtk/Qt level but not by parsing helper message. Please see 
the code which I committed at r1515.
qtkde-helper/src/common/uimstateindicator.[h/cpp] deals with helper message.
qtkde-helper/src/common/quimhelpertoolbar.[h/cpp] add stateindicator to itself 
and add im-switcher exec buttons.

The merit of not creating GUI by not parsing is:
  - avoid excessive updating of menu
  - no need to write complicated codes in Scheme
  - abolish complicated parsing, message becomes shorter.

However, the demerit is also available. The creator of toolbar (helper apps) 
can freely modify its user interface, so we're afraid of not prividing 
unified (have same user interface) apps. But this can be avoided to create 
documents which define toolbar's interface.

How do you think about this?

regards.

---------------------------------
Move the worl:D!
Kazuki Ohta : mover at hct.zaq.ne.jp



More information about the uim mailing list