Gustavo wrote: > >>>>> >>>> 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. >>> >>> >>> >>> >> I haven't been trying to 'push' any particular approach.. just pointing out >> a simple >> one that can be realized now if desired. And frankly, I'm not sure I'd >> bother to >> work it out given your attitude on it. I sure as hell don't need it for >> anything. >> > > Hey Jose, don't take this personally. Everybody tries to push their > own point of view everywhere, it's not something bad. You were trying > to push transforms that way you said, I liked the idea but thought it > would never happened, you proved me wrong and showed your code. Again, > I like this idea but don't see it happening, prove me wrong again! :-) > > >
I'm not trying to 'push' anything into evas.. never have. I've never even wanted cvs/svn access. I do have my views as to what I think is a 'good idea' and conversely, but I prefer to make the reasons for those views open for discussion and let people see if they want it, and leave it up to Carsten to make the choice - for evas' better or worse, that's what I've decide is best for *my* interaction with this project. You see Gustavo, if I really personally *want* something in evas or whatever else, I can just do it myself, my system - I don't need someone to do it for me.. and very rarely do I suggest stuff here that I haven't already done in some form or another. >>>> 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. >>> >>> >>> >> No. This has nothing to do with enesim or any other immediate-mode >> rendering >> lib. It's about evas providing an extension mechanism of some sort - and >> here >> in particular it's about a simple mechanism that imposes no policy on the >> implementations. >> > > As we already have an extension mechanism called smart, I'm sure > you're talking about objects that draw new primitives. If so, don't > play the fool, we know that for that we need to expose somehow the > drawing primitives and in that case a 'immediate rendering api". > > You don't *need* to expose any drawing primitives - that's a fairly advanced way that would be useful, ie. expose an abstract api, but it's not needed. You could draw via whatever methods you feel like using as best suits you and/or the object in question. For example, a cairo object would use (guess)... an svg obj could use librsvg (via cairo say), an ogre3d obj would use.... etc. They may or may not be supported by all engines - that would depend on how one would want the semantics of extensions. The point isn't to provide an abstract immediate mode gfx api, but to have evas enable some mechanism for extending object types that can use other libs, other routines, your own methods, some methods already in evas but used to create different kinds of renderable objs (text-block and text-grid are examples), whatever. For this to be efficient, you need to get close-in to evas internals if need be - even if the actual implementation details may vary, one still needs the exposed aspects of the mechanism. As far as edje/edc extensibility goes.. that too can be done, you just have to think about it a bit. If you want though, you can see it akin to what you might do if instaed of edc you had xml. But all of this is mute if people don't see it as a primary method around which to build stuff - hence the need to expose the concepts and see if there's enough awareness and desire to want to do so. If not, then leave things be. > >> As to 'hints' for objects to render outside their bounding box, if what you >> mean is for objects to draw outside their given rectangular description, >> then >> that's trivial to realize. No need for hints, the evas api just needs to >> expose >> getting an obj's canvas bounding rect (not its 'geometry'), and internally a >> new >> cur/prev extents state kept in the generic obj def. This is all fairly >> trivival >> and has been worked out.. one needs it for things like transformed objs, for >> thick stroked lines, etc. It's not particularly relevant here. >> > > so good. > > > >>> 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). >>> >>> >>> >> And so it shall remain. Do what you want. >> > > again, don't take it personally... you're too dramatic these days. Be happy! > > Best regards, > > No drama. I just don't feel like wasting my time here. Think, and do things right. ____________________________________________________________ Are you safe? Click for quotes on a home security system. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3ni3c2GWgkMwjCb9fo4fZUJ0NauXSwlliqsUU4Ikj5aNqHUI/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
