From: Gustavo S. B. <bar...@gm...> - 2007-11-15 15:06:37
|
On Nov 15, 2007 11:10 AM, Andre Magalhaes <and...@gm...> wrote: > Hey! > > On Nov 15, 2007 10:52 AM, Stafford Horne <sh...@so...> wrote: > > This is very cool. > Tnx for the feedback. > > > Ill need more time to look into it and read the comments. Do you think this should be integrated into ETK? I thought it might be better to support input methods directly in the ecore_x layer as I have done with XIM. This has been required as XIM ties in closely with the X event loop. > > > > Maybe this is not required if we go directly to SCIM / UIM. > I will integrate it with ETK today, this is the easiest part. > Regarding integrating it directly into ecore_x, IMHO this shouldn't be > done, as we would loose the ability to use it on Windows, Macos, .... > That's why we have set_client_window (see other mail). Remember that > this should be an abstraction layer on top of existent IM. The hildon > input method plugin is highly tied to X event loop, and it works quite > well, I believe you won't have a problem implementing XIM on top of > Ecore_IM. You can take a look at > http://cvs.gnome.org/viewcvs/gtk%2B/modules/input/gtkimcontextxim.c?rev=1.54&view=markup > as the base for a Ecore_IM_XIM, as the API of GtkIMContext and > Ecore_IM_Context is quite similar. Yes, building XIM on top of this Ecore_IM would be a better option. shorne, could you have a look? -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: bar...@gm... MSN: bar...@gm... ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 |