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
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
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
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
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
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
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
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?
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
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:
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
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
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.
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
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
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
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
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
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
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.
20 matches
Mail list logo
