On Thu, Feb 26, 2015 at 11:31 PM, jose_...@juno.com <jose_...@juno.com> wrote: >> On Thu, Feb 26, 2015 at 9:50 PM, jose_...@juno.com <jose_...@juno.com> wrote: >>> Hey Cedric, >>> >>> I have a question for you... :) >>> >>> What are you thinking of doing with the current evas rect, line, and >>> polygon objects? >> >> I am considering the idea of introducing an Evas_Object_Shape, or >> something close to that, and make those 3 objects just reuse that one >> with some inheritance and the Ector backend (When Ector will provide a >> proper GL backend and be fast enough to replace them of course). > > Ok, that seems reasonable. But there are a few things to consider... > If you do that, then why not also introduce the rest of the standard shape > related objs like polyline, ellipse, circle, path? And where will the > fill/stroke-paint > properties of shapes come from.. restrict to colors only?
So this is really not defined yet and I am still trying to figure out how I will implement that. Currently, the first issue is do we want to have an Eo object for Line and Poly. I see no benefit for it. Rectangle have a benefit has we can have a custom cutout logic. So I could implement Line and Poly just as a set of helper function on top of a Shape object. Also in my branch I have already started adding a set of simple helper (mostly following what the SVG specification says) for rectangle with rounded corner and circle. I kind of plan to expand that set of helper that generate path over time. This helper will work thanks to Eo on both Evas_VG_Shape, Ector_Renderer_Shape and an hypothetical Evas_Object_Shape. That should not be a big deal. For stroke and fill paint source, I am considering allowing the source to be any Evas_Object like we do for proxy. The main issue is that we don't provide an Evas_Object_Gradient this day anymore, so it kind of limit the usefulness of it. That's still something I don't really know (I guess I could reintroduce an Evas_Object_Gradient as I would have the necessary code in Ector, but not so sure about it). > Evas object resizing would also need to be done consistently on these, > last I recall it was somewhat inconsistent on the line and poly... I think we trigger an ERR if you do a resize on a poly this day. Line is I think defined as a resize of both end point. But sure that would have to be taken care of. -- Cedric BAIL ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
