On Thu, Sep 06, 2007 at 09:08:34AM -0300, Gustavo Sverzut Barbieri wrote:
> On 9/6/07, Youness Alaoui <[EMAIL PROTECTED]> wrote:
> > 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
> >
> > 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).
>
> So, both things makes sense, but I'll write basic x_cursor functions
> before I add that one back.
>
> Just one thing still pending: Will we create an XCursor class that
> wraps the opaque pointer Ecore_X_Cursor and provide utility methods or
> will we keep using integers and pass them around?
> IMO the former is better, avoiding errors and typing less
> (self.something()), but do someone have some objection?
>
Yeah, I agree, it would be cleaner code to have an object for that, since it's
not related to the
EcoreEvas..
The question would need to be asked for Ecore_X_Window rather than
Ecore_X_Cursor, since
the X_Window is an attribute of the EcoreEvas (while the cursor is not).
I think it will depend on the amount of functions needed and what they do (like
the cursor_set). I
would rather see it like :
cursor = ecore.x.Cursor.shape_get(ecoe.x.Cursor.ARROW)
ecore_evas.cursor_set(cursor)
rather than :
cursor = ecore.x.Cursor.shape_get(ecoe.x.Cursor.ARROW)
win = ecore_evas.window
win.cursor_set(cursor)
But as I said, it will depend on the amount of functions, if there are 100
functions for the
Ecore_X_Window, it could just 'spam' the ecoreEvas, so using a separate class
would be better for
keeping the EcoreEvas code clean. If it's only a few functions, then maybe
putting the functions in
EcoreEvas would make the API easier to use.
What do you think ?
>
> > > 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
>
> it adds unnecessary bloat: bigger binaries, more function calls, ...
> For this specific widget it probably won't matter that much, but let's
> try to keep it as good as possible :-)
>
Agreed
KaKaRoTo
-------------------------------------------------------------------------
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
