[Uim] Replacing property handling codes with property.scm

[YamaKen]

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.

1. OK
2. OK

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?
  i.e. Is prop_label_update removable from uim?

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

- Is leaf-less branch intended?

    branch anthy   <-- indicates currently active input method

- Is leaf-less branch activatable?

    branch sw      <-- exec uim-im-switcher when activated (clicked)

- Is generic information indicator intended?

    branch 10      <-- indicates type/sec, with or without leaves

- 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

- Are other models intended?

> > What did you mean by the word 'constant variable'? Show me
> > actual example as same style as follows.
> > 
> > branch dictionary
> >    leaf  add a word to dictionary
> >    leaf  edit user dictionary
> 
> If I indicate an example, this is the example. To be more detailed,
> "leaf  add a word to dictionary" is constant variable.

The 'constant variable' model in your mind and mine are
different. In my sense, 'constant variable' means following
model.

  branch hi
     leaf   hi hiragana input mode  <-- the only possible value

> But, I think these examples are not easy to understand, because their
> form are after mapped helper-protocol. Constant variable has only 1
> state definition, the constant property has only 1 possible state.
> 
> My proposal of previous mail is that make an exception in favor of
> handling of these constant variables. (Ordinary, property is mapped to
> branch, but constant property is mapped to leaf).

What means 'constant property is mapped to leaf'? (No answer
needed)

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?

I'm tired to find out true meanings of the ambiguous words
property/variable/value/branch/leaf, so I want to use above
'manipulator' model in new framework even if actual messages are
composed as prop_list_update.

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.

However, I also think deprecatation of prop_label_update is
good because it does not resolve the problem truely.

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

Did you mean 'value' by the word 'property'? Ah, no discussion
needed...

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

As I described above, I can't understand what is meant by 'map
the property as leaf'. But I'll resolve any problems by new
framework. Don't worry.

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

I'll redesign the framework and resolve it.

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

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