On Wed, Jul 29, 2009 at 7:46 PM, Gustavo Sverzut
Barbieri<barbi...@profusion.mobi> wrote:
> Hello all,
>
> I'm planning to bootstrap the guarana + elementary merge* soon** but I
> want to solve an unsolved problem first: help bindings and users of
> evas_object_smart_callback*.
>
> If you're out of time to read it in detail, skip to end and read
> "Summary" at least.
>
> = Problem =
> Evas smart objects can emit signals with data, but these are
> free-form. Nobody knows which signals are emitted or which type of
> data they carry. This makes life of users harder since they have to
> grep for code or hope that there is documentation and it's up to date,
> which is quite hard we know. For bindings it's even worse, as we have
> to do it and write specific mappers for each signal, that's very
> boring and error prone.
>
> = Solution =
> I would like to avoid breaking current code, so changing things
> drastically is a no go. I could also propose a new system with signal
> inheritance and index access to speed up dispatching and all, but I
> guess the best is to build on top of existing stuff as it's "fine" for
> our use cases.
>
> The proposal is to add an array/list of signals-types to
> Evas_Smart_Class. This array would be defined when class is created
> and should not be changed afterwards. Types would be DBus-like type
> strings
> (http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures),
> for example "iis" is accessed as a struct with two leading integers32
> followed by a string.
>
> USERS: We could write a script to extract such information from C
> files and generate documentation.
>
> BINDINGS: On signal callback we just query Evas_Smart_Class from
> Evas_Object then type from it. With type we can query a hash that
> dispatch function for that type, converting native types to wrapped
> types.
>
> I don't plan to enforce checking on evas_object_smart_callback_call(),
> but that could be a compile/run time toggle to help spotting bugs.
>
> = Problems =
> - inheriting from another class would not automatically copy signals.
> This could be worked around with a new call
> "evas_smart_class_inherit_from()" that would copy all members and
> duplicate this array/list.
>
> - "generic" smart objects would not be able to cooperate with it. I
> clearly don't care much about this case as I find it abuse and not the
> best solution as it would make bindings nearly impossible to do
> efficiently. Unfortunately this is a real world case and raster likes
> it, current elementary is built just like that, with a single
> "elm_widget" class and all other widgets set hooks instead of
> inheriting. A possibly solution for it is to add extra pointer per
> Evas_Object_Smart with per-object signals. Then one could register
> signals per instance as well as per class. I dislike it though.
>
>
>
> = Summary =
> EVAS_SMART_CLASS_VERSION -> 4 (version++)
> struct Evas_Smart_Class: add
> const struct Evas_Smart_Callback { const char *name, const char
> *type; } *callbacks;
>
> // pseudo code:
> const char *evas_object_smart_callback_type_get(Evas_Object *o, const
> char *callback_name)
> {
> const struct Evas_Smart_Callback *cb;
>
> cb = _evas_object_smart_callback_get(o->instance_callbacks, callback_name);
> if (cb) return cb->type;
>
> const Evas_Smart *smart = evas_object_smart_smart_get(o);
> const Evas_Smart_Class *sc = evas_smart_class_get(smart);
> cb = _evas_object_smart_callback_get(sc->callbacks, callback_name);
> if (cb) return cb->type;
>
> error("no callback %s in object %p (%s) type %s\n", callback_name,
> o, o->name, smart->name);
> return NULL;
> }
>
> // pseudo code:
> Eina_Bool evas_smart_class_inherit(Evas_Smart_Class *dst, const
> Evas_Smart_Class *src)
> {
> if (!dst || !src) return 0;
> memcpy(dst, src, sizeof(Evas_Smart_Class));
> dst->callbacks = _evas_smart_class_callbacks_dup(src->callbacks);
> return 1;
> }
>
> we can add variants to add extra callbacks or even provide functions
> to just manipulate callbacks (join, copy) and let user handle it,
> like:
> my_sc->callbacks = evas_smart_callbacks_join(parent_sc->callbacks,
> my_sc_extra_callbacks);
I hate replying to myself, but I clearly missed an important thing
here: making the Evas_Smart_Class have a pointer to parent, that way
we basically solve the problem of copying callback definitions as we
can walk ->parent and check it there. It will also help calling the
parent methods, for example users of "clipped smart object" need to
call original "del" method and to do so it need to keep the copy of
the original method, this way we just sc->parent->del(o)
Of course it adds a bit of overhead of walking the hierarchy, but it
shouldn't matter much as it should not be that deep/long.
The inherit call could also take a "size" parameter allowing
extensions of Evas_Smart_Class to be inherited as well, for example:
evas_smart_class_inherit(child, parent, sizeof(*parent));
maybe this size could be inside parent itself, but I see this getting
out of sync easily.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
