From: <jos...@ju...> - 2008-02-16 06:40:54
|
> Another wrinkle is that we'd like to create a core library that is > only loosely tied to any specific underlying display system. We're > still in the process of abstracting the evas and edje specifics into > engines, and I don't want to add too many more direct dependencies. > This could be done as a library add-on to provide an ewl_evas widget > without breaking that abstraction. I That seems like a good way to do it. Note for example that Hisham did a similar thing in etk with an etk_cairo widget, something which you might also want to indulge in as well. :) I think Hisham's work on evolve is also very promising, and he's told me that he'd like to have it 'engine-based' so that it could be used for etk, ewl, raster-widgetry(?). BTW, as a distantly related aside here: The topic has often come up of buffered rendering in evas and of transforms for evas objs, it's something many people want.. and can be adadpted to includes gui- toolkit widgets and such. So, let me bring it up here a bit. In general, there are many 'kinds' of canvases - html ones, svg ones, mixed such ones, canvases of vgfx objects (like some cairo or qt based ones around), evas, edje (yes that can be considered one, just add a few move,resize,... api funcs to edje and you can forget that it comes from evas), and of course even ewl and etk and the like. Now, the thing about evas and edje is that they tend to want to restrict themselves to pixel-aligned objects (much like an html canvas). This makes it easy to deal with layout, alignement, and event handling. But people would like transformed objects, and fractionally positioned objects.. I spent some time looking into this, and discussed it somewhat with Carsten, and we both agree that it would be a 'bad' thing to add transforms to evas objects, per-se. It would create all sorts of issues and problems with semantics and layout/alignment and event handling and ghosts and monsters start to appear and whatnot. The best way (at least we feel so) to introduce such notions to evas objects (not only primitives like images, rects,... but also compound objs like edjes or just any smart-object) is indirectly via something much like a canvas-widget as we've been talking about here, though better to call it something like an "evas_drawing" object. Basically, one'd just add evas objects to this type of object, and set transforms on the so bound child obj of the drawing obj. This is actually fairly easy to do - for the primitive evas objects of rect, image, polys,.. all the needed gfx code is already there for it (see eg. some of Jorge's work in enesim for software versions). But for things like edje objects, or general smart-objects, or other drawing objects.. well, that requires being able to render to buffers in evas.. which itself is not that difficult to do (need code for the gl engine, but all the others are fairly straightforward). However, when you put all this together.. it becomes a massive re-write of much of evas' internals -- and that's what's blocking any work on evas to get these kinds of capabilities.. It's all there, but no one is sufficiently motivated to put that much time and effort to do the necessary re-write. I certainly find myself somewhat short of that at the moment. It may well be the case that it's better to just start from scratch with a new version of evas.. something based on a far more flexible canvas approach that would enable building not only evas, but also the various other kinds of canvases that people find of interest.. and again Jorge has done a large amount of work there, as part of his 'efl-research'. _____________________________________________________________ Click here to find the right stock, bonds, and mutual funds. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mJ0S2Z6jYgZqkPp5xP2BJX5hiezlA6aZWaMexYCeVky2wwo/ |