Re: [E-devel] Ecore + XIM working
I committed the code yesterday as Ecore_IMF as agreed on IRC. The hildon input method plugin wasn't committed cause it's LGPL. I created a garage project and uploaded the code there. If you are interested please check it from https://garage.maemo.org/projects/himf-ecore/ 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore + XIM working
On Nov 21, 2007 12:55 AM, Andre Magalhaes [EMAIL PROTECTED] wrote: In case you are interested I created a new Input Method module for the keyboard done by Gustavo. Really amazing results, it took us just few edje changes (so it does the in/out animation and the semi-transparent background) and the integration of ecore_imf by andre to have this nicely integrated. worth noticing that this uses the same Ecore_Evas/Evas than the application in order to have it blend nicely without relying on xcomposite extension, so it works better when you use a full-screen app, or at least one that the keyboard fits horizontally. Great work Andre, -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore + XIM working
On Nov 16, 2007 10:46 AM, Stafford Horne [EMAIL PROTECTED] wrote: On Thu, 15 Nov 2007 12:06:27 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: Yes, building XIM on top of this Ecore_IM would be a better option. shorne, could you have a look? Hi Guys, I look a closer look at Ecore_IM. Great :). Currently it provides an function called ecore_im_context_filter_event which takes a void * agument for event_info. This seems to be a bit of a problem as the application will define the event_info. It would not then be possible for an arbitrary module to handle this application specific data. What is the Idea behind this? Actually this event_info should not be defined by the application. I chose to use Evas_Event_* as event_info to not replicate the event structures already defined in Evas. As you can see the type is a Evas_Callback_Type (EVAS_CALLBACK_MOUSE_DOWN, ...). Evas already uses event_info as void * to represent the various Evas_Event_* In order for XIM to be integrated successfully we will need one more Ecore_IM_Context_Class function, void ecore_im_context_filter_keypress(Ecore_IM_Context *ctx, Ecore_IM_Event_Key_Down?? *event) This will be used to: 1. recreate the xevent using the IM key event 2. Use the Xutf8StringLookup function to translate the event by the input method Just use the filter_event method and filter for events with type EVAS_CALLBACK_KEY_DOWN/UP. It should be enough, please let me know if you need anything else. Definitely an XIM module could not be used unless the application is using the ecore_x event loop. So the implementation would have to be somewhat dependent on Ecore_X. I am still thinking about this. On my hildon_input_method create function I try to open the X display (ecore_x_display_get()), and if it fails it returns NULL. Maybe you can do the same. 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore + XIM working
On Thu, 15 Nov 2007 12:06:27 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: Yes, building XIM on top of this Ecore_IM would be a better option. shorne, could you have a look? Hi Guys, I look a closer look at Ecore_IM. Currently it provides an function called ecore_im_context_filter_event which takes a void * agument for event_info. This seems to be a bit of a problem as the application will define the event_info. It would not then be possible for an arbitrary module to handle this application specific data. What is the Idea behind this? In order for XIM to be integrated successfully we will need one more Ecore_IM_Context_Class function, void ecore_im_context_filter_keypress(Ecore_IM_Context *ctx, Ecore_IM_Event_Key_Down?? *event) This will be used to: 1. recreate the xevent using the IM key event 2. Use the Xutf8StringLookup function to translate the event by the input method Definitely an XIM module could not be used unless the application is using the ecore_x event loop. So the implementation would have to be somewhat dependent on Ecore_X. I am still thinking about this. -Stafford - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore + XIM working
I just finished the E (e_entry actually) IM support. Patch attached.
It's quite easy to integrate it with other widgets if needed. If
someone wants to help please let me know
BR
--
Andre Moreira Magalhaes (andrunko)
Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
Skype: andrunko
Blog:http://andrunko.blogspot.com
diff --git a/src/lib/etk_entry.c b/src/lib/etk_entry.c
index 3c9d69e..29cc814 100644
--- a/src/lib/etk_entry.c
+++ b/src/lib/etk_entry.c
@@ -626,7 +626,10 @@ static Etk_Bool _etk_entry_internal_realized_cb(Etk_Object *object, void *data)
if (entry-im_context
etk_widget_is_focused(ETK_WIDGET(entry)))
+ {
+ ecore_im_context_reset(entry-im_context);
ecore_im_context_focus_in(entry-im_context);
+ }
return ETK_TRUE;
}
@@ -787,8 +790,11 @@ static Etk_Bool _etk_entry_key_down_cb(Etk_Object *object, Etk_Event_Key_Down *e
_etk_entry_selection_copy(entry, ETK_SELECTION_PRIMARY, ETK_FALSE);
if (entry-im_context)
+ {
+ ecore_im_context_reset(entry-im_context);
ecore_im_context_cursor_position_set(entry-im_context,
etk_editable_cursor_pos_get(editable));
+ }
return (!stop_signal);
}
@@ -871,8 +877,11 @@ static void _etk_entry_editable_mouse_down_cb(void *data, Evas *evas, Evas_Objec
}
if (entry-im_context)
+ {
+ ecore_im_context_reset(entry-im_context);
ecore_im_context_cursor_position_set(entry-im_context,
etk_editable_cursor_pos_get(entry-editable_object));
+ }
}
/* Called when the entry is released by the mouse */
@@ -920,7 +929,10 @@ static void _etk_entry_editable_mouse_move_cb(void *data, Evas *evas, Evas_Objec
{
etk_editable_cursor_pos_set(entry-editable_object, pos);
if (entry-im_context)
+ {
+ecore_im_context_reset(entry-im_context);
ecore_im_context_cursor_position_set(entry-im_context, pos);
+ }
}
}
}
@@ -1006,7 +1018,10 @@ static Etk_Bool _etk_entry_focused_cb(Etk_Object *object, void *data)
etk_editable_selection_show(entry-editable_object);
etk_widget_theme_signal_emit(entry-internal_entry, etk,state,focused, ETK_FALSE);
if (entry-im_context)
+ {
+ ecore_im_context_reset(entry-im_context);
ecore_im_context_focus_in(entry-im_context);
+ }
return ETK_TRUE;
}
@@ -1021,14 +1036,20 @@ static Etk_Bool _etk_entry_unfocused_cb(Etk_Object *object, void *data)
etk_editable_cursor_move_to_end(entry-editable_object);
if (entry-im_context)
+ {
+ ecore_im_context_reset(entry-im_context);
ecore_im_context_cursor_position_set(entry-im_context,
etk_editable_cursor_pos_get(entry-editable_object));
+ }
etk_editable_selection_move_to_end(entry-editable_object);
etk_editable_cursor_hide(entry-editable_object);
etk_editable_selection_hide(entry-editable_object);
etk_widget_theme_signal_emit(entry-internal_entry, etk,state,unfocused, ETK_FALSE);
if (entry-im_context)
+ {
+ ecore_im_context_reset(entry-im_context);
ecore_im_context_focus_out(entry-im_context);
+ }
return ETK_TRUE;
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore + XIM working
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)
Re: [E-devel] Ecore + XIM working
Hey! On Nov 15, 2007 10:52 AM, Stafford Horne [EMAIL PROTECTED] 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.54view=markup as the base for a Ecore_IM_XIM, as the API of GtkIMContext and Ecore_IM_Context is quite similar. 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
Re: [E-devel] Ecore + XIM working
On Nov 15, 2007 11:10 AM, Andre Magalhaes [EMAIL PROTECTED] wrote: Hey! On Nov 15, 2007 10:52 AM, Stafford Horne [EMAIL PROTECTED] 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.54view=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: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - 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
Re: [E-devel] Ecore + XIM working
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 [EMAIL PROTECTED] 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 [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
Re: [E-devel] Ecore + XIM working
I've changed some minor things, check the new version from: http://staff.get-e.org/?p=users/andrunko/ecore.git;a=summary -- 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
Re: [E-devel] Ecore + XIM working
On Thu, 15 Nov 2007 12:06:27 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: Yes, building XIM on top of this Ecore_IM would be a better option. shorne, could you have a look? Yeah, Ill take a look. I probably wont have much time between now and the first week of december, but Ill try. -Stafford - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore + XIM working
On Nov 15, 2007 7:56 PM, Stafford Horne [EMAIL PROTECTED] wrote: On Thu, 15 Nov 2007 12:06:27 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: Yes, building XIM on top of this Ecore_IM would be a better option. shorne, could you have a look? Yeah, Ill take a look. I probably wont have much time between now and the first week of december, but Ill try. Great. I just uploaded the Etk patch integrating Ecore_IM into Etk_Entry. You can check it and the updated Ecore_IM from my git tree on staff.get-e.org. Raster, if you could take a look at Ecore_IM it would be great. I would like to integrate it on Ecore asap, as we need it for canola, and don't want to be shipping a patched ecore :) Note: There was some modifications on the Ecore_IM patch but i used the same commit to make it easy to integrate it with ecore in the future if needed. So if you were using the old patch please check it out again :) 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore + XIM working
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 - 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
Re: [E-devel] Ecore + XIM working
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
Re: [E-devel] Ecore + XIM working
On Thu, 8 Nov 2007 11:12:41 +1100 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: as per IRC - lets just drop the preedit_type - lets just make it callback based (ie the ecore_x events to notify you of info from the IM and if you need to send anything - ecore_x calls to tell it stuff).otherwise looks ok to me. Thanks, One more change is that we will probably need to register some event data for the callbacks. i.e. ecore_x_window_input_context_init(win, event_data); This way if you are processing events in your event loop you can have some data to work with. The one thing left to worry about is asynchronous processing of the event queue and out of order preedit events. -Stafford - 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
Re: [E-devel] Ecore + XIM working
Hi, I was studying how input methods work, as I need to integrate the hildon keyboard in ecore+etk. I believe we should use an approach similar to Gtk/Qt4. They have a similar approach to work with im modules, which IMHO should be a library independent of gtk/qt/ecore (freedesktop ^^) and everybody should use it. To take a look at details on how they do it see: http://www.kde.gr.jp/~asaki/how-to-support-input-method.html Basically they have an interface where plugins for different input methods are implemented (XIM, SCIM, hildon-input-method, ...) and a api to use in applications, such as GtkEntry, ... I believe this is more extensible, portable way to integrate im support on ecore, among other things. What do you think? BR Andre On Nov 8, 2007 11:09 AM, Stafford Horne [EMAIL PROTECTED] wrote: On Thu, 8 Nov 2007 11:12:41 +1100 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: as per IRC - lets just drop the preedit_type - lets just make it callback based (ie the ecore_x events to notify you of info from the IM and if you need to send anything - ecore_x calls to tell it stuff).otherwise looks ok to me. Thanks, One more change is that we will probably need to register some event data for the callbacks. i.e. ecore_x_window_input_context_init(win, event_data); This way if you are processing events in your event loop you can have some data to work with. The one thing left to worry about is asynchronous processing of the event queue and out of order preedit events. -Stafford - 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 - 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
Re: [E-devel] Ecore + XIM working
Hi Andre, 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. 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 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. 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. -Stafford On Thu, 8 Nov 2007 12:21:34 -0300 Andre Magalhaes [EMAIL PROTECTED] wrote: Hi, I was studying how input methods work, as I need to integrate the hildon keyboard in ecore+etk. I believe we should use an approach similar to Gtk/Qt4. They have a similar approach to work with im modules, which IMHO should be a library independent of gtk/qt/ecore (freedesktop ^^) and everybody should use it. To take a look at details on how they do it see: http://www.kde.gr.jp/~asaki/how-to-support-input-method.html Basically they have an interface where plugins for different input methods are implemented (XIM, SCIM, hildon-input-method, ...) and a api to use in applications, such as GtkEntry, ... I believe this is more extensible, portable way to integrate im support on ecore, among other things. What do you think? BR Andre On Nov 8, 2007 11:09 AM, Stafford Horne [EMAIL PROTECTED] wrote: On Thu, 8 Nov 2007 11:12:41 +1100 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: as per IRC - lets just drop the preedit_type - lets just make it callback based (ie the ecore_x events to notify you of info from the IM and if you need to send anything - ecore_x calls to tell it stuff).otherwise looks ok to me. Thanks, One more change is that we will probably need to register some event data for the callbacks. i.e. ecore_x_window_input_context_init(win, event_data); This way if you are processing events in your event loop you can have some data to work with. The one thing left to worry about is asynchronous processing of the event queue and out of order preedit events. -Stafford - 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 - 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
Re: [E-devel] Ecore + XIM working
On Tue, 6 Nov 2007 23:53:31 +0900 Stafford Horne [EMAIL PROTECTED] babbled: as per IRC - lets just drop the preedit_type - lets just make it callback based (ie the ecore_x events to notify you of info from the IM and if you need to send anything - ecore_x calls to tell it stuff).otherwise looks ok to me. Hello, It seems my original patch did not go out. The files are here: http://www.shorne-pla.net/uploads/ecore_xim.diff http://www.shorne-pla.net/uploads/xim_ecore.c New function ecore_x_window_input_context_init(win, Root); Lately I have been working on shutdown code. I still need to fix it so that if the XIM server dies and comes back only all input_context objects will be recreated automatically. Still working on other preedit types, only Root is working now. I am thinking now that IM callbacks should be handled with ecore_events instead of having to actually register callbacks. -Stafford On Sat, 3 Nov 2007 13:00:13 +0900 Stafford Horne [EMAIL PROTECTED] wrote: Hi All, Just want to let you know that I got the first steps of ecore XIM integration done and basic functionality is working. Attached is a diff for ecore_x and a small sample application. Currently there is only one extra method needed to be called to add an input_context to your window. The method takes one argument which should be the type for preedit style (OverTheSpot, OnTheSpot, Root, Callbacks, etc.) but only Root works for now. void ecore_x_window_input_method_init(const char *input_style); Please, if someone can just check my approach and api and give comments I will be happy. I have a few ideas for how to handle setting up position callbacks, rendering callbacks and other things, but ill try to catch up in IRC later. -Stafford - 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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
Re: [E-devel] Ecore + XIM working
Hello, It seems my original patch did not go out. The files are here: http://www.shorne-pla.net/uploads/ecore_xim.diff http://www.shorne-pla.net/uploads/xim_ecore.c New function ecore_x_window_input_context_init(win, Root); Lately I have been working on shutdown code. I still need to fix it so that if the XIM server dies and comes back only all input_context objects will be recreated automatically. Still working on other preedit types, only Root is working now. I am thinking now that IM callbacks should be handled with ecore_events instead of having to actually register callbacks. -Stafford On Sat, 3 Nov 2007 13:00:13 +0900 Stafford Horne [EMAIL PROTECTED] wrote: Hi All, Just want to let you know that I got the first steps of ecore XIM integration done and basic functionality is working. Attached is a diff for ecore_x and a small sample application. Currently there is only one extra method needed to be called to add an input_context to your window. The method takes one argument which should be the type for preedit style (OverTheSpot, OnTheSpot, Root, Callbacks, etc.) but only Root works for now. void ecore_x_window_input_method_init(const char *input_style); Please, if someone can just check my approach and api and give comments I will be happy. I have a few ideas for how to handle setting up position callbacks, rendering callbacks and other things, but ill try to catch up in IRC later. -Stafford - 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
