On Thu, 27 Oct 2005 00:25:12 +0900 Carsten writes:
> OK everyone - developer beings and such.
>
> as was brought up on the mailing lists several months ago,
> i have (FINALLY!) started some work on cleaning/rationalising
> and improving eva's smart object code and interfaces.
And there is much rejoicing! :)
> my first step is to move smart object child objects within
> the smart object itself - making the object struct less flat and
> more tree-like. this shoudl mean some speedups too.
Yes. Also, though not smart-obj related -- since clip-objs
should have only *one* clipee, it would make sense to let a
clipped obj 'own' its clipper as well.. ie. remove clippers from
the layers as well.
Also not smart obj related, but a small, easy optimization
in most cases -- have an internal canvas render function of the
form:
Evas_List *_evas_render(Evas *evas, char return_updates);
so that the api's render function which *does not* return updates,
can be defined via the above -- with 'return_updates' set to 0.
When this is 0-set, the _evas_render function can avoid creating
the list of rect updates (that the evas_render function can't
return anyway and just has to free).
> i also plan on removing the need for clip/unclip, show/hide
> and color_set methods so they are no longer used.
> that will be step 2.
And again there is much rejoicing! :)
I would suggest adding render-pre and post methods though,
as they could be very useful for more 'self-rendering' types of
smart objs. The obj's render-pre and post functions have to be
called anyway, just to recurse calling their childrens', so might
as well have user provided ones in addition...
Of course this could also cause all kinds of havoc... :(
> step 3 will be removal of evas_smart_new()
> in favor of using evas_smart_class_new() as it uses an extendible
> struct interface. i have marked methods for deletion for now too
> in that.
Well, this will go a loooong way to solve many of the major
problems with these :)
What about the event system?
> so... that means if you have made smart objects... you will need to
> do a little adapting soon. but in the long run it will make things
> much simpler, cleaner and more expandable.
Yes :)
> i am still tossing up if the smart move method should be there, or
> all child
> objects should be simply placed rlative to the smart parent's origin
> and thus
> moved automatically, or if i should provide a default move method
> that does
> this for you. right now its save from destruction - but i'm tossing
> up as to
> the future of it.
>
> another thing to go soon will be the old textblock api - consider it
> dead as of
> today, and only hanging in evas in cvs as long as i simply dont get
> around to
> removing it. if you are using textblock2 - it will be RENAMED to
> textblock once
> this happens. this will cause a short period of breakage as things
> move over,
> but then transition will be finished.
>
> so - be warned... :) and enjoy the newness! :)
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am"
> --------------
> The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
> 裸好多
> Tokyo, Japan (東京 日本)
>
>
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
