List-reply...
----- Forwarded message from Youness Alaoui <[EMAIL PROTECTED]> -----
From: Youness Alaoui <[EMAIL PROTECTED]>
To: Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>
Subject: Re: [E-devel] python-ecore and etk patches
On Thu, Sep 06, 2007 at 01:41:21AM -0300, Gustavo Sverzut Barbieri wrote:
> On 9/6/07, Youness Alaoui <[EMAIL PROTECTED]> wrote:
> > Hi,
> > Attached are two files, the ecore.evas.c_ecore_evas_x_cursor.pxi which
> > should be 'cvs add'ed to
> > e17/proto/python-efl/python-ecore/ecore/evas/
> > and the efl.patch which is a patch containing the following changes :
> > python-ecore.evas :
> > - Adds a method for setting the cursor of the window (using an
> > Ecore_X_Cursor, or a shape)
> > - Adds X_Cursor class containing the values of each cursor shape available
>
> Ok, check CVS. I've changed most of things, but the functionality is
> there, keep reporting (and sending patches!) required features.
>
> Changes:
> - created ecore.x module and constants are in its __init__.py, we
> really should write its implementation ;-).
> - created ecore.evas.BaseX11 to be the parent of all X11 related
> classes (SoftwareX11, SoftwareX11_16, XRenderX11, GLX11) and just
> expose x_window_cursor_shape_set() (your cursor_set_shape()), since
> the other takes an integer, but it's actually an opaque data referring
> to X internals, not an enum or random integer. It could be exposed in
> our ecore.x implementation.
>
Ok, cool! I started by writing a X_Window module for all the functions that use
an X_Window, then the
same for X_Cursor, but I got lost with the huge list of functions in Ecore_X.h
(+I barely started
learning python, so I didn't want to go too deep in there).
About removing the x_window_cursor_set, I know it's an ID for a cursor, but I
still need it, the reason
is because when we get an ETK_POINTER_NONE, we should remove our custom cursor,
and the only way
(afaik) is to do a ecore_x_window_cursor_set(win, 0); if I send 0 to the
shape_set method, then it will
use the cursor with the shape 0, which is the ECORE_X_CURSOR_X (an 'x' shaped
cursor).. and if I use
the 'ECORE_X_CURSOR_ARROW' pointer from the ECORE_X_CURSOR_* defines, I'll get
a cursor different
from the one set by my theme. Also, this method will be useful later when we
implement the
ecore_x_cursor_new method which return an Ecore_X_Cursor (and not a shape
number).
>
> > The cursor_set_shape and cursor_set_x_cursor functions depend on the
> > window_get property of the
> > derived classes, so it should work with the available classes apart from
> > the ecore.evas.FB one
> > which doesn't implement it (but the FB one doesn't even seem to work). I
> > don't know how to check for
> > the existence of that property...
> > These functions are necessary for the use of Etk_Embed widgets, since we
> > need to register a callback
> > for changing the cursor manually (for entries for example).
> >
> > The second changes in that patch are for Etk, it does a few things...
> > - Removed etk_combobox_entry_popup_feed from the header since the function
> > seems non-existent
> > - Added etk_embed_new_from_ecore_evas to create the Etk_Embed directly from
> > the Ecore_Evas, and no need
> > for the user to implement and manually set the position_method and the
> > pointer_method.
> > - Adds a second embed window to the etk_test_embed because I found some
> > bugs that only happen when
> > you have several embed widgets in the same Evas.
> > - Fixes the bug with multiple Etk_Embed in the same Evas, the widget gets
> > the focus internally,
> > but never requests it to the Evas, so the Evas keeps sending the keyboard
> > events to the same
> > Evas_Object.
> > - Fixes the bug with multiple Etk_Embed in the same Evas, when we loose the
> > focus because another
> > Evas_Object received it, we must unfocus the currently focused widget in
> > our Etk_Embed.
> >
> > The last three fixes were already sent to CodeWarrior by mail, but I don't
> > know if he got them into CVS
> > yet, so I'm sending them again (since 'cvs diff' says they're not).
>
> I've not checked it carefully because I don't feel comfortable to
> commit to ETK's base yet, but somethings come to eyes:
>
no problem
> Etk_Widget *etk_embed_new_from_ecore_evas():
> + if (!embed) {
> + etk_embed_position_method_set(ETK_EMBED(embed),
> _etk_embed_ecore_evas_position_get, ecore_evas);
> + etk_embed_pointer_method_set(ETK_EMBED(embed),
> _etk_embed_ecore_evas_pointer_set, ecore_evas);
> + }
>
> weird, shouldn't it be "if (embed)"? If not, then why use ETK_EMBED(embed)?
>
oups sorry, You're probably right.. I should have specified that I didn't test
that patch, sorry about
that :s
I'll probably test it and send another patch (if necessary) once I create the
python bindings for the
etk_embed_new_from_ecore_evas in python-etk
> Also, please define these static callbacks
> (_etk_embed_ecore_evas_position_get,
> _etk_embed_ecore_evas_pointer_set) before this function and remove the
> prototype declaration, it's just bad coding habit: functions must be
> declared first and near it's usage (if possible).
>
ok, I'll remember that
> libs/etk/src/lib/etk_embed.h:
> +#include <Ecore_X.h>
> +#include <Ecore_X_Cursor.h>
>
> remove those, newly added API don't require them, include in
> etk_embed.c instead.
>
>
> etk_widget.c:
> +/* Evas Callback: Called when the widget gets focused */
> +static void _etk_widget_focus_in_cb(void *data, Evas *evas,
> Evas_Object *object, void *event_info)
> +{
> + Etk_Widget *widget;
> +
> + if (!(widget = ETK_WIDGET(data)))
> + return;
> +}
>
> Am I missing something or is this totally useless?
>
no, it is totally useless, I just kept it to keep the symetry of having a
callback for the FOCUS_IN and
FOCUS_OUT
>
> + if (!(focused = etk_toplevel_focused_widget_get(widget->toplevel_parent)))
> + return;
> +
> + if (focused)
> + etk_widget_unfocus(focused);
>
> Ok, I really don't like this "attribution inside if-statement", but if
> you do, pay attention to the next block: "if (focused)" is useless,
> rewriting it to more elegant C:
>
> focused = etk_toplevel_focused_widget_get(widget->toplevel_parent);
> if (focused)
> etk_widget_unfocus(focused);
>
> easier to read, fewer lines and "more efficient" (actually the
> compiler would optimize that).
>
I agree, I just did it that way, because it was done that way in other parts of
ETK (copy pasted that
part). + the if (focused) is redundant here since we already checked that in
the if.
> Thanks, nice to see your patches! Keep them coming!
>
Thanks! I'll keep them coming ;)
And Thanks for applying my patches so fast :)
KaKaRoTo
> --
> Gustavo Sverzut Barbieri
> --------------------------------------
> Jabber: [EMAIL PROTECTED]
> MSN: [EMAIL PROTECTED]
> ICQ#: 17249123
> Skype: gsbarbieri
> Mobile: +55 (81) 9927 0010
----- End forwarded message -----
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
