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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote:
>
>
> > Hey,
> >
> > On Nov 8, 2007 8:13 PM, Stafford Horne <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > MSN: [EMAIL PROTECTED]
> > 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@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Andre Moreira Magalhaes (andrunko)
--------------------------------------------------------
Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
Skype: andrunko
Blog: http://andrunko.blogspot.com
/*
* vim:ts=8:sw=3:sts=8:noexpandtab:cino=>5n-3f0^-2{2
*/
#include <stdio.h>
#include <Ecore.h>
#include <Ecore_Evas.h>
#include <Ecore_IM.h>
#include <Ecore_X.h>
static int
_retrieve_surrounding_cb(void *data, Ecore_IM_Context *ctx, char **text, int *cursor_pos)
{
if (text) *text = strdup("test surrouding");
if (cursor_pos) *cursor_pos = 3;
return 1;
}
static int
_event_commit_cb(void *data, int type, void *event)
{
Ecore_IM_Event_Commit *ev = event;
fprintf(stderr, "commited %s\n", ev->str);
}
int main(int argc, char **argv)
{
Ecore_List *ids;
const char *id;
Ecore_Evas *ee;
Evas *evas;
Evas_Object *rect;
Ecore_IM_Context *ctx;
fprintf(stderr, "** initializing ecore\n");
ecore_init();
fprintf(stderr, "** initializing ecore_evas\n");
ecore_evas_init();
fprintf(stderr, "** initializing ecore_im\n");
ecore_im_init();
fprintf(stderr, "** retrieving ecore_im_context_available_ids_get\n");
ids = ecore_im_context_available_ids_get();
if (ids)
{
ecore_list_first_goto(ids);
fprintf(stderr, "** available input methods:");
while (id = ecore_list_next(ids))
{
fprintf(stderr, " %s", id);
}
fprintf(stderr, "\n");
}
ee = ecore_evas_software_x11_new(NULL, 0, 0, 0, 800, 480);
ecore_evas_title_set(ee, "test");
ecore_evas_name_class_set(ee, "test", "test");
ecore_evas_fullscreen_set(ee, 1);
ecore_evas_show(ee);
evas = ecore_evas_get(ee);
evas_image_cache_set(evas, 8 * 1024 * 1024);
rect = evas_object_rectangle_add(evas);
evas_object_move(rect, 50, 50);
evas_object_resize(rect, 50, 50);
evas_object_show(rect);
fprintf(stderr, "** creating context\n");
ctx = ecore_im_context_add("hildon-input-method");
ecore_im_context_client_window_set(ctx,
(void *) ecore_evas_software_x11_window_get(ee));
ecore_im_context_retrieve_surrounding_callback_set(ctx, _retrieve_surrounding_cb, NULL);
ecore_im_context_reset(ctx);
ecore_im_context_show(ctx);
ecore_event_handler_add(ECORE_IM_EVENT_COMMIT, _event_commit_cb, NULL);
ecore_main_loop_begin();
ecore_im_context_hide(ctx);
return 0;
}
-------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
