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

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