While I'm carrying on with this nonsense here:
>
> Just to clarify this remark a bit.. All this really means, in this
> particular case of edje, is a means by which an edje object would setup,
> on each of its member parts, a function that would allow for changing
> the part description suitably to reflect the state of the member object..
> eg. if a member obj's color is changed (via the evas api), then it would
> call a color-inform kind of callback function which would end by basically
> saying: have the parent edje smart find the part description corresponding
> to that member obj (if possible) and change the color state there to be
> the member's current color -- ie. a method to edit *some* of the edje
> parts states via 'parent inform' kinds of callbacks. One could also
> possibly use it to override things.. and in general it could be used for
> many things.
> Anyway, not saying that would be useful or desirable.. just thought
> I'd mention it. :)
>
The main problem with this kind of thing is that's it's so
limited in scope and effect... eg. for the case I gave here of colors
one'd have no way to really take care of states.. and there's no way
at all to account for custom internal properties/states that the smart
data may have, etc.
____________________________________________________________
Click for free info on online masters degrees and make up to $150K/ year
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nNjc0eEJLpesZrqzlnROw2BthDAEVy9Zrq1yZUTwavZZ5iw/
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
