On Thu, Jul 30, 2009 at 9:20 AM, Cedric BAIL<cedric.b...@free.fr> wrote:
> On Thu, Jul 30, 2009 at 1:58 PM, Gustavo Sverzut
> Barbieri<barbi...@profusion.mobi> wrote:
>> On Thu, Jul 30, 2009 at 6:28 AM, Cedric BAIL<cedric.b...@free.fr> wrote:
>>> Hi,
>>>
>>> On Thu, Jul 30, 2009 at 12:46 AM, Gustavo Sverzut
>>> Barbieri<barbi...@profusion.mobi> 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.
>
> Hum, I would have say an array, as we don't have key name in front of
> the value. Beside that, I know that currently, their is no easy way to
> generate an Eet_Node tree from an Eet_Data structure. This limite the
> automatic transformation from Eet_Data to Script object. But as I
> already did the other way around from Eet_Node to Eet_Data (meaning it
> is possible to generate Eet_Data from a Python object quite easily
> now), I plan to do this shortly as I need it (And it will clean
> Eet_Data internal in the mean time). So at some point, it will not be
> that much useless to have an Eet_Data/Python Object converter.
>
>> 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...
>
> Yep, definitively.
>
>> 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...
>
> That was my reason behind eet, having the possibility to name each
> chunk easily and with some meaning (it would ease the creation of
> binding, as we will have real object with propertie name). So yes, I
> like name, but I don't like the idea of a new "protocol" to parse. So
> I will disagree on putting a complex scheme like that. Or we ease
> EET_DATA use, with some tool that generate EET_DATA_DESCRIPTOR, or we
> go to the easy and small path of your first proposal. I prefer
> EET_DATA as it's really easy to use in C, and will be for script to.
> We just need an way to represent it in our documentation.
Hum, I dislike having to provide another file that generates another
one that is included by every class. We'll basically double the number
of files in Elementary, or triple if if you consider the generated.
But on the other hand this is technically good and if description is
simple, like Edje, we can even include it verbatim in documentation,
like:
callbacks {
callback {
name: "value-changed";
value: INT "old";
value: INT "new";
}
}
But again, it's getting too complex and I'd like to avoid if if possible.
> The drawback is that it would make Eet a strong dependency for Evas,
> not a big deal in my opinion.
this is not an issue, we can split descriptors out of eet, maybe move
it to eina or a new lib.
>> 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.
>
> A small hash table will do the trick and be fast enough, without
> consuming too much memory (as it is shared by all object from the same
> type if I understood correctly).
No, this is per instance object as it's the connections of that
instance. But it can be created/destroyed on demand and if we create a
small/regular hash we could know from number of know signals (of
class, the instance defined signals to help elm_widget are another
issue).
--
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
