On Thu, Jul 30, 2009 at 6:28 AM, Cedric BAIL<[email protected]> wrote: > Hi, > > On Thu, Jul 30, 2009 at 12:46 AM, Gustavo Sverzut > Barbieri<[email protected]> wrote: >> = 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. > > Hum, why not EET_DATA for that ? We have EET_DATA_DESCRIPTOR for the > description. We should be able to generate from/to object script too. > >> USERS: We could write a script to extract such information from C >> files and generate documentation. > > I was thinking about this using EET_DATA_DESCRIPTOR, we should be able > to generate doc. Or we could do the other way around with a simplified > syntax, we could generate C file that provide EET_DATA_DESCRIPTOR > alongside with documentation (based on the same idea as bison, flex or > gperf). > > This way it would be easier to use EET_DATA for more thing like > network traffic (it's way faster to process eet_data than xml), IPC. > > What do you think about this addition to your proposal ? > > Note, that I like the idea you are proposing for some kind of object > inheritance with evas_smart, this would bring some usefull capability > to the EFL. And I would just use the ->parent mecanism for almost > every thing including signal inheritence.
Regarding EET_DATA, I did think about it as well, but I like the string types more for some reasons: - simpler to use inside evas, it's just a string. and unless we want to do debugging checks, we don't need to use it in fast paths so performance is not an issue here - simpler to use by scripts, just iterate a string and output list items. - simpler to use by bindings, EET_DATA is useless for Python, for example. I would like to use write some "common dispatchers" like _evas_smart_callback_dispatch_iis() and do the generic just if required, later. To do so with strings I just need to add a hash table. All in all they're almost the same thing and the result would be the same, but i think it's easier to do so using strings... I can see this getting cumbersome to create eet_data_descriptors and all for every single signal one may emit... My proposal lacks a "name" entry for each value, which EET_DATA provides... do you think it is important to be inside code? On one hand it would be good to have this information, but on the other it would make declaration more complex and parsing harder, if we keep these 2 separate (to make parsing simpler) we can easily get out of sync. Maybe a format like TYPE:NAME,TYPE:NAME.... like "i:old_value,i:new_value" would do, then in Evas_Smart we can split and keep just the types... Evas_Smart could contain other pre-processed data, such as sorted version of all known callback names inherited. This would enable instances to speed up signal dispatching. Instead of a single list with (callback_name, func, data) we would have an array/hash of (func,data) lists and could do binary search on it for quick finding the correct list of functions for that callback name. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
