Gustavo wrote:
>> It was more
>> about having all these things (including some older stuff) that
>> may or may not apply to this or that obj type, no way to know,
>> etc. Ideally a "pie in the sky" kind of thing would be an evas
>> based on an ecore_object 'object' system (with all the ecore gui
>> stuff, including ecore_evas, split off from an ecore base), and
>> similar utopian ideals. :)
>>
>
> I think that's overkill at this level. This is better if you take
> widgets and like, so can be done in an upper level like ETK or EWL do.
>
I'd have to disagree with this. Even if it's just for "toolkit"
use that one is concerned with, it would be very useful for some toolkits
to have evas objects as part of the same object system as the widgets,
some may even build the widgets by extending evas objects if they wished,
or extending the base object that evas objects also extend, etc. But just
in evas itself this would be extremely useful - many reasons for that.
> About this I'm particular biased _AGAINST_ ecore_object. It's better
> to rely on existing machinery, either "native" going C++ or
> Objective-C, or going with GObject or PyObject, saving efforts to
> create yet-another-poor-implemented object system in C.
>
>
Ok, now there you're going to have political as well as logical
'issues' with various people. :)
I think an ecore_object 'object' system upon which to build
things like evas,edje,toolkits,... would be very useful. Even if
you wanted to use gobject you could still have ecore_object built
on top of it, but then you might as well replace most of ecore with
glib and relatives... and this is going to be a 'political' issue
with some people here.
As far as using other higher-level libs, c++,obj-c,c#,java,...
well, I'm sure you'll have some nice debates with people as to why
and why-not one or the other. :)
>> Anyway... although I'm not sure just how 'important' it is
>> (in practice) to have object sizes cut down as much as you managed,
>> that's nice work anyhow! But yeah, some of it is a bit 'ugly'...
>> maybe leave those parts alone?
>>
>
> the importance is that, except by image data, that's what consume most
> of memory in EVAS. Also, making them smaller, consuming less cache
> lines, will make applications a bit faster when you're loading batches
> of them to RAM... the downside is that now comparisons will need to
> apply masks before comparisons and settings, making these a bit
> slower, however if you use multiple load/store of values in the same
> bitfields, they can be done in one step, so a bit faster.
> Also, one of the patches moved data that non-smart objects do NOT
> use, and these were confusing and wasting memory.
>
>
Some of it was nice, and the addition of the min/max values
for layers was a *very* good idea (actually, something like that might
be good for limits to coords and size values as well). But some of
the others may just be more of a pain to deal with than any 'real' gains
for practical use (that means run-time and develop-time), it depends.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
