[Uim] Replacing property handling codes with property.scm

YamaKen yamaken at bp.iij4u.or.jp
Tue Oct 19 12:37:56 EEST 2004


At Tue, 19 Oct 2004 17:10:24 +0900,
tkng at xem.jp wrote:
> 
> On Tue, 19 Oct 2004 05:56:46 +0900
> TOKUNAGA Hiroyuki <tkng at xem.jp> wrote:
> 
> > On Mon, 18 Oct 2004 16:47:43 +0900
> > YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > 
> > > I'm also going to replace property handling codes in each IMs
> > > with new property handling framework existing in property.scm.
> > > 
> > > This is the last chance to reflect your opinion about it. I mean
> > > it.

> 1. Icon support
> 
> Property aims to provide some infomation which are shown by toolbar, but
> property lacks icon supports. It's a chance to add an icon support to uim.

The feature is already intended. Suppose retrieving an icon for
the prop-state prop_anthy_hiragana.

We can construct the corresponding icon file name from a icon
search path and prop-state-id.

(define icon-path '("/usr/X11R6/share/icons/uim"
                    "/usr/local/share/icons/uim"))

Since prop_list_update contains the prop-state-id, receiving
applets can compose the pathname
/usr/X11R6/share/icons/uim/prop_anthy_hiragana.png from the
icon-path and the prop-state-id.

I believe that icon-path information should be isolated from
each prop-state definitions to keep flexibility. For example, we
can introduce some icon substitution feature without modifying
the prop-state definition.

> 2. Property isn't always used to indicate state.
> 
> Current implemantation of property doesn't consider about items which is
> not indicating state. For example, uim-anthy may have a property item
> which role is to call dictionary manager. Though I'm not confident in
> the feature is appropriate for the name 'property', this feature itself
> would be worth to consider to implement. What's your opinion?

Please tell us what is the 'property' for you.

I have taken efforts to understand what is the meaning of the
'property' from your codes, and my current understanding is
described in doc/HELPER-PROTOCOL as follows. You must share your
intention which is hardly imagined by others if my understanding
still differs from yours. See also my winding understanding
history about it in r1431 and r1332 of commit log.

doc/HELPER-PROTOCOL
----------------------------------------------------------------
* Property messages

    The concept 'property' in uim means 'properties of input method'. An input
    method (in accurately, input context) can own arbitrary number of
    properties. A property is ordinarily appeared for user as a popup menu
    with an indicator. Such indicator will be appeared simultaneously for user
    if the input method has 2 or more properties. One property controls one
    variable state of the input method such as 'input mode' or 'keymap'.


Please consider the definition of the word 'property' in a
dictionary and object oriented computer programming
domain. People will expect such meanings.

property n.
1 (a) something owned; a possession, esp. a house, land,
  etc. (b) Law the right to possession, use, etc. (c)
  possessions collectively, esp. real estate
2 an attribute, quality, or characteristic
3 a moveable object used on a theatre stage, in a film, etc
4 (Logic) a quality common to a whole class but not necessary to
  distinguish it from others.

'a property item which role is to call dictionary manager'
sounds completely different thing for me. I can't regard it as a
property of an input method. What is the owner of the property?

I think that we should develop different framework for such
different things. As I said before, I will develop 'ustore'
framework which integrates and generalizes
retrieve/store/propagate/notify of informations. It will replace
property, helper-system, custom API, IM-related information
retrieving, callback interfaces and more. But it is a future
consideration.

I think that we should simply replace the property handlings
with current property.scm, for now.

> 3. System tray seems to intend to indicate one icon
> 
> This will need some explanation. 
> 
> Currently, uim-toolbar-gtk-systray show same widget as uim-toolbar-gtk.
> But from the System tray protocol specification, " From a UI standpoint,
> the system tray is normally used for transient icons that indicate some
> special state". 
> 
> We should not show all infomation by uim-toolbar-gtk-systray, so we need
> a way to know what is important and what is not so.
> 
> I don't have good idea about this, only wrinting the problem...

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.

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



More information about the uim mailing list