[openi18n-im:01437] Re: Upcoming Gimlet related enhancements

Phill,

Impressing progress you, Yong and Gavin have made. It demonstrates well
how dynamic configuration framework will be implemented within IIIM, it
is lovely.

Through the protocol, gimlet can retrieve the property from LE, render
them. With user's interaction on its UI, the modified property will be
sent back to LE to sync with the change internally. Because the
configuration on pallete would be different between languages, new APIs
and spec should be provided to LE developer to instruct them how to
effectively utilize the framework, it is better for us to provide common
language engine (CLE) and implement maximum default configuration within
it by taking all languages into account, with which LE developer don't
need to start from scratch to implement their own pallete.

In parallel with those above tasks, let's implement new protocol for the
new configuration framework within IIIMP and try to export to client
framework as soon as possible, then developing the rendering part within
gimlet and handling the property change in LE will be followed.

Also don't forget the common AUX task which consists of the start-of-art
pre-edit and candidate window.

-federic
 
> Hi, team,
> 
>     Thanks for the introduce from Hideki for the configuration window
> and panel. In the past weeks, Yong Song, Gavin Tu and me are working
> on
> this. Currently, we just implement some protype for the dynamic GUI
> builder, not integrated with any of the IIIMF yet. We believe
> it could give some good user experience for both LE developers and IM
> end users,
> and the experimental integration wok is also undergoing.
> 
> Below is current states from us.
> 
>     Firstly, please check the attached screenshot for some direct 
> conception. The screenshots are divide into two category, the "palette
> panel"
> and "configuration window". The most important thing is that all
> the GUI are build dynamicly according to property data which will be
> send from LEs in the future.
> 
>    Secondly,  following is the property data structures, infact its
> header file:
> 
> #ifndef _IM_PROPERTIES_H
> #define _IM_PROPERTIES_H
> 
> typedef enum tagImRenderType {
>     DEFAULT,
> 
>     ITEM,
> 
>     EDIT,
>     PASSWORD,
>     TEXTAREA,
>     SLIDE,
> 
>     TAB,
>     FRAME,
>     LIST,
> } ImRenderType;
> 
> typedef enum tagImPropertyType {
>     STATIC,
>     BOOLEAN,
>     STRING,
>     INTEGER,
>     COMMAND,
>     SEPERATOR,
> 
>     GROUP,
>     RADIOGROUP,
>     GROUPEND,
> } ImPropertyType;
> 
> typedef struct tagImProperty {
>     const char*        key;
> 
>     int                type;
>     int                render;
> 
>     const char*        label;
>     const char*        icon; //in server, it is .xpm file name, when
> send to the aux, it is (const char**)xpm_data
>     const char*        tip;
> 
>     int                visible;
>     int                enable;
> 
>     int                min;
>     int                max;
>     union {
>         int            i_value;
>         const char*    s_value;
>     };
> } ImProperty;
> 
> 
> #endif
> 
> 
>     Thirdly, following is some basic API which may be provided by
> iiimsf to the LEs and how 
> LEs use these API. Generally, there should be two kind of dynamic
> properties, one for
> configuration of the LE's common option for a user on some desktop.
> the other is some
> session related properties, that when their value changes,  some event
> will notify LEs about the
> change. The former is suitable to use "configuration window" GUI and
> the later is good to use
> the "Palette panel" GUI.
> 
>    for the first kind of properties, it is OK to get/set its value in
> the if_getLEValues() and if_setLEValues().
>    for the second kind of properties, One way is to a new service will
> be provided, such like
> 
>         void update_properties(sesssion, int nproperties, const
> ImProperty* properties);
> 
> which should be called in the focus_in() methos by LE to change the
> GUI. and When some events
> or change are generated from palette panel,  the event will be send to
> LEs by setSCValues() or some
> other new event method.
> 
>    Anyway, it is easy to provide these functions in both current LEIF
> SPI and future LEIF tier2. We
> need to make the spec out ASAP.
> 
>     Last, we'd like to give some raw draft when we start working on
> those dynamic GUI builder, although
> some of its content is modified in current demo implementation. Just
> as reference:
> 
> MENU Context and Normal Context
> ROOT Group: the hidden root of all properties, in Palette, it's a
> MENU, for configuration, it could be think as a window or FRAME. The
> introduce two different context: 
> 
>               * MENU Context is used in the palette, the click on
>                 Group/Item will be converted to event and send to the
>                 sever imediatly. 
>               * MENU can only contains Render type: LIST, ITEM 
>               * The top level of the palette looks like buttons, but
>                 they acts as menus or menuitems 
>         
>       * FRAME Context will be used in the configuration Window, any
>         change will not be send back to server after whole
>         configuration finished, i.e., OK/Apply (which are not inside
>         the properties) buttons are pushed.
> 
> 
> Property fields
>               Fields
>         General Description
> key
> a string to identify the property.
> For those properties like
> Seperator, GroupEnd,
> non-RadioGroup, etc, it could be
> null. Which means they do not need
> any feedback. The key should be
> checked inside events.
> type
> The type of the property. Nomarlly
> there are two categories op types:
> FolderType and LeafType.
> render
> How to render the property. This
> field is highly depend on the type
> field, but DEFAULT could always be
> used. In case the GUI builder think
> this field are given wrong value,
> it could be back-off to DEFAULT.
> label,tip,icon
> the displayed text lable, image
> icon file path and the tip text.
> Note, label is different with
> string value.
> enable
> Whether or not this GUI item is
> enabled. Group's disable state will
> affect all children.
> visible
> Whether or not this GUI item is
> visible. Group's invisible state
> will affect all children.
> min,max
> Specify the INTEGER range or STRING
> lenght limits.
> i_value
> integer value
> s_value
> string value
> 
> 
> 
> Property Type and its field meaning
> Group
> render
>       * TAB: Must be the first leve
>         child of ROOT, and all
>         siblings are TAB rendered
>         Group. 
>       * FRAME: Normal frame, maybe
>         a rectangle around group
>         elements, make related
>         properties together. 
>       * LIST: 
>               * In MENU context, it
>                 is a MENU contains
>                 a list of
>                 items(submenu or
>                 menu items). 
>               * In FRAME context,
>                 it is a LISTBOX to
>                 display and
>                 multi-select a list
>                 of items. Children
>                 must be ITEMs 
>         
>         
> DEFAULT render type is FRAME
> 
> RADIOGROUP(children must be
> BOOLEANs)
> render
>       * LIST: 
>               * In FRAME context,
>                 it is a Combobox to
>                 display and select
>                 single value. 
>               * In MENU context, it
>                 is a MENU contains
>                 sub-items 
>       * FRAME: 
>               * In FRAME context,
>                 it is a
>                 single-selection
>                 LISTBOX
>               * In MENU context,
>                 there will be of
>                 no-menu for the
>                 group, but just
>                 list children as
>                 menu-items. and try
>                 to add sepators
>                 before/after it if
>                 needed. 
>         
>         
> DEFAULT render type is FRAME
> 
> icon/label
> When not specified, it will borrow
> from the child selected. 
> s_value
> It should be set to "key" of the
> one of its Boolean child. To
> Boolean items in a RadioGroup,
> their i_values are ignored, i.e.,
> not used, and never be transfered
> back as event. The change will be
> reflected using RadioGroup's value
> change. 
> 
> Note, when RadioGroup has only two
> children, it's another kind of
> boolean. This kind of boolean is
> useful to implement the first-level
> palette bar. For this kind of
> RadioGroup: (1)Frame render type in
> menu context, (2) only two
> children, (3)icon/label not
> specified. the palette bar will not
> pop-up submenus, but switch
> icon/label directly. :-)) 
> 
> Boolean
> render
>       * ITEM: 
>               * In FRAME context,
>                 it is a CHECKBOX. 
>               * In MENU context, it
>                 is a MENUITEM with
>                 a check icon left
>                 to its icon and
>                 text 
>         
>         
> DEFAULT render type is ITEM of
> cause. 
> 
> Command
> render
>       * ITEM: 
>               * In MENU context, it
>                 is a MENUITEM with
>                 a check icon left
>                 to its icon and
>                 text 
>               * In FRAME context,
>                 it is a BUTTON.
>                 NEED to SUPPORT???
>         
>         
> DEFAULT render type is ITEM of
> cause. 
> 
> String (Do NOT supported in MENU
> context)
> render
>       * EDIT: Single line edit. 
>       * TEXTAREA: multi-line edit. 
>       * PASSWORD: single line edit
>         with password masking.
> DEFAULT render type is EDIT. 
> 
> INTEGER(Do NOT supported in MENU
> context)
> render
>       * EDIT: Single line edit. 
>       * SLIDE: A slide bar to
>         adjust the value by mouse
>         click/dragging.
> DEFAULT render type is EDIT. 
> 
> GROUPEND
> render
>       * DEFAULT: mark the group
>         ending. The matching of
>         GROUPEND to GROUP or
>         RADIOGROUP is like the
>         matching of } to { in C
>         source code. 
> SEPERATOR
> render
>       * DEFAULT: A Seperator 
> STATIC
> render
>       * DEFAULT: A text label
>         with/without image 
> 
> 
> Best regards
> Phill Zhang
> 
> 在2005年06月25日的05:16，Hideki Hiura写道： 
> > It's a preliminary anouncement. 
> > 
> > There has been a series of gimlet related updates in progres.
> > 
> > Among planned enhancencents below,
> > 
> > >     * GIMLET enhancement
> > >           o SUB-TASKS:
> > >                 + rewrite to use systray (notification area)
> > >                 + rewrite to use iiimcf
> > >                 + unify all configuration to one window
> > >                 + rename to something more desktop neutral
> > >                 + move all lang data out to LEs
> > 
> > two big enhancements are very close to be done.
> > 
> > First one is "unify all configuration to one window" feature.
> > 
> > It consists of the property configuration framework which allows LEs to 
> > dynamically create configurable GUI property panel.
> > 
> > This will significantly reduce the use of AUX for simple property
> > panel. LE can send a property configuration data and gimlet
> > dynamically creates GUI which a user can manipulate, select and input.
> > The value of attributes a user changes would be sent back from gimlet 
> > to LE.
> > 
> > I saw the demo yesterday in Beijing presented by Phill Zhang.
> > He demonstrated that custom configuration panel GUI and selection 
> > of property without writing GUI code in LE but customizing 
> > the data to be sent, 
> > 
> > Phill will send out its spec and current sample screenshots by Monday.
> > 
> > Second one is "move all lang data out to LEs" feature. 
> > 
> > It already shows significant progress in what Federic posted yesterday
> > as [openi18n-im:01432].  It enhances the LE info to be exchanged
> > betwee LE and gimlet, so that a user can switch input methods within
> > LE if an LE has multiple input methods inside.
> > 
> > Regarding "rename to something more desktop neutral" task, anyone
> > has any suggestion?
> > 
> > We need to change both part of the name of gnome-im-switcher.
> > Not only "gnome-" part, but "im-switcher" may not be appropariate
> > name, as the first feature described above, the major part of
> > gimlet becomes dynamic configuration framework.
> > Any idea?
> > 
> > Cheers,
> > Hideki