[Uim] Replacing property handling codes with property.scm

[YamaKen]

At Sat, 23 Oct 2004 11:27:03 +0900,
tkng at xem.jp wrote:
> 
> On Fri, 22 Oct 2004 10:35:11 +0900
> YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > 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.

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

I'll consider all of above usages in new framework.

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

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

Not enough.

A name is needed to indicate following intentions even if the
word 'manipulator' is not the best.

- what the combination of indicator and actions means

- independent and peer existence of indicator and actions

- indicator and actions are element of a higher entity
  (manipulator)

What I meant by the word 'manipulator' is an unit of user
interface entity. The unit which has an unique ID is required to
implement the framework, to contorl user preference.

  ;; controls:
  ;; - what manipulators will be shown
  ;; - order of showing
  (define anthy-manipulators '(prop_anthy_input_mode
                               prop_anthy_kana_input_method))

  "manipulator" "prop_anthy_input_mode"
    "indicator" "prop_anthy_direct" "a" "direct" "direct input mode"
    "action" "prop_anthy_direct" "a" "direct input" "direct input mode" "*"
    "action" "prop_anthy_hiragana" "hi" "hiragana" "hiragana input mode" ""
    "action" "prop_anthy_katakana" "ka" "katakana" "katakana input mode" ""
  "manipulator" "prop_anthy_kana_input_method"
    "indicator" "prop_anthy_roma" "R" "romaji" "romaji input mode"
    "action" "prop_anthy_roma" "R" "romaji" "romaji input mode" "*"
    "action" "prop_anthy_kana" "ka" "kana" "kana input mode" ""

# I use old 'prop_*' names only for example

And it is also required to identify the unit by message
receivers:

- To implement partial update of manipulators (e.g. only updates
  prop_anthy_input_mode of the manipulators). Because some menu
  such as popup-style im-switcher comprises quite long message,
  so the partial update is valuable

- To show specific units such as "prop_*_input_mode" only

I think that the names 'entity' or 'unit' are too generic to
indicate the role, so I suggest the name 'manipulator'. Do you
have a good idea? Is the name 'ui-unit' is meaningful for you?

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

Yes, the ustore framework is the API. I'll do it later. But what
I meant is don't forget or ignore existence of such platforms.

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