Re: [E-devel] Ewl and Edje
Does ewl have something like a canvas widget that one can add evas objects to? Not atm. That seems to me like it might be a BIG problem for any sufficiently flexible use of ewl and evas. :( Until a more generic solution presents itself, why not have a separate Ewl_Evas lib, with say a 'ewl_evas' widget, that has a function to get an underlying evas..? _ Click here for financial aid options. Quick and Easy. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oIGkNxoRjRxe4thXzy5MRk0x8J6Q6n8cIKpq1vVMPQTRjgE/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
On Fri, Feb 15, 2008 at 2:01 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: That seems to me like it might be a BIG problem for any sufficiently flexible use of ewl and evas. :( Until a more generic solution presents itself, why not have a separate Ewl_Evas lib, with say a 'ewl_evas' widget, that has a function to get an underlying evas..? Getting to the evas is not a problem: embed = ewl_embed_widget_find(some_widget_on_my_evas); evas = embed-canvas; /* Should probably write a _get for this as we have a _set */ The problem comes down to the event dispatching, since EWL marshals it's own events (for a variety of reasons). We would still need a way to feed event dispatching into Evas for a sub-tree of the objects on the Evas. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
Until a more generic solution presents itself, why not have a separate Ewl_Evas lib, with say a 'ewl_evas' widget, that has a function to get an underlying evas..? Getting to the evas is not a problem: embed = ewl_embed_widget_find(some_widget_on_my_evas); evas = embed-canvas; /* Should probably write a _get for this as we have a _set */ The problem comes down to the event dispatching, since EWL marshals it's own events (for a variety of reasons). We would still need a way to feed event dispatching into Evas for a sub-tree of the objects on the Evas. Umm... It still sems to me like you'd want some kind of canvas widget to which one could add arbitrary evas objects to, directly or indirectly (I believe that etk has something like that), in order to have a more flexible evas objs in a ewl app system, and just feed ewl events on that canvas widget to the underlying evas..? But as far as the particular events issue you bring up, maybe you could write up a preliminary evas patch with the changes/additions you feel are needed.. and battle it out with raster if need be. :) _ Click to get information on how to convert your home equity into cash with a reverse mortgage. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mI5r1fcZsC2CxSOZLFsNLviDuKojDR5z76gSgJXAG11o3gs/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
On Fri, Feb 15, 2008 at 3:50 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Umm... It still sems to me like you'd want some kind of canvas widget to which one could add arbitrary evas objects to, directly or indirectly (I believe that etk has something like that), in order to have a more flexible evas objs in a ewl app system, and just feed ewl events on that canvas widget to the underlying evas..? The idea of a canvas has been under consideration for a while, but has been lower priority than other things that still need work. Through what mechanism are you proposing we build the canvas widget? It could be a buffer evas as we already have a pretty good wrapper around that, but the levels of indirection are additional overhead (maybe a reasonable amount). That would solve the problem of feeding events since they could go directly through the global evas event API. I'd prefer to have a sub-canvas abstraction around the windows existing evas, which we can clip to the region of the canvas widget. But as far as the particular events issue you bring up, maybe you could write up a preliminary evas patch with the changes/additions you feel are needed.. and battle it out with raster if need be. :) I'm not sure if you've noticed my commit level lately, but it hasn't been what I would call active. I'll look at this if have a chunk of time to commit to it, but I'm hoping someone with an itch to scratch will beat me to it. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
Umm... It still sems to me like you'd want some kind of canvas widget to which one could add arbitrary evas objects to, directly or indirectly (I believe that etk has something like that), in order to have a more flexible evas objs in a ewl app system, and just feed ewl events on that canvas widget to the underlying evas.. The idea of a canvas has been under consideration for a while, but has been lower priority than other things that still need work. Through what mechanism are you proposing we build the canvas widget? It could be a buffer evas as we already have a pretty good wrapper around that, but the levels of indirection are additional overhead (maybe a reasonable amount). That would solve the problem of feeding events since they could go directly through the global evas event API I'd prefer to have a sub-canvas abstraction around the windows existing evas, which we can clip to the region of the canvas widget. Good questions.. Don't know. A buffer canvas would be nice to have for several reasons, but as you mention it may not be the best way to realize a canvas widget for other reasons.. it also depends on the semantic notions of child widgets vs sub-canvases. I think etk takes a canvas widget as just a region of the underlying canvas of the parent widget, and just feeds the events to that evas. But as far as the particular events issue you bring up, maybe you could write up a preliminary evas patch with the changes/ additions you feel are needed.. and battle it out with raster if need be. :) I'm not sure if you've noticed my commit level lately, but it hasn't been what I would call active. I'll look at this if have a chunk It's been better than mine.. of time to commit to it, but I'm hoping someone with an itch to scratch will beat me to it. My itching has calmed down quite a bit over time since it often feels like too much of a battle here in E land.. I'd hoped to see some of the things Carsten mentioned he'd like to engage edevelopers in - meets, discussions, coordination in plans, maybe some hackfests, etc.. but it seems that kind of organization itself takes more time than anyone really has.. :( _ Music to your ears. Click now for great mp3 accessories! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oh9kw8rO5cy05pZf7Z6vqaNFwfzyTG45gGYhqutlSXvsQ44/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
On Fri, Feb 15, 2008 at 10:05 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Good questions.. Don't know. A buffer canvas would be nice to have for several reasons, but as you mention it may not be the best way to realize a canvas widget for other reasons.. it also depends on the semantic notions of child widgets vs sub-canvases. I think etk takes a canvas widget as just a region of the underlying canvas of the parent widget, and just feeds the events to that evas. 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 My itching has calmed down quite a bit over time since it often feels like too much of a battle here in E land.. I'd hoped to see some of the things Carsten mentioned he'd like to engage edevelopers in - meets, discussions, coordination in plans, maybe some hackfests, etc.. but it seems that kind of organization itself takes more time than anyone really has.. :( Yeah, unfortunately my participation at SCALE fell through. I'm not sure if raster made it, but it would be good to hear a trip report if he did. :-) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
On Feb 15, 2008, at 8:36 PM, Nathan Ingersoll wrote: snip Yeah, unfortunately my participation at SCALE fell through. I'm not sure if raster made it, but it would be good to hear a trip report if he did. :-) http://arstechnica.com/news.ars/post/20080211-the-enlightened-future-of-openmoko-linux-mobile-phones.html -Blake - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
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/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
The answer is yes and no. You can certainly do this simply by mapping the theme for a widget to your Edje. The problem is that any events will automatically have the source set as EWL instead of the clicked part. The problem is that we do dispatching to the widget inside of EWL, and w/o an API to feed these events to the specific evas object we just send a generic signal on the edje itself. So in order to do this effectively, the Evas API needs some expansion. On Thu, Feb 14, 2008 at 2:57 PM, Andreas Volz [EMAIL PROTECTED] wrote: Hello, I've seen the ewl_embdd_test example where a ewl widget is embedded in a evas/edje application. This is really great. But is it also possible to use a edje object in a ewl application? I've created some custom edje widgets and think about to use them in a ewl application. regards Andreas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
Nathan wrote: The answer is yes and no. You can certainly do this simply by mapping the theme for a widget to your Edje. The problem is that Is mapping the theme for a widget to your Edje a standard, well-known thing to do in ewl? Is that the same as using one's own edj file to define a custom theme for a ewl widget? any events will automatically have the source set as EWL instead of the clicked part. The problem is that we do dispatching to the widget inside of EWL, and w/o an API to feed these events to the specific evas object we just send a generic signal on the edje itself. So in order to do this effectively, the Evas API needs some expansion. Ahhh... that's why you've proposed that before. Is that problem there with the use an edje object in a ewl application part of andreas' question? Does ewl have something like a canvas widget that one can add evas objects to? _ Be your own boss today! Easy Fitness Franchises. Click here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oKH5OGow0dSdMSdTwCMauC41N5lSLnH4GNOC2r15ZPXSA5q/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ewl and Edje
On Fri, Feb 15, 2008 at 12:18 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Nathan wrote: The answer is yes and no. You can certainly do this simply by mapping the theme for a widget to your Edje. The problem is that Is mapping the theme for a widget to your Edje a standard, well-known thing to do in ewl? Is that the same as using one's own edj file to define a custom theme for a ewl widget? Yes, you can set the group name, the filename or both on a widget to map it to your custom Edje. any events will automatically have the source set as EWL instead of the clicked part. The problem is that we do dispatching to the widget inside of EWL, and w/o an API to feed these events to the specific evas object we just send a generic signal on the edje itself. So in order to do this effectively, the Evas API needs some expansion. Ahhh... that's why you've proposed that before. Is that problem there with the use an edje object in a ewl application part of andreas' question? If the edje object has any programs or complexities that require signals to come from varying parts within the edje, then it's a problem. Does ewl have something like a canvas widget that one can add evas objects to? Not atm. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
