[Uim] Replacing property handling codes with property.scm

[TOKUNAGA Hiroyuki]

On Fri, 22 Oct 2004 10:35:11 +0900
YamaKen <yamaken at bp.iij4u.or.jp> wrote:

> Hi Hiroyuki, I've decided to advance.
> 
> At Thu, 21 Oct 2004 12:05:05 +0900,
> tkng at xem.jp wrote:
> > 
> > On Thu, 21 Oct 2004 07:30:24 +0900
> > YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > 
> > > At Thu, 21 Oct 2004 06:47:02 +0900,
> > > tkng at xem.jp wrote:
> > > > 
> > > > On Wed, 20 Oct 2004 21:57:41 +0900
> > > > YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > > 
> > > > 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.
> 
> Perhaps you did mean 'non-selectable menu (i.e. no flags)' by
> the word 'constant variable'. Following my answer assumes it.

I associate 'non-sensitive menu (visually showed, but cannot activate)'
with the word 'non-selectable menu'. I prefer 'non-selective menu'. But
no flags is same as my intension.


> I'll redesign property.scm to implement such features. Please
> provide me following exact informations. I'll use it as design
> constraints to establish another model for new framework. Answer
> carefully.
> 
> - Does branch arguments and label have exactly same role?
> 
>   i.e. Is prop_label_update leaf-less prop_list_update?

Yes.


>   i.e. Is prop_label_update removable from uim?

Yes if no other bridges use the function.


> - Is branch permanently stable in non-selectable menu model?
> 
>   i.e. The branch is not rewritten during register-im and end of
>   life of the process (except for input context switching)

Yes.


> - Is leaf-less branch intended?
> 
>     branch anthy   <-- indicates currently active input method

No, I didn't intended, but such usage may be useful.


> - Is leaf-less branch activatable?
> 
>     branch sw      <-- exec uim-im-switcher when activated (clicked)

No, I'm not intended. But I want know other opinions about this.


> - Is generic information indicator intended?
> 
>     branch 10      <-- indicates type/sec, with or without leaves

No. Such usage is interesting as a hack (do you know AmetMulti?), but
I'm not intended.


> - Is hybrid selectable menu such as following example intended?
> 
>     branch dictionary
>        leaf  add a word to dictionary <-- unselectable
>        leaf  edit user dictionary     <-- unselectable
>        leaf  dictionary 1             <-- selectable
>        leaf  dictionary 2 *           <-- selectable, selected

No. Of course such menu is allowable as an user, but the development
cost seems too high a bit relative to the merit.


> - Are other models intended?

No.


> I feel that the meanings of the words property/variable/value
> are quite differently recognized by us, and sharing same view is
> difficult.
> 
> To avoid such worthless discussion, I suggest following names
> and message format for future.
> 
> "manipulator" manipulator-id
>   "indicator" indication-id(can be null) iconic-label label short-desc
>   "action" action-id iconic-label label short-desc activity
>   "action" action-id iconic-label label short-desc activity
>   "action" action-id iconic-label label short-desc activity
>   ...
> 
> I think that the above model is closer to actual use, and
> reduces misunderstanding and time-consuming discussions.
> How do you feel it?

indicator and action is good, but manipulator is hard to understand for
me. Isn't combination of indicator and action enough?


> At Thu, 21 Oct 2004 06:47:02 +0900,
> tkng at xem.jp wrote:
> > 
> > On Wed, 20 Oct 2004 21:57:41 +0900
> > YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> 
> > 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.
> 
> No. Don't ignore resource-sensitive embedded platforms. Consider
> uim may run on phones someday. Helper protocol is heavy and
> power-consuming for such platforms.

For such platform, maybe we should provide another API.


> > > > > > 3. System tray seems to intend to indicate one icon
> 
> > 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.
> 
> I prefer 2. The concept 'primary property' already exists in
> property.scm.
> 
> I think that we should not assume implementation specific
> visualization method (i.e. what is actually shown) of
> prop_list_update message receivers. We should provide logical
> information.

OK, I'll rewrite toolbar with latter idea.


Regards,

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