Re: [E-devel] E SVN: barbieri IN trunk/evas/src/lib: . canvas

[Gustavo S. B. <bar...@pr...>]

On Tue, Oct 28, 2008 at 6:05 AM, Jose Gonzalez <jos...@ju...> wrote:
>  Gustavo wrote:
>
>>>> This code is part of our effort to unify common code into base libs,
>>>> where its worth to avoid duplicating code over and over again.
>>>>
>>>> With that in Evas, we can now expose it in Edje and use it in Guarana
>>>> and Elementary and possible any other toolkit. It uses Evas_Object's
>>>> size hints infrastructure, but can be extended to have its own
>>>> properties if one wish.
>>>>
>>>> Attached is a test case and example. You can try to hack your own
>>>> fancy layout function, it's it's generic and useful to others, add it
>>>> to evas as well (Like layout using a Bezier or any other path).
>>>>
>>>> People implementing Ecore Evas can now use layout "stack" and
>>>> ecore_evas_object_associate() to provide the "main window" concept,
>>>> just add your background and then your object to the evas_object_box
>>>> and associate this box to the window. If you want your background to
>>>> scale in both directions, just set it's aligns to -1.0 and -1.0.
>>>>
>>>>
>>>>
>>>
>>>  This is the kind of thing that I hoped evas would avoid tending to, and
>>> yet both raster and gustavo seem prone to want to get into. :(
>>>  I know it's tempting to add more and more specialized layout/widgetry
>>> 'objects' to the core evas lib/api, but I think it's a big mistake for
>>> evas
>>> in the long run.
>>>
>>>  It's not hard to start extending evas *and* edje to allow for custom
>>> objects,
>>> even if at first all such object modules need to access evas internals.
>>> Adding
>>> these kinds of things, whether text-grid objs, or box objs, or table
>>> objs,
>>> etc..
>>> directly into the evas lib api is likely to become 'not a good idea'.
>>>
>>
>> this requires no access to internals, it's just a helper to avoid
>> spreading this code everywhere (e_box, guarana, elementary, etk...).
>>
>> the point is, raster always planned to have dynamic layout options in
>> Edje, so it's possible to specify in Edje if you want a stack,
>> vertical or horizontal layout and in code you add the objects. To add
>> this we need this kind of code. We could create yet another library
>> (like split esmart into edje independent and dependent code) and add
>> this there, make edje dependent on it, but it will be lot of work to
>> get a simple and useful code in.
>>
>> Since evas already have internal libs in it, at some point we can
>> create a libevas_utils and users can optionally link to it. That way
>> we keep things in a common place and avoid extra overhead.
>>
>> Our point is to do now what others should have done already: unify
>> stuff. Size hints, box, editable text block and these stuff should go
>> in Evas and make it easy to share stuff and easier to use EFL.  I
>> always hear, at least from ETK, that some things were re-done in ETK
>> just to work around some problems in Evas or Edje, I consider that
>> wrong, these stuff should be fixed there, and that's what we're doing.
>>
>>
>
>  Ok, let me pose this this from a different view.. let's not worry about
> whether
> or not such 'layout' or 'widgetry' or 'special-purpose' or whatever kinds of
> objects
> should be added to the evas lib *api* -- I don't think they should in some
> cases,
> but that's partly incidental here.
>
>  There will be a need for such kinds of objects, and others... things like
> custom
> self-rendered objs (possibly relying on other libs and apsects that those
> libs allow)
> that are best implemented at the 'evas level' for efficiency reasons and
> whatnot.
> It's just a matter of where their implementation should be, how to realize
> them..
> and how to expose their apis.
>
>  So, let's discuss the underlying issue that I think is what should be
> addressed
> here - namely, that of evas' "extensibility" at least as far as object types
> goes.
>
>  Would one want things like "object modules", or libs of them, for giving
> evas
> that kind of of flexibility and extensibility at a low enough level?
>
>  Well, one could certainly obtain the kinds of objs you want here, quite
> trivially
> really, and have them implemented by some lib.. even by edje itself say. And
> you
> could have things like a 'cairo' or an 'svg' object (which for certain
> engines
> could be done more 'directly' then via having these render to an argb
> buffer), and
> you could have say an 'ogre3d' object, or maybe a 'gstreamer' obj, or a
> video obj,
> or many, many things... and not have to worry about these being 'added' to
> the
> evas lib's api, or imposing a hard dependence on them by evas.. and yet,
> they can be
> implemented at the 'evas' level (possibly having them need access to evas
> internals
> at first, as I quickly outlined in an erlier email, and maybe further
> refined into
> a more abstract mechanism later if desired).
>
>  So, as a question: Would this kind of extensibility for evas be something
> desired?

of course yes

> What concrete things could you do with this?

with your approach, that you're trying to push for some time now, you
can do anything you want, so lots of stuff.


>  Is it a 'better' way to 'add' special/custom objs to evas then always
> worrying
> about whether or not to extend the evas lib's api with this or that 'one'
> useful obj?

yes, seems that we all know about that. BUT, nothing done. Enesim was
the way to go for that and is halted. All in all, we need manpower to
provide this extensible and very optimized immediate rendering api so
we can allow other things to render to Canvas, and we also need to
change the rendering pipeline, because we need more hints in the case
objects can render to outside their bounding box.


however I think you hijacked this thread :-P   While I think you have
a point with that, you have being pushing it for years, this tread was
about smart objects and with your api or not, this is still about
smart objects, not generally extending objects. As said by some, in
IRC or so, we could use a third party library (ie: split esmart in
edje-dependent and independent code).    I see in your other mail that
you worry about how to make this automatically exposed in Edje, just
like in any other system you need some kind of introspection, that's
simple, but needs time and nobody knows if it worth the pain (seems it
doesn't because nobody did it yet).

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: bar...@gm...
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202