[Uim] Replacing property handling codes with property.scm

[TOKUNAGA Hiroyuki]

On Wed, 20 Oct 2004 21:57:41 +0900
YamaKen <yamaken at bp.iij4u.or.jp> wrote:

> > 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.

To put it simply, problem could be break down as follows:

 1. Should we accept constant variable as property?
 2. Usage of property such as

> > branch dictionary
> >    leaf  add a word to dictionary
> >    leaf  edit user dictionary
    is acceptable?

Could you agree this break down? What is your opinion about these
questions?

Short my answer is:

1. Yes
2. Maybe yes

1 is yes because constant variable characterize the difference between
one IM's instance and other IM's instance.

2 is difficult question, but, basically my answer is yes.

>From the point of view of toolbar, nothing changed from before. From the
point of view of protocol design, there's no problem if we assume "one
branch's". I agree this protocol design is not good, but for me this is
latitude.

> 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?

Sorry, but I didn't have clear vision about this till lately. At that
point, I didn't feel flag field is inconsistent, because I mixed up
branch/leaf design problem and label/list design problem.

branch/leaf design problem is that, value of branch's iconic-label is
independent from leaf's iconic-label. IMO this should be more
emphasized (by myself).


label/list problem is that, "prop_label_update doesn't need".
prop_label_update, which updates only branch infomation, was introduced
for performance. Helper protocol is light enough for current computers,
so this is mis-design.

Believe it or not, I mixed up these problems and didn't noticed that
introduction of flag field restricts possible value of branch's
iconic-label. In other words, I disrespected branch's iconic-label at
that point.


But, I'm thinking this flag field inconsistency is solvable with a
little addition of doc/HELPER-PROTOCOL as follows:

If all leaves don't have a flag field, we assume these leaves are
indepentent. If any leaf has a flag field, we should assume these leaves
are possible values of the branch. The leaf which has a flag field is
selected. (In former case, branch doesn't have its own value, we must
define iconic-label and buttontooltip_string of the branch. In latter
case, we can abbreviate iconic-label and buttontooltip_string of the
branch.) In other words, if any leaf has a flag field, the branch
represents a property. If not, a leaf represents a property.


Fortunatelly, there's no need to change toolbar implementation. (I
confirmed by toolbar-gtk. toolbar-qt may need a little modification.)

> > 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.

There's no more uncoded purposes... I think.

> 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.

I'll do after this discussion ended. Now circumstances is floating. (If
I complement now, the complement will be flag field and the concept
'property' only. I don't feel necessity for correction for other parts.)

Following is my proposal of API enchance of property.scm.

If number of state definitions of register-property is 1, map the
registered property as leaf. This will solve the problem I described in
previous mail, "property.scm assumes that branch value is some one of
leaf value".

Though I have no idea about default value for this type of property
(i.e. what should be mapped to branch?), but this seems solvable
problem, doesn't it?

Ah, of course this proposal is story if you agree above break down. If
not, please ignore this proposal.



> > > > 3. System tray seems to intend to indicate one icon
> > 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?

Now I have 2 ideas to solve the problem. One requires modification of
property.scm, another doesn't require. So, my answer is maybe we can. My
ideas are as follows:

1. Add "always-show" flag to property.scm. This idea need modification.

2. Regard first registered property as "The most important one". Usualy
only this most important property shown as icon, others shown by right
click or something similar action. This idea doesn't need modification
of property.scm.

There may be better solution, but now I don't think up.


Regards,


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