[Uim] Replacing property handling codes with property.scm

[YamaKen]

At Wed, 20 Oct 2004 07:20:11 +0900,
tkng at xem.jp wrote:
> 
> On Tue, 19 Oct 2004 18:37:56 +0900
> YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > > 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.

> 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

It surprises me. I can't imagine such purpose from the word
'property'. I feel that it's inconsistent with your definition
of the property 'an attribute, quality, or characteristic' of
uim-anthy.

In rough (and slightly inaccurate) word, 'property' means
'instance variable'. So I can understand your intention 'a
property must be able to exist without default value'. But the
example does not represent variable/value model. It's a
categorized operations. So we should rename the feature
'property' to another one to avoid serious misunderstanding
about the intended model, if we will really go to implement such
thing.

In addition, a specification change about prop_list_update
performed in 2004-09-05 is also inconsistent with this
example. As described in doc/HELPER-PROTOCOL, current
prop_list_update has the 'flag' field that implies the state
model. How do you think about it?

See also 'Flag field has been added to prop_list_update message'
entry of doc/COMPATIBILITY.

> 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've understood this example although it's hard to accept as
'property'. Tell me any other undocumented/uncoded purposes if
exists. Regard the undocumented purposes are hard to imagine for
me.

And please read whole doc/HELPER-PROTOCOL. Kazuki and me had
described our understanding about helper-protocol and properties
into the document a while ago, and I've written the property.scm
based on this document. If it still differs/insufficient from
your intention, you must notify us it immediately.

Please please complement doc/HELPER-PROTOCOL by yourself. I
can't imagine your intentions such as correct branch/leaf model.

> > > 3. System tray seems to intend to indicate one icon

> > Can a systray hold plural uim-toolbar-gtk-systray
> > simultaneously? If it is possible, we can display one branch per
> > uim-toolbar-gtk-systray and resolve the problem, as temporary
> > solution.
> 
> Though I don't tested yet, it would be able to hold plural
> uim-toolbar-gtk-systray simultaneously. But, as you said, it's temporary
> solution because users won't want to show so many icons in system tray.

Although it's a temporary solution, better solution is not
required to introduce property.scm. Since property.scm
encapsulates helper-protocol specific handlings, we can modify
the protocol messages later to resolve the problem. Can't we?

-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp