Gustavo Sverzut Barbieri 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,
If it's not broken, why fix it ?
current elementary is built just like that, with a single
> "elm_widget" class and all other widgets set hooks instead of
> inheriting.
Nice thing about current way is that it leaves one nice clean place for
tracking problems...rather than hunting down a bunch of inherit issues
which may not even be E(FL)'s fault....
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.
>
Agreed. Not liked too much....who/what defines the per-object ? One
object is diff from another how ? The current way, everything is derived
from a single "object" (elm_wid, etc) ...
Is this about being "nicer" to "other languages" ? OR is there a
benchmark that says "this is the better way" ??
Politely,
dh
>
>
> = 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);
>
>
>
> = Notes =
> * merge: no, it's not a miracle and I don't suddenly have time to do
> it all, but I guess I can bootstrap it and have more people to do the
> conversion of remaining parts. I'll probably do the 1% of the work,
> but I guess it's the tricky part and rest is basically copy & paste,
> sed, etc.
> ** no deadlines yet, but I'll do my best.
>
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
