Andre,
This is very cool.
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.
-Stafford
On Wed, 14 Nov 2007 21:30:53 -0300
"Andre Magalhaes" <andrunko@...> wrote:
> Hey,
>
> I've finished a first version of the Ecore_IM (that's how I called it)
> and you can check it from:
> http://staff.get-e.org/?p=users/andrunko/ecore.git;a=commitdiff;h=d8264fed3811ef9262437b57c1c6f9e68676c822
>
> Here is a little overview of the architecture:
> The module ecore_im is the responsible for loading plugins and handle
> them. Applications should make use of this modules through the
> Ecore_IM_Context interface.
> Plugins writers should implement some methods defined
> Ecore_IM_Context_Class and export the through the Ecore_IM_Context
> API.
>
> Attached there is a test (test_im.c) example of how to use the API.
> The idea is to integrate it with Etk/EWL. I should start integrating
> it with Etk tomorrow, if somebody is interested in integrating it with
> EWL it would be great.
>
> I am not sure if the API covers all various Input Methods (XIM, SCIM,
> ...) possibilities, but we can extend it if needed. The API is based
> on GtkIM and Qt input module.
>
> Issues:
> - In order to set a client window to the input method, I had to use a
> (void *), as Ecore does not abstract different
> "Windows" (Ecore_X_Window, Ecore_Win32_Window, ...). I am not sure if
> this a problem at all, cause plugins for windows will just be compiled
> on windows, .... Who who uses the API should take care of passing the
> right window to the IM.
> - The hildon_input_method immodule shipped with the patch is heavily
> based on hildon-input-method-framework and this framework is LGPL. I
> don't know if we will be able to ship it with ecore, but if not, I can
> create a separate package for it.
> - Documentation love.
>
> Well, that's it, I will let you comment now
>
> Hope you appreciate
>
> BR
> Andre
>
> On Nov 12, 2007 11:55 AM, Stafford Horne <shorne@...> wrote:
> > I hope the immodules work is going well.
> >
> > I had started on Ecore_X XIM integration and decided I had better finish. Below is my current patch which supports callbacks XIM style. I have found several limitations with callbacks.
> >
> > Pitfalls:
> > * Callbacks only provide current edit string (i.e. doesnt provide kanji choices)
> > * IM still draws choices dialog
> > * With Callbacks API we can not specify the location of the choices dialog
> > * UIM does not support callbacks
> >
> > I think we could live we these problems but lets see how the immodules pans out.
> >
> > http://www.shorne-pla.net/uploads/ecore_xim-0.2.diff
> >
> > -Stafford
> >
> > On Fri, 9 Nov 2007 11:31:13 -0300
> > "Andre Magalhaes" <andrunko@...> wrote:
> >
> >
> > > Hey,
> > >
> > > On Nov 8, 2007 8:13 PM, Stafford Horne <shorne@...> wrote:
> > > > Thanks, this is a helpful document. I agree that immodules are a cleaner way to handle input. They will allow us direct access to input method API.
> > > Yeah, i believe immodules are the way to go. I would be perfect if we
> > > could have a freedesktop library that everybody could share, so one
> > > didn't need to write immodule for Gtk/Qt/Ecore.
> > >
> > > > The problem I saw with this is:
> > > > 1. We will have to develop more code to get off the ground
> > > > 2. For every inputmethod we will have to develop a module for support
> > > I am going to start implementing the immodules support today and I
> > > believe I should have something working next week. The problem is that
> > > i need to make hildon input method working with ecore/etk, and I don't
> > > want to make a workaround to change it later. Writing modules for
> > > every new input method we want to support is the cost we have to pay
> > > to be able to support multiple input method across multiple platforms
> > > (Windows, Maemo, Macos, ...).
> > >
> > > > With XIM we will be able to use existing input method bridges to take advantage of input methods right now. I say we try out XIM and find the limitations ourselves.
> > > It would be great if you could implement a XIM module when I have
> > > something working.
> > >
> > > > Do you know if Hildon has an XIM bridge? Also, what is so legacy about XIM now anyway? By using callbacks only API we are basically cutting out all of the Legacy baggage of the protocol.
> > > Hildon does not have a XIM bridge and I don't think they intend to
> > > implement it anytime soon. They already have a Gtk immodule for it,
> > > and it seems they don't have interest in adding support for other
> > > toolkits.
> > >
> > > BR
> > >
> > > --
> > > Andre Moreira Magalhaes (andrunko)
> > > --------------------------------------------------------
> > > Jabber: andrunko@...
> > > MSN: andremoreira@...
> > > Skype: andrunko
> > > Blog: http://andrunko.blogspot.com
> > >
> >
> > > -------------------------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc.
> > > Still grepping through log files to find problems? Stop.
> > > Now Search log events and configuration files using AJAX and a browser.
> > > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > > _______________________________________________
> > > enlightenment-devel mailing list
> > > enlightenment-devel@...
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
>
> --
> Andre Moreira Magalhaes (andrunko)
> --------------------------------------------------------
> Jabber: andrunko@...
> MSN: andremoreira@...
> Skype: andrunko
> Blog: http://andrunko.blogspot.com
>
|