Re: [E-devel] EFL and Webkit
> > I have a question for you on this though: I imagined having > > 'native surface' image obj api given in each of the engine headers, > > but you added a generic evas api for it.. What exactly do you have > > in mind here? eg. say with gl-textures? > > literally evas exposing the engine drawing routines for that engine - > generalised tho. gl i would expose as a generic api from a evas-3d > lib on top of a native surface, but it would just abstrait to either > software mesa or direct hardware opengl, so it'd work in a software > canvas, just slowly. Ummm I'm not sure I follow you here at all. What you've mentioned above seems far more reaching - not quite just dealing with implementing image obj 'native surfaces', which is what I was wondering about here. Maybe the other engine-ers (Cedric, Vincent, Gustavo) can give their own views here as well, but let me just be a bit more specific as to how I'd imagined this and see if it makes sense. By 'native surfaces' I'd meant things like xrender pictures, gl textures (maybe pbuffers), sdl surfaces, etc. So, more like engine- renderer specific 'buffer surfaces'. One'd then have get/set functions for image objs of 'similar' evas engines (xrender-x11, gl-x11,...), along with various specialty funcs to query whatever extra stuff specific such 'surfaces' might have (eg. wether a gl texture is an nv-rect, its actual size, etc). Ideally, there would also be given a means to convert such surfaces to argb data (wether exposed or just internal). I'd imagined these funcs in each engine header, nothing at all in the general evas api, and one would implement the funcs in the engine modules, likely via the use of a new 'object function' to get an evas object's 'engine_data'. Or at least, that's more or less what I envisioned for these. Then go from there and build things like an evas-3D lib if desired.. possibly dependent on gl but able to render to any evas by say rendering to a gl buffer and getting argb data if need be, or some other way.. But what I was curious about was what exactly you had in mind with your: typedef struct _Evas_Native_Surface Evas_Native_Surface; /**< A generic datatype for engine specific native surface information */ EAPI void evas_object_image_native_surface_set(Evas_Object *obj, Evas_Native_Surface *surf); EAPI Evas_Native_Surface * evas_object_image_native_surface_get(Evas_Object *obj); _ Can't pay your bills? Click here to learn about filing for bankruptcy. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nfvZ1HP2N7idMqB8psDhtwnNzca8Owk4iEEfc4EysHx9ahK/ - 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] Evas Object Size Hints
> > Also, how can one 'set' an object's min/max size? Wouldn't > > these be intrinsic to the object? > > for other objects it may or may not be, but thats why set() > calls exist - to set it. Makes no sense to me, nor for the 'request' one either if that means something like 'natural' size, but hey it's all mojo anyway... :) _ Click to find out what your future holds. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3lzGqPTh7dbcivddZSHblEhI9twEktKifb3nStGRAqsWHyTu/ - 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] Evas Object Size Hints
Also, how can one 'set' an object's min/max size? Wouldn't these be intrinsic to the object? _ A cleaner home is just a click away. Click now for great housekeeping services! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nkMTls1hPsF4suhS7TfEIjnGT9vA2SjBTqaJGcLjhk3LwXO/ - 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] Evas Object Size Hints
Gustavo wrote: > We were discussing about this idea at IRC and the summary is > written at: > >http://wiki.enlightenment.org/index.php/Evas_Object_Size_Hints > > Idea is to move this common requirement to Evas_Object so it can be > shared by toolkits, Edje and even the layout smart objects I plan > to add someday in future. Adding this is pretty straightforward and > I should do it soon, next moving Edje to use it. > > Any comments on that? Requirements we failed to notice? Better > functions/types names? They seem fine to me - it's a good idea, even if some objects may want to be stubborn about this stuff sometimes. One question though: is there such a thing as a 'natural size' notion used by people? _ Paralegal Scholarship - Click Now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oIChxuBcHnXgib3G4TAEvKUa7mtZgiBqrthQTMRmR5HQrc0/ - 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] EFL and Webkit
Carsten wrote: > ... what would be the right way would be to allow new extended > objects (smart objects) to set rendering calls - the same way > evas internal objects do, and then do their own rendering. > breaking this out to a nice public api would be really nice and > allow for objects built on a non-stateful (immediate mode) > rendering model to exist and be efficient without HAVING to render > to a buffer. this would mean breaking out the engine drawing calls > and surface creation/destruction etc. into evas api. Yeah, would be good to have. But just getting render-pre/post funcs for smarts, and implementing 'native surfaces' would be very desirable as well, since buffered drawing is *very* useful for many things. It's also easier to do, and needed in order to have engine- specific sub-canvases. Either way, this would allow for engine-specific extensions for evas.. wrapping things adequately would allow for things like say an "evas3D" lib if really desired. I have a question for you on this though: I imagined having 'native surface' image obj api given in each of the engine headers, but you added a generic evas api for it.. What exactly do you have in mind here? eg. say with gl-textures? There must be plenty of gl addicts out there who would love to start doing their rtt 3D stuff with a gl-x11-evas. :) _ Be your own boss today! Easy startup businesses. Click here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l5i5ETtM15PrOl2jcouG108VB7tTMRbBeTCnS8KunaIB3Dq/ - 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] Google Summer of Code 2008
Gustavo wrote: > I agree with use case of fixed filters, actually the proposed > filters cover more than what I expect. What I disagree is > _having_ to implement a span of combinations in order to optimize > it for all engines, it will not worth the pain. Ok if one wants > to do that, but if we say such feature would just be accepted > if this is done we'll never have it. > If you like feel free to rephrase it on wiki. I actually agree with Gustavo here somewhat, and that's why I'm not sure if exposing a generic filters pipeline is the 'best' way to achieve things like transforms, reflections, blur, bumpmap... It's the requirement of chaining arbitrary numbers of these that creates difficulty, inefficiency, and is often just not that useful for most real-time gui use cases. Make it easy to do some very usefull, interesting things very well, and possible for people to do their own custom things -- hwd accel or not, shading language or not. Also, consider just how you're going to deal with things like image borders, with image fills, with compound objects, with 'custom' objects, with events, etc. And how you're going to expose any of these things in something like edje or whatever similar, deal with layouts, alignment, etc. _ Live your dreams. Click here to find information on becoming a lawyer. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oFGmtTsWdLM7EXhh9ojhGZopcus7flUVAOgaC2By5aithnK/ - 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] Google Summer of Code 2008
Gustavo wrote: > > > On 2/27/08, Vincent Torri <[EMAIL PROTECTED]> wrote: > > > > > > > > I think that we should add evas filters. It should be very > > > interresting for student (study of the internal behaviour of > > > evas, interresting algorithm to perfmorm different filters...). > > > Rotation, perspective, reflection can be a good beginning > > > and maybe add gradient clips, blur > > The fact that I added filter objects to Evas and not Enesim in wiki > added some discussion on IRC. I would like to have both Evas and > Enesim, because they have different constraints and time lines. > I just added Evas because I thought Jorge would add the enesim bits. > > Evas is there now and lots of code base on its current state. > I don't think we'll be able to rewrite Evas on top of Enesim before > getting E17 out doors. I say that because Evas already handle lots > of corner cases that any library that wants to replace it (including > its rewrite) would have to, don't ask me for these corner cases, > because these are the ones that you just remember when you reach > ... > > That said, I also think having both is no overlapping, adding filter > objects to Evas is trying to fit it in something have HUGE walls to > work around, you will not be able to do much, our work is to find out > the minimum set of changes to Evas to support the minimum of hardware > accelerated filters. Read the wiki, you'll see I'm not proposing a > general purpose filter solution, something that would work with > software, framebuffer and like, I just want something that will > enable us to use hardware acceleration if it is available. I'm not sure what "getting e17 out" or enesim have to do with the particulars of the evas filters/transforms proposals you added to the wiki. How much have you looked into this? You don't need OpenGL or "gallium3D" for any of the things mentioned above, and in fact it may well be about the same, or worse, in many circumstances to do things via those libs - even with decent drivers. Also, what you proposed was a very generic filter pipeline mechanism, which though nice in theory may well be fairly counter- productive or useless to have in practice for most cases that evas is applied to. You don't need to have a filter mechanism rivaling Photoshop built-in to evas, or requirements that there be "shaders" for it to work, and there are more aspects here than just being able to 'do the gfx', hardware accel or not. That said, I think it's great that you want to see things move forward and all... and who knows, maybe there's lot one can gain out of trying out your approach to this. In the end though, Carsten is the maintainer of both evas and edje, and something as large as this would be best discussed with him. - 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] Google Summer of Code 2008
Ravenlock wrote: > First, lets get in the correct mindset. We are not "asking people > to help with our E stuff". The goal of SoC is to help students > learn and to create more open source code. Google is not putting > up bounties for things *we* want done. Google is gonna pay a few > students to further their knowledge of Open Source in general, and > to get more code out in the wild. The ideas we suggest are just > that. Google, or anyone else for that matter, can't support every open source project or idea out there just for the sake of furthering that kind of selfless, indiscriminate goal. So, there must be criteria for why some particular projects or ideas are chosen over others. What is e, and why should they care? _ Save hundreds on getting a Web Design Degree. Click here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oHUFL6mPiDBhBx69lFRM2h01zHSjoqFhnnXSr1e5CAqcg3m/ - 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] Google Summer of Code 2008
Vincent wrote: > what i wanted, is a gui that is not like evince and use the power > of edje (see the wiki) > > With your reasonning, just gave up all the EFL, as they are libs > to write mainly gui. And a lot of tool already exist using gnome > or kde. Indeed, unless you can convincingly argue otherwise, I see little point in not going with one of those well-known, mature solutions. The "power of edje"? I gather you've done a lot of work with "edje". Tell me, how easy will it be to use this edje to develop and maintain the various kinds of apps that I might need? How many developer hours do you estimate it'll take to have something functionally equivalent to evince? Can you at least provide a mock-up of this edje-based version that's compellingly far more interesting in its gui? _ Click to learn how you can earn extra cash in day trading. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3noTBX0rcGKNE43MRPTCt3eGM4En4GdTFX1TTmcciR0quHLC/ - 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] Google Summer of Code 2008
Ravenlock wrote: > What has to happen is, we have to describe our ideas in terms > that non-E-devs can understand, and appreciate. (Nice work on this BTW) Ok, let's take a naive point of view - we're all now neophytes with no real knowledge of "e", and someone's asking you for help with their "e" stuff.. What would you say? If you really want anyone unfamiliar with "e" to even begin to care about "e", then maybe you'd need to start by answering some fundamental questions: What is "e", and why should I care about it? Look at sourceforge, freshmeat, and others such.. There are tens of thousands of foss projects out there - many of them quite interesting. Why "e"? A window manager? So what, there are tons of those already. What else? An app development framework? There are mature, full-featured ones already... ones that have produced thousands of apps. How does "e" compare to those other frameworks, and what apps has it managed to produce? Why is its framework, or the apps it allows, 'better' somehow? What's the 'Big Picture' of "e", and why should others care? Is "e" something like a "rich app development framework"? Does it support or work well with the web? Do you have a 'projects' page where I can see some of the things developed with this "e"? Why should 'we' care about "e"? _ Internet Security Software - Click here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mEWr9GJ2IW54dJDUXglcblyBmlNhB3fOPbQYfzRfCq6RfWQ/ - 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] Google Summer of Code 2008
Vincent wrote: > * writing an evince-like prog in full edje Why would anyone not familiar with "e" care about anything like this? There's already an evince. Why would a similar app, but with this "edje", be of any interest to anyone, or of interest enough that they'd pay someone to do it? _ Click here for free information on student financial aid. Quick and simple. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oIGktovcuGbsPi2iqQ79VKbu6TugaSobdHdsS4rhlY6IfIs/ - 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] e_module-notification installation location
> this would violate the principle of least surprise. Well said. U... then again, setting a size load option on an image and getting -- surprise! it may or may not be what you asked for! does seem to flaunt that excellent principle you want to adhere to. :) PS. Not to mention the various situations where it's hurting you efficiency wise - in both mem and performance. _ Find what you want and get it for less with an online auction. Click now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3n7Vg4peFzfZABnf0WEB9YUbScPl2JV6cogqskHyo7Fiq9Lq/ - 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] Imlib2: problems with HSV colors
> I replaced both functions as you suggested. No it looks a little > better but not much. > From my perspective the problem is that imlib2 stores color ranges > internally in rgb. In part.. As I mentioned, the use of the wrong scale was only part of the problem. The other part is that it's doing an initial interpolation in rgb color-space.. and that'll give incorrect results since hsv<->rgb are not linear conversions. Furthermore, it also does an initial hsv->rgb conversion to store the color range in rgb, as you mention, and that causes some further (small) inaccuracies (since the conversion hsv->rgb->hsv doesn't always give an identity). > Maybe a better solution is to calculate the hsv color by myself and > draw each line by myself. > Although it may be less efficient however in this case I have one > advantage to the imlib2 hsv color range function: > I will not loose information from back and forth converting between > colorspaces. That would be one way.. and actually you might get something which is even faster. You can also try and do something like in evas, where though the initial colors are input as argb, the actual interpolation is done completely in ahsv space. You can do even better in imlib2 by, as you mention, store the color range as ahsv values, and then proceed as mentioned, thus avoiding any conversions to begin with. So, if you have some time you could try and work out a patch for imlib2 that would do this. _ Click for free info on online masters degrees and make up to $150K/ year http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nNjdFYdDR3fGPlZCD0wMLqBR5Prep3GzTlswkYigkTWnJcE/ - 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] Google Summer of Code 2008
Ian wrote: > Alright I've taken this summer of code research a bit further > apparently we're not blacklisted in anyway. The reason we were not > accepted last year is that our application was a bit suboptimal > and the ideas list was poor we didn't elaborate enough on the > ideas what they were. It wasn't clear enough to an e outsider what > we needed to get done. so they said to reapply this year and > improve it. So from this point forward I'm willing to do what > it takes to get enlightenment into SOC this year but of course > I'll need commitment and help. I'm willing to help be an admin > but we need people who're willing to mentor and we need the > ideas to be explained clearly on the wiki. Make it so that someone > who has never heard of e can look at them and understand what we > need the different things for. All I mentioned are simply things I blieve would be useful for E to have, SoC or not. I could give detailed explanations of what I mentioned.. but these things might not be what others believe would be good to have, specially things related to specific E-projects (which are?). It would be up to the individual project leaders to come up with their own detailed descriptions of specific proposals they feel would be good for their projects. So far, only Michael from eterm has done something like that, but it's still early and many things need to be thought about first before people can come up with proposals. _ Click to make millions by owning your own franchise. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m6iRdMIqwDoRmKnxSepEMMLAVxYenmEFXGkOa8QZaPuoD1W/ - 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] Google Summer of Code 2008
Ok, here are just a few 'ideas' that I think would be nice, not necessarily anything to do with SoC, just a few things I think e could benefit from (merely from my own viewpoint). 1. Further work on an immediate-mode gfx lib like enesim, and also on a generic canvas framework as in jorge's further work. 2. I'll stay away from suggesting multitudes of stuff for evas, and just give one: Implement 'native surfaces' for image objects - at least for gl texture, sdl surfaces, and xrender pictures. Extend ecore's sub-canvas stuff to use such surfaces for the corresponding engines (gl, sdl, xrender). Similarly for any other engines/native surfaces that people may want (dfb, win32, cairo). 3. If people here must use 'edc' syntax, then have a stand-alone generic parsing lib for the syntax. 4. Further develop embryo scripting, and/or add support for other well-known scripting languages to edje/edc (javascript, python, lua, ...). 5. Develop a time-line based animation api for ecore, ewl, and etk. Also, further general work on ewl and etk, and similarly more attention to the excellent edje-editor and evolve projects. 6. Create a lib of "themable evas objects", with a well-known collection of such including things like 'widgets' and 'gadgets', and a mechanism for loading/using other such. 7. Develop ways to make "E" more web-connected and supportive of web related stuff. It's a shame that the enlightenment site can't show off anything it's developed directly over the wire. There are other things, but all these are few that are doable, possibly useful, and not too far from what's already there (except perhaps 7, which is a somewhat fuzzy goal). _ Click here for great computer networking solutions! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oHgMmgMnPCdbmAGKrCzEjB6YonpGtBFr44mGxSzdHu8yPX6/ - 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] Google Summer of Code 2008
> Recording them into wiki.enlightenment.org would probably be the > best bet. A much more stable and easy to use record then the > mailing list. BTW, wouldn't it be a good idea to have a link to the wiki from the main enlightenment.org site? I had no idea how to find that and had to start clicking away at all the existing header links there. Also, maybe also a "projects" link, which would list any projects that people may want to have some site setup for (eg. eterm, entrance, ewl, etk, edje-editor, your-nice-app-or-lib-site,...). So, maybe add two more main links, left and right, for "wiki" and "projects"? A link to "themes/art" sites like get-e.org and e17-stuff.org wouldn't hurt either. _ Save hundreds on getting a Web Design Degree. Click here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oHUE03S3OaJ9NbYm7LPM7QnXr2UPm4cT7tQHlnmK9KeSgtC/ - 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] Google Summer of Code 2008
Vincent wrote: > > I think that we should add evas filters. It should be very > > interresting for student (study of the internal behaviour of evas, > > interresting algorithm to perfmorm different filters...). > > Rotation, perspective, reflection can be a good beginning and > > maybe add gradient clips, blur Indeed, those things would be interesting objects of study for those leaning to gfx stuff. In practice, we already have fast software implementations of all those things, and there are plenty of gl based methods out there for these as well (though a generic shading-language like approach could be very good here, regardless of the backend). > actually, there is already a mention about evas filters in the wiki. > But maybe we should be a bit more precise on which filters we would > like > > That makes me think that we must add turran's work Absolutely. But there are certain obstacles to be overcome. Jorge's work on enesim and other of his efl-research work are still in flux and early development.. he needs help with those. Anyone interested in gfx and wanting to give a hand should contact him about things. But assuming all that is done.. there are even bigger issues to deal with regarding evas itself. First of all, there's the question of just HOW to 'add' such capabilities (filters, transforms, whatnot) to evas... not how to implement the underlying gfx algos, we know how to do that.. but how to expose these capabilities thru the api in a way that makes sense for evas and edje say. If you want an analogy here, think of html and assume you've got this nifty idea of adding filters/transforms to image tags, maybe just via css styling, or that you want to add vgfx elements.. How are you going to make this work? Well, that's kind of the problem here with evas and edje. Secondly, again assuming you've now got that worked out, you then have facing you the realities of evas' current internals to work with.. and there you have some real headaches to deal with. In particular, the way that image stuff is dealt with internally, and the way the engines are used by the api. These things mean a fairly large re-write of evas internals, stuff has been shoved-in again and again without taking the time to redo internals when it would've been easier to do so. Now, it's a large, messy bit of work that needs redoing.. work that's not easy to follow for anyone but the persons who wrote the initial code -- It's always much easier to understand one's own convoluted mess than someone else's clear organized stuff.. and much, much more difficult to follow someone else's not-so-clear stuff. Wether it gets done or not, there's a lesson here for people to keep in mind as they develop stuff in e-land. _ Make up to $100/hour by getting a degree in Web Design. Click Now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oHUEnY1AXtj4nEATvMInnIAsEfechiubYcUh7COaDvsWRzq/ - 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] Google Summer of Code 2008
> > Recording them into wiki.enlightenment.org would probably be the > > best bet. A much more stable and easy to use record then the > > mailing list. > > Eventually, yes. But initially, the list is a much, much > better forum for feedback and tossing around some general ideas.. > Let's not dampen public discussion of goals and ideas before they > even have a chance to get started. But yeah, definitely would be a terrific thing to have the stuff in the wiki as well.. Maybe do both so that at least for starters some initial ideas/goals get discussed. I found Michael's comments about eterm, for example, very interesting and informative. :) _ Hospitality Management - Get the career you've always wanted. Click Now. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oJdd01478NqBButcnVP6zoDxj8tw4zztHcPEkDKFF2V8G6k/ - 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] Imlib2: problems with HSV colors
> thanks for the tip will give it a try. But there is still > the issue that the function documentation is wrong. Therefore > It could be that the hsv_color_range function is expecting > different values. Ok, took a quick look, and... Yeah, that whole imlib2 grad implementation is screwed.. and you're right, part of the problem is that values are assumed to be in a different range scale than the usual (ie. what the docs state). Using the evas version of the hsv-to-rgb function will make things worse unless you also use the rgb-to-hsv version of that function. I suggest replacing both the rgb-to-hsv and hsv-to-rgb implementations in imlib2 with those used in evas and keep the documentation as is. Test it, and if that works for you then send it as a patch. :) _ Free comparison of top car rental companies. Click Here! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nMUoueJtZoo7GxUezgCVk2Tkm2r0Z4HCkdyh6h2J6CCdaWE/ - 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] Google Summer of Code 2008
> Recording them into wiki.enlightenment.org would probably be the > best bet. A much more stable and easy to use record then the > mailing list. Eventually, yes. But initially, the list is a much, much better forum for feedback and tossing around some general ideas.. Let's not dampen public discussion of goals and ideas before they even have a chance to get started. _ Click here to find great deals on vending machines. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oCSv53M7Uk6rCuiP3VF1GxNnWaK7RUZkri460IIfp7FR2sQ/ - 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] Google Summer of Code 2008
Jess wrote: > Is there a dedicated person we should send the email to? > Or just email the list? Sorry, not familiar with the etiquette here. For greater exposure, feedback, etc. the list here would clearly be best. This is something that people here have to build together. Build the goals, both short and long term, that its various projects see as interesting, make them visible as serious objectives people can work to contribute to. _ Have a nack for decorating? Click here to earn money from your passion. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oLOnsKY4a1ggzCGnW7OnSysyHbnAwxaPiLgXElcGXwSMsfG/ - 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] Google Summer of Code 2008
Michael wrote: > > about these suggestions, would it be interesting to add them in > > the trac main page ? > > My point is that I think suggestions might be jumping the gun > a bit, unless the sheer volume of suggestions might help reverse > our previous poor fortune. > > Step #1: Get accepted into SoC. > Step #2: ??? > Step #3: Profit! > > No, wait... :) Well, I think a nice list of suggestions/ideas would be a great thing to have, SoC or no SoC. Maybe if everyone here could take a day or two and think about some set of such, then submit them here for consideration.. eventually compile them into a reasonable list to add to the e site, under various sub-categories... Actually, I have one that likely others have felt as well: "eterm on new efl libs", or just various ideas for eterm that people might think of. Eterm is one of the great, classic e apps that many love and rave about.. but some feel it could be improved somehow, or become even more cutting-edge. _ Click for free information on court reporter careers, $100 per hour potential. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l6dgHjC5iVhxGscKfxs7kuVabLKI3JWwxWw8itwjzd9AyOc/ - 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] Imlib2: problems with HSV colors
> Furthermore in the function __imlib_hsv_to_rgb an improved behavior > could be achieved if the last case statement in the switch would be > replaced with a default. Give it a shot and see if it fixes the issues you experienced. You might also want to look at evas' hsv-to-rgb function: evas_common_convert_color_hsv_to_rgb in the file: evas/src/lib/engines/common/evas_convert_color.c try using its implementation in the imlib2 function (instead of the current imlib2 one) and see if that helps. _ Click for free info on online degrees and make up to $150K/ year. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nlXFuK1e9gVr14HVU4n53xKufFdaxpkX72xaM95QAMvKJKI/ - 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] Google Summer of Code 2008
> there were no specifics on why we were denied beyond a vague > "we don't think you are a worthy/valid/interesting open source > project". That would be their right to decide of course, and a natural view for them since e has so-far shown little interest in web related 'technologies' whereas google in largely centered around such. By contrast, both of gtk/gnome and qt/kde have extensive support for that.. thus making those projects far more attractive. Not to push other projects here, but... What I don't understand is why this really interesting project called "PyroDesktop" hasn't been supported by them.. it seems like an excellent idea for a web-centered desktop shell - a Mozilla/xul based window manager. _ Paying too much for your business phone system? Click here to compare systems from top companies. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3ohtZpWeGpr2PUYz7KgHYiiRBQ4wpyGDGhJ4o2PwhIOqHblu/ - 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] EFL and Webkit
> As for implementation details, smart object is not the best option, > actually using Evas as WebKit backend is not the best option around. > ... > ... > So the best option is to draw to some buffer and use this as image > data, then take care of event passing to this webkit engine. Using > ... Using smart objects has nothing to do with using evas built-in primitives. A smart object, along with render-pre/post functions for smart classes, may actually be your 'best' way to wrap that image object to which you're setting the data - you would do your rendering to the image data in the smart parent's render-pre function, and keep any relevant state as part of your smart data. With render-pre/post functions you could restrict any drawing to the image data to when evas renders, redrawing only what areas need it, and adding only those updates to the image object. Alternatively, you can use buffer engine and a sub-canvas as in done in ecore. Yes, these are all doublle-buffered solutions, which has both good and bad aspects... it's at its worst when things are constantly animated. But these are not going to be 'accelerated' solutions without support for 'native surfaces' in evas image objects. _ Click for free info on business schools, $150K/ year potential. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l7gMa49rDXuDBBJYXBgZ8bIpq5pi4CGeUjC3brt3TlCDbXS/ - 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] [RFC] Edje improvement
> > There are a couple of other smart class functions that would > > also be useful with smart objects, in particular min/max_size_get > > functions, and add similar functions to the evas api so that one > > can query an evas object's min/max size. > > I already though about that, and perhaps a way to only specify one > direction could be usefull. If you want to setup a textblock, you > know the width but not the height you want. Or for an image object > this could give you a way to have without special case in your code > a way to respect aspect ratio. Not that this is difficult or > impossible to code today, just easier if the object told us the > right answer. Also, consider when one has an edje group that swallows an external object. When calculating the edje's min/max size, you need to know the swallowed part's such.. Well, right now, this is done in edje in a very ad-hoc way and can be problematic to deal with in general for swallowed objects that are designed to have min/max sizes (but aren't edjes themselves). > > I should add though that in this particular case, there could > > be potential 'side effects' in event handling.. because, some > > changes of state that could be affecting the size and positioning > > of things, would then be deferred to render_pre time, and hence > > possibly not be detected by the events system. It's something > > you'd have to investigate as to what consequences it might have, > > in this particular case. > > I may be wrong, but I don't see a reason for edje_calc to send > signal right now, nor did I saw a direct to it from edje_calc. > Perhaps someone with more knowledge on edje could give a better > view of the problem. Sometime ago, I considered doing this very same thing with edje_calc. Never did get around to looking into that in more detail, but I dimly recall there was some issue on my mind that was related to this consideration. It's been a long time now and I can't recall exactly why.. but just thought I'd mentioned it to you. _ Click here to obtain free information on accredited degrees. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l8OpuBKdPwAvyspcKtyTT47qT3nL2bhKiFPwnkjkdHxiapC/ - 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] DirectFB, Intel GDL, Overlays and more
> 1. An engine that can render to such a native surface buffer (rather >than using the software argb buffer engine). > 2. Implement evas image 'native surfaces' for the kinds of buffer > surfaces you use in (1) above. I should add that (2) isn't really needed for most uses, it'd just be 'nice-to-have' for greatest flexibility and efficiency. For example, for the opengl engine, one could have gl textures for the 'surface' buffers, and then be able to use the gl api, or any number of libs that support rtt, for custom rendered objects (ie. one renders to such a buffer and uses that buffer as the 'data' of an image obj, thus obtaining a custom rendered obj). Though for this to be truly useful, it would likely be best used in conjuction with render_pre/post functions of smart classes. _ Love Music? Get a degree in Musical Education. Click Here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oLWtvUT98gPPElJFfhvCV8rcyczR7UqpuVxQY2kdm82ElFu/ - 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] DirectFB, Intel GDL, Overlays and more
Gustavo wrote: > Now to Evas part: we have an outdated DirectFB which AFAIK nobody > is using or willing to maintain and we (more specifically Cedric) > have SDL almost integrated. The directfb engine was initially written a long time ago and was never kept up with as much as other engines, it could use a re-write. I believe Freevo was using it, but not sure if that's still the case - Jason Tackaberry did some work to bring it slightly more up to date a bit back. > I know SDL is really bare bones, so overhead of it should be > minimum, however due it being bare bones I fear it not exposing > primitives we could benefit. I couldn't find any source code or > patch for SDL, so I'm not sure what they optimized. SDL as in the software-sdl engine? I think cedric tried to use more native sdl apis for optimizing some things, but as I recall he had some issues with compositing via sdl functions due to something about their handling of alpha (maybe due to evas use of pre-mul data?). > I don't know DirectFB more than reading their website some years > ago, but looking at their code and the patch provided by Intel, > . > . > > So I'm not sure on how to proceed. Would it be better to get > DirectFB in shape, use SDL or write Evas GDL engine? Maybe my > requirements can help somehow: > ... > ... 'Fixing' the directfb engine would be good regardless, but wether to use that vs. the sdl engine vs. write a new gdl one...?? Note though that this issue of 'overlays' has come up before in regards to using evas with opengl in games.. and wether or not you do go ahead and write a gdl engine, you may still face some of the common issues that were relevant to using evas in those kinds of lud 'overlays'. Basically, if your 'overlay' can be given as a display target buffer 'surface', then you'd want to draw to such native surface buffers, and that means two things: 1. An engine that can render to such a native surface buffer (rather than using the software argb buffer engine). 2. Implement evas image 'native surfaces' for the kinds of buffer surfaces you use in (1) above. Then you'd also need some support from ecore (and enhancements to the whole sub-canvas part). But for this to work best you'd definitely want to have your native surface buffer engine do as much as possible via accelerated methods (and make sure the drivers for those are good) - if you're going to have the rendering mostly via software, then for (2) you might as well just use a software buffer engine instead (you shouldn't need to get pixels out of the display target unless you're doing some very specialized gfx effects). > What's the state of DirectFB? Was it running fine one day (ie: > directfb part is okay, it just lag behind Evas api changes)? It was ok not too long ago, just behind on some things then.. check with Jason from freevo.. maybe he can be of some help there. jose. _ Click for free info on business schools, $150K/ year potential. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l7gMtXxsPP8YHDFA1HhQEbGNPFkaYE5rax2fYZWbJMI7LPC/ - 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] [RFC] Edje improvement
> - call _edje_calc only from a render_pre. I should add though that in this particular case, there could be potential 'side effects' in event handling.. because, some changes of state that could be affecting the size and positioning of things, would then be deferred to render_pre time, and hence possibly not be detected by the events system. It's something you'd have to investigate as to what consequences it might have, in this particular case. _ Click for free info on rehab treatments for drug & alcohol dependency. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nCeLs6pLAkXE8vlfBg4TgKdgRQbP5BAYofw3kwjxB1KS94E/ - 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] [RFC] Edje improvement
Cedric wrote: > If understood the code correctly, when I change a property that > could affect the layout of the edje, _edje_calc is called directly > instead of being defered until render like all native evas_object > behaviour. That's because smart object don't have a render_pre > function. It also need to recalculate all edje part, because their > is actually no way to know what are the part that would be affected > by the change of another part. Exactly. It's a real source of inefficiency for most any smart-class derived object that needs heavy calculations and/or uses custom rendering. One'd need to add render_pre/post functions to smart classes (very easy to do), and have these called, if there, from the smart object's internal render_pre/post obj functions. There are a couple of other smart class functions that would also be useful with smart objects, in particular min/max_size_get functions, and add similar functions to the evas api so that one can query an evas object's min/max size. jose. _ Click for free info on online masters degrees and make up to $150K/ year http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nNjcaHVAzCuFMV4rAE8pAP1h4qQQrzhXWs1Z3o2Hr0gub1m/ - 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
> > 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
> > 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
> > 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
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] todo item: "Language Packs"
Andres wrote: > I spent hundreds of hours learning and writing about the EFL and > all this time will be wasted if the flagship product of the EFL, > the dr17 window manager, is not released in a reasonable time frame. That's a great contribution and personal effort on your part, but I'd have to disagree with your statement about it being 'wasted' unless e17 is released sooner or later (or even if it were ever to be 'released' at all). Not everyone feels that e17 is more or less important than the development libs or tools. Obviously raster, and many others, feel the e17 desktop/gadget-shell is of great importance - personally and otherwise.. but to feel that it's the only work that defines the value of the E project is a very narrow viewpoint (and an unfortunate consequence of the way the project has evolved over time). There are other excellent things written with the efl: eterm, entrance, enna, canola, freevo's stuff, ... etc. If seeing MORE great apps written is what people here want, interesting apps that are *easier* and *faster* to write (including e17 and various possible modules), then furthering the state of the development tools/libs is of primary importance.. e17 is just ONE app written via these things and its development, as well as other apps', can be done "in parallel" with that of the dev tools, each driving and benefitting from the other. But people here have to learn to see and work that way, rather than block things from evolving. _ Save hundreds on a Study Abroad Program - Click here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l9pmwvZRI4upu7SIJopnAOLMYYaojg6c2FjOE8ihYqnvjIE/ - 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] Edje / EDC file, detect two images interacting (draging one to the other)
Just to get back to this a bit... Gustavo wrote: > I can provide you some tips & tricks others told me along the last > year. My first advice to you, based on my own experiences and > those from my team and people I introduce to EFL: don't overuse > Edje and mainly Embryo. Everyone that learns it find it so powerful > that tries to solve every problem with just these 2 technologies, Ideally, both edc and embryo-scripting could be extended enough that one could use it to deal with most gui 'problems' one might encounter (more or less of course). I think this is raster's ultimate wish for edje. :) This would be akin to what Mozilla xul+javascript, Flex mxml+action-script, MS xaml+something(?), or Sun JavaFX, all do -- in their own way. One might also wish for edj/edc to allow for further kinds of scripting besides embryo, and for it to use code-logic loaded from external sources as well (this is something which I believe MS's xaml allows). That way, one could use not only embryo scripts, but also say (external) python scripts, ruby scripts,... or C code. ie. use edc to define the ui, and possibly load/execute suitable logic in other associated files if desired. Hisham's evolve (+edje/edc) does some of the extending, by enabling standard gui-toolkit widgets to be defined via an edc-like syntax (hopefully, it'd become more widget-kit agnostic at some point, right now it's etk-widgets only), but I'm not sure just how much it allows on the 'scripting' or 'code-logic' side. I think it'd be great to hear what both raster and/or codewarrior (or anyone else) have in mind, or just "wish" for, regarding this. _ Click for free info on detox treatments for drug & alcohol dependency. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nCaIvTofQDopnm7hi9qAZEy5qRagGUEZtsTIDLRepBs3cda/ - 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] Edje / EDC file, detect two images interacting (draging one to the other)
> > There are some documentation bits here and there.. eg. the > > wiki at http://wiki.enlightenment.org, but I don't think I've ever > > seen any docs on embryo at all (it's kind of an incomplete > > scripting language as it stands, and likely mostly raster has any > > real insight into it). > > Embryo is based on PAWN, if you loot at old Embryo description you > find a link to it's page, with language documentation. Also of help > is embryo.inc and edje.inc If you find that helpful for embryo in edje... great. :) > > There may be other 'bindings' or even different syntactic > > descriptions for defining edjes besides edc (maybe xml based ones)? > > I hope not, manually editing xml sucks hard compared with .edc :-D > Specially if you use my emacs module :-D Well, that may be in the eye of the beholder.. I'm somewhat ambivalent as far as syntax goes. But the real gain one would have with something like xml is the of multitudes of tools/libs that exist for it. Already there are 'issues' of various sorts due to a lack of a parser for 'edc' (similarities to css syntax not-withstanding). There is also the possibility of xml -> wbxml for use... _ Discount Online Trading - Click Now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mJ8Xms9NQrB5GRACbZzycRE1t9KQQwVFfiQU72rxOzeIXlm/ - 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] Edje / EDC file, detect two images interacting (draging one to the other)
Gustavo wrote: > on a self-marketing side: I wrote the Python-EFL bindings, > we built Canola2 (http://openbossa.indt.org.br/canola) on top > of it and it works really well, if you know python, or is fine > with learning a new language, I really recommend you to do, > life will be a bit easier ;-) And it's amazing that you guys were able to do so much with the efl so quickly.. edje in particular is kind of a "dark art". There are some documentation bits here and there.. eg. the wiki at http://wiki.enlightenment.org, but I don't think I've ever seen any docs on embryo at all (it's kind of an incomplete scripting language as it stands, and likely mostly raster has any real insight into it). Are there similar docs for the python bindings? BTW, there is also tilman's ruby bindings for the efl (see http://code-monkey.de/pages/enlightenment), and also his 'redact' which is an "alternative edje compiler in Ruby". There may be other 'bindings' or even different syntactic descriptions for defining edjes besides edc (maybe xml based ones)? _ Better by design. Click here for professional graphic artists! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m0uds2chY7odofykPU1WQtK28keYIjXe2Vjb06btHqjuF1O/ - 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
[E-devel] E CVS: apps/e barbieri
> Modified Files: > e_widget_frametable.c e_widget_frametable.h > > Log Message: > Add const to frametable's label. > Just a minor thought here on all this widgetry stuff... For all of these 'e_widgets', wouldn't it be better to have a consistent interface for 'adding' them to an evas? For example, say of the form: Evas_Object *e_some_widget_type_add(Evas *evas); and then have functions for setting the relevant properties.. Or, as another possibility, say of the form: Evas_Object *e_some_widget_type_add(Evas *evas, void *property_class); where 'property_class' would refer to a type specific struct that would hold the relevant things desired.. (Or some combination of these.. say the simple 'add' with no property arguments, and a function to set the property_class). This would not only allow for a simpler, more consistent methodology, but also make it easier to change or extend the kinds of initializing properties used. In a somewhat different vein: Since these 'widgets' possibly need some set of edje groups to define their 'theme', wouldn't it also be desirable to allow one to be able to specify an edje file that would hold the required theme elements? This would allow for any given widget instance to be separately themed - if desired (I believe both ewl and etk allow for something like that?). BTW, what happenned to Hisham's "eblocks"? Wasn't that a lib similar to these e-widgets stuff? jose. _ Be your own boss. Click here for information on starting your own business. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l5e2pbSxwe17Zn1lfnNkod0YFs2zzs0Ex5FPeIaPJmOX4G8/ - 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] larger gadgets/shelves?
> >Again, I'm just proposing a simple mechanism to enable > > the notion of loadable, themable 'evas-objects', so that these > > interesting, compound, gadget-like things can be made available > > for use/re-use on a wider basis. > > There are a LOT of interesting 'objects' one can make > > using evas/ecore/edje/other-stuff... things from a simple boing- > > boing-logo to system-monitors to clocks to matrix-bgs to some- > > layout-object to some-gui-control to color-picker to virtual- > > keyboard to calculator to simple-video-playing-object to > > whatever. > > > > It's a shame not to be able to load/use/build these > > kinds of things, where appropiate, or explore what this kind of > > capability could evolve into with further refinements. > > what you want is basically what KDE plasma provides, we already > did it using python-efl for Canola, it's not as generic as you > want, but it's more generic than what we need, working really well. That's actually very interesting about canola - you've never really mentioned much about it. :) I guess Kde's plasma (I know as much about it as I do about the surface of the moon, ie. seen a few pictures, read a few stories), could in part be an example of something like that.. and so is their "kparts" stuff (minus the merged-gui-controls bit). In the windows world there's this "DesktopX" framework which also seems similar, and it's built on something very close to edje - though I believe it's all developed via some gui builder and a scripting language, same as with Flash I'd imagine. I suppose many that have to do with "guis" could be said to have similar aspects... really anything that claims to have some kind of 'modules' system - it's mostly a matter of the functions/properties exported by the modules and the objects they deal with. For what we're talking about here it'd be evas objects, though I suppose one could do the same with ewl/etk-widgets or with something derived from these toolkit widgets. With certain kinds of 'object systems' one often sees libs that have a 'base' object which one can 'extend'. Invariably one then sees developed larger libs which attempt to collect a set of standard/ common 'objects' which depend on each other and work together somehow. They also allow for building on this by further 'extending', and often such further derived objects are offered via other known libs. Invariably though, one also sees 'objects' that are fairly self-contained or very specialized (regardless of how they're created), and these are sometimes best used at run-time, if desired, rather than linked-to beforehand, hence some sort of mechanism for querying/using these also seems to be common. I don't think it'll ever be the case that one will supplant the other, regardless of the kind of object-system or the programming language used -- especially if the objects in question allow for 'embedding' of objects into some others. > > Given some time, I'd really like to provide a layout library and > possible some basic widget-like components, just get e_box, > e_widget_* and make a lib. Maybe it should go into esmart, dunno. > That could be very useful to many. [NB. raster has often mentioned wanting to extend edje/edc in various ways.. eg. more scripting language support, but also possibly having more layout mechanisms and maybe some form of widgetry..?] > It works, it's easy to do, what lack is people actually doing it. Ummm... not a lot of work to write an intial pass at a lib to manage such an 'evas-object' modules system.. and the actual modules themselves would just be developed over time as desired. I suspect there are other reasons why things like this have 'problems' getting off the ground. _ Get the perfect student credit card by clicking now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mIRRUD5M9ASNCepX4RYtstkgdgX48tsxJdJVvRv0ajqfvJG/ - 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] larger gadgets/shelves?
Gustavo wrote: > I have no time to reply your mail as detailed as I would like, > but one idea to do what you want is to make the gadcon usage > recursive. Then we could have an object that exports its own gadcon > api to children. Maybe it's an overkill and can be done by means > similar to evas smart objects. Well, gadcons are mostly evas smart objects that implement a certain simple layout policy on its member objects, so likely having gadcons that contain other gadcons as members wouldn't be too hard to achieve.. and of course one could also have all sorts of other layout/container objects as well. All this could be very useful to have for actual, real uses. What I was pointing to though was something a bit more abstract in nature. Basically, it's really just the notion of loadable, themable "evas-objects" (akin to what edje is in particular), eg. things like a 'clock-object', or a 'cpu-monitor-object', or a 'jumping-logo-object' etc... as well as various kinds of container/layout objects (possibly with some notion of a fg or bg), all are just examples - with some of them possibly exporting more functions unique to them, but all exporting (at least) the ability to add an object instance to a given evas, and of setting a theme/resource file on such instances. By abstracting this out into a lib that 'manages' these loadable, themable 'evas-object' modules, you can use them wherever you have an evas available, create new ones (using existing ones or not), put them where others can also use them, etc. There's no need for many of these kinds of things to be e17- modules or e17 specific in any way, they really don't need to be restricted that way (any more than say let's just put edje inside e17), though some could also be 'e17-objects' or 'appX-objects' rather than generic 'evas-objects'. Again, I'm just proposing a simple mechanism to enable the notion of loadable, themable 'evas-objects', so that these interesting, compound, gadget-like things can be made available for use/re-use on a wider basis. There are a LOT of interesting 'objects' one can make using evas/ecore/edje/other-stuff... things from a simple boing-boing-logo to system-monitors to clocks to matrix-bgs to some-layout-object to some-gui-control to color-picker to virtual-keyboard to calculator to simple-video-playing-object to whatever. It's a shame not to be able to load/use/build these kinds of things, where appropiate, or explore what this kind of capability could evolve into with further refinements. _ Boost your business with a small business loan. Click now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3no7b2odKd6a6lfu3Q6Kj4XbEduIi8vxVpkcLCWGKildKgLu/ - 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] larger gadgets/shelves?
Gustavo wrote: > > Has anyone followed up on this? It seems to me that this > > could be easily done in a way that would allow for a certain amount > > of re-usability of such 'gadgets', and yet enough flexibility to > > have custom designs as well. Likely there are multitudes of ways to > > go about doing something like this, but maybe a simple approach > > could be a good one to start with? > > Raster sent this code as example, it's pretty simple, but no time to > work on it still: > >http://www.rasterman.com/files/logo-0.0.1.tar.gz A very nice example :) Note that one could do much the same with many of the current gadcon based e17-modules - ie. display them directly on a zone's bg evas and have move/resize handlers if desired. And of course one could write whole new ones... But there are a couple of limitations with this: 1. All these nice gadgets are strictly "e17 only". Not much here that other apps/libs could use (except copy paste some code). 2. Even within e17 only, there are some undesirable aspects. eg. if you wanted to have a gadget that consists of a clock, plus a cpu-monitor, plus a mem-monitor, and you want these to be arranged in some interesting way relative to each other, and maybe have a nice background that contains them which does a nebula-effect (whatever that is) on mouse-over, then it's not clear wether you'd have to write all of these components from scratch... One would like to be able to address these things in as simple a way as possible - ie. make it easier to re-use exhisting 'gadgets', to create new ones from sets of given ones, etc. Note that one thing that all these kinds of 'gadgets' have in common is that they define evas objects on a given evas, preferably a 'themable' object - and commonly they simply define an edje object. They could also have certain 'properties' that might be varied, and this is usually done via some configuration gui. Does this seem like something one could use as a starting point for finding a means to address the above mentioned limitations? For example, let's say we take only the "core" aspects of these gadget modules so that one has only some loadable libs that expose certain functions - say a function that 'adds' an evas object to a given evas, and another to 'set' a theme/resource file on such a thusly created evas object, and maybe a function to set/get named property/values, and possibly other functions particular to a given gadget. Of course one might want a way to 'manage' such object-modules and thus maybe a lib to load them, init them, keep references, etc... Could these generic 'object-modules' (plus a 'managing' lib) be used for building 'gadgets' as desired?? _ Beauty Product Reviews Read unbiased beauty product reviews and join our product review team! http://thirdpartyoffers.juno.com/TGL2121/fc/JKFkuJi7GiXG07S2bI33ExQknalirOMoYMTWHjW874ZiTMwMFZ1MiE/ - 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] larger gadgets/shelves?
Sometime back, Gustavo wrote: > So, my idea is either to provide larger shelf size or provide > another shelf category, maybe desktop applets, that could be > placed everywhere (if it makers hard to efm icons, then maybe > disable those or make this new shelf attached to borders, with > icons evicting it). Larger shelf is easy to add, just change the > max constant, but I really thing the other option is more > interesting, we could have more specialized applets, like, > the calendar view could toggle between large Month-Day/Week-Day > and full edje-beauty calendar, other modules could Then, Carsten wrote: > you can. its a few trivial lines of module code to go put any evas > object on the desktop. anywhere. a few more to allow you to just > move it around anywhere - and a few more to resize. if you REALLY > want that. a shelf is NOT THE SOLUTION TO THIS. tyring to use the > shelf shows a fundamental mis-understanding of e's internal code > and how it all works, and just how trivial it is to do it yourself > with custom objects. Has anyone followed up on this? It seems to me that this could be easily done in a way that would allow for a certain amount of re-usability of such 'gadgets', and yet enough flexibility to have custom designs as well. Likely there are multitudes of ways to go about doing something like this, but maybe a simple approach could be a good one to start with? _ Beauty Product Reviews Read unbiased beauty product reviews and join our product review team! http://thirdpartyoffers.juno.com/TGL2121/fc/JKFkuJi7GiXZ1FN7tCJs851A2aHol8FFGF7FH9KBYQcyzwXtUBv79u/ - 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] Epsilon problems
> what you want is an: > > evas_object_image_rescale(Evas_Object *obj, int w, int h); > which forcibly rescales ANY image to a particular size - be it > loaded from a file or generated as ARGB data. this gives you the This has been something I've suggested to you before, many times - it was something you never found needed. Yes, that could be useful in various situations. > choice after load - if the load options didn't get you a size > you are happy with "for free" to do extra work to fix it. with > enignes like the opengl engine scaling is "free" so you might > not want to pay the price of a software-scale on load when a > "please pre-scale this to this size - if you can do it for no > extra cost" is by far better - for jpeg in this case u can load > a large jpeg image at a reduced size much faster and then scale > with GL afterwards "for free". putting that into the load and > load options takes that choice away. Nothing is for free.. and to make evas' potential semantics depend on not only the existance of GL, but also good drivers for it (so that the claimed 'free' scaling is obtained), seems like somewhat of a new reach for evas. No, it doesn't take any choice away whatever - you don't have to set scale options.. and for your 'jpeg' case you can just set the power-of-2 you want and it would still do that part. Not only that, but if one really wanted to go taht way, one could make all engines (gl, xrender, ...) part of the scaling-on-load process (lot more work, but could be done if that's really a big thing to have). Not respecting size related load options uniformly across loaders could take away, as well as create confusion. What it could take away is the ability to cache an image loaded at a size other than the file-given one.. if load-options were added to edje that could be very useful. Of course one could also go the extra mile and add caching of scaled images loaded from files or not, but it's yet an extra new thing. I don't see an 'image_rescale' api function and a consistent semantics for load-size options as mutually exclusive. But, since you obviously feel very strongly about this and I don't.. again, I'll leave it up to you, and those who have use cases where these things come up, to decide as to what the best way to go might be. _ Click to become a master chef, own a restaurant and make millions. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m4pC396gbCwHORjUhPd40WyO0Uhf24QQqM9htU1ztMO5tCw/ - 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] Epsilon problems
> Is there any internal call to do these scaled blits or just > those of evas_common? If so, those more used to it: there is > any way to use these evas_common functions to do this convertion? Only the 'common' functions for scaling are really needed. Just do an imitation of what the e17 thumbnailing code does, for those loaders that don't currently support scaling fully to the load-option's requested wxh size (I'm assuming that's all you really want to fully implement). Use a temp image whose data is the loaded file's data (loaded according to what's currently approximated there to the size load options), and scale that to the real image you're working with (then get rid of your temp image and/or its data). There are a few details here and there you'd want to make sure are covered, but it's all fairly straightforward if you look things over a bit. Or wait a few days and I can send you a version when I get a chance. But you'd still have to navigate the more complex, murkier waters of getting such heresy into cvs. :) _ Stuck in a dead end job?? Click to start living your dreams by earning an online degree. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nNfaT3FnM82IViYSct5wnA1xKHJkhmlXElIkaWNbEOsTxpe/ - 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] Call for help: E + SCALE ( http://www.socallinuxexpo.org / Feb 8-10 2008 )
> > I can make it there if need be. > > why don't you come just to hang out - since you're there :) I'm quite far away actually, so while that would be nice, it's not something I'd really consider all that lightly. _ Click to learn about options trading and how to make more money from the pros. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m5bjLdjZYwGQpXLBHsC8LyJMFBgd0XhaorJvqQs53NURr8s/ - 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] Epsilon problems
> > Man, we all say some silly things in time, but this has to be one > > of the good ones from you. :) It's a 'load option' so it's fine > > for this to be 'optionally' implemented in a loader? Wow! > > correct. load options include things like DPI settings. do you > expect every loader to now scale images based on DPI - the loader > doesnt even know what the DPI of most image formats is - will it > "fake" one (eg 75dpi) just to make this "work" ? these options are Yes, because that's exactly what we did (for the one and only loader that respects that, the svg one), except I believe it was 90 dpi not 75 that we used. I can understand some 'option' so particular to a format that it had absolutely no relevance to other formats.. eg. a format might support various kinds of de-compressions, speed vs quality kinds of things or whatnot.. but that's just not what's being adressed here. We're talking about, essentially, about image sizes - likely the most common attribute you can think of for "images". > there if the loader can do something easily/for "free" while loading. > for some formats like SVG rendering at a DPI is part of loading - > or at a size, so it comes for free. for jpeg scaling down by 2, 4 or > 8 in each dimension is for "free". if every loader implements this > i also need to add controls over the scalign quality (smooth or > samples for example). None of this has any real bearing on the issue at hand - ie. wether evas itself should do the re-sizing on load, or let everyone who needs it have to copy&paste your e17 solution. But it's your call so we'll leave at that. :) _ Live your dreams. Click here to find information on becoming a lawyer. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oFGmcsTG5zvq2NKKrizxPBJOtoZSV14O43SGaQcKaICuQqc/ - 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] Call for help: E + SCALE ( http://www.socallinuxexpo.org / Feb 8-10 2008 )
> What: Gareth from SCALE has really kindly offered Enlightenment.org > (that's use guys) free floor/booth space @ SCALE ( http://www.socal > linuxexpo.org/ ) Next February (2008). So it looks like I will be > there. Also Nathan of EWL fame and work will likely be there. > Is there anyone else in the area (This is southern califronia) who > wants to join and help put together/man a booth and at an expo? > Hands up now? > I can make it there if need be. > Suggestions on things to do are welcome. > How about taking the opportunity to discuss "what could be done" to improve the project, to address its weaknesses, to enhance its strenghts, etc.? How about coming up with some concrete short and long-term goals that people can see as real things that can be worked on? (and I don't mean just e17-todos) I'll even start it here by listing some of the next-generation projects in e's cvs. 1. The "core" efl libs: evas, ecore, eet, embryo, edje, and some language bindings. 2. The "utility" libs: esmart, efreet, e_dbus, epsilon, evfs, exml, ...? What else belongs here? 3. The main toolkits: ewl, etk, and some language bindings. What are utility libs for these? 4. The "important" apps: e17, entrance, ...? What else belongs here? 5. The "utility" apps: edje_cc, ... What else should go here? 5. Other apps: What should go here? What are short/long-term goals, aims, roadmaps, progress, ... for these things? What about for how they 'fit together'? What's important in E and what's just incidental? Let's take epsilon for example. There was recent discussion on how to perhaps improve epsilon in this or that way, some ideas and whatnot... But, will anything come of that? Why should anything be done to this lib at all? I'm starting to think that having certain of these special- purpose libs is a "bad thing". It just seems to lead to projects falling by the wayside because there's little or no mechanism, or community built around them, to ensure that their fires keep on burning. It might've been better if epsilon had been an 'ecore_thumb'. Maybe then there would've been more attention paid to it over time. Ecore may be a mish-mash of things, and some dependencies there might be a bit twisted... But it's ONE identifiable important thing that many people look at and work on. Much the same could be said about e17 as well.. it at least manages to stay focused and un-fragmented. jose. _ Chart your path to success with a smart new business plan. Click here! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nojL2rIySqaVgJajQyq8UopyPUUiwgkMYrxPeEyvcbDFiAI/ - 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] [PATCH] Edje improvement
> > I have been working on some little improvement for Edje recently. > > The first patch, "edje_data_file.diff", add support for a > > data.file entry inside edc file. It give the possibility to put > > text file inside edje directy. > > hmm - ok. sounds ok to me - using that for copyrights and such? Sounds potentially useful - one could even use it to embedd other text-based file formats...? One thing that edje/edc may need is a means of 'typing' the various kinds of edjes. Right now, all these .edj files are used to define a very large and disparate number of things How does one know if it's an e17 bg, some clock thing, an etk or ewl theme, an icon, some menu or dialog theme, or who knows what others may use them to define. This kind of thing can become a problem over time. Maybe time for some way of specifying WHAT these edj files are supposed to be - perhaps something akin to what's done with mime- types... maybe some 'type', 'category', 'description' sorts of data in the edj/edc file (maybe with versions as well)? Anyone have any suggestions on this? jose. _ Save hundreds on an Unsecured Loan - Click here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m3iUASETfimAwEe8X9bUmPtTpfLDeW14o6KQy9FK3cdqdWw/ - 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] Epsilon problems
Carsten wrote: > > Unless... Oh, oh.. unless we didn't finish off implementing > > the load-size option for all loaders. I know we did it for the > > svg loader, and that the jpg loader respects loading scaled-down- > > by-dyads, but I can't recall if we really did finish off making > > sure that all loaders respected the load-size option.. need to > > take a look. If not, then it should be filed as an evas BUG. > > see my other mail. load-size is an option. a loader implements it > ONLY if it can do a scale-down on load "for free". it is a hint, > not a requirement. you need to load, then check image size and see > if you need to adjust/scale later yourself. so only the svg loader > will scale to the size u want - as it can. the others wont' do > anything. the jpeg loader will chose the nearest scale size it can > manage (which is 1/2, 1/4 or 1/8th the width/height of the original > jpeg file - that's all it can do. this it gets for free tho on load. > in fact load is faster the more u scale down). Man, we all say some silly things in time, but this has to be one of the good ones from you. :) It's a 'load option' so it's fine for this to be 'optionally' implemented in a loader? Wow! Tell me, given that this is really trivial to add in evas, and you end up going thru inefficient loops&hoops to get the 'option' to actually work in a 'non-optional' way, then why not just have this actually work? > > I think evas needs to add an image saving 'size' option, > > maybe best done via the current "flags" for saving, so that you > > can save an image that alreday exists at some size (for whatever > > reason), to a file at whatever other size one wants. > > not sure we should do that - as above - its possible to do this > with buffer canvases and objects. it's much more flexible as i can > ALSO put MULTIPLE objects into the thumb then. i can add watermarks > and more to them. Sure, you can do all sorts of things.. but it doesn't mean that it's always the best way to get something simple done. Other than new work required to add something like this via the api, why do you feel that maybe it shouldn't be done? ** > > I doubt it worth the pain, because if we go FDO we must remove > > any attempt to use .edj as thumbnail format, and it's a good > > alternative if you want to provide movie thumbnail. Going "too > > generic" may hurt more than help if nobody else use it, and > > believe me these guys are hard to get using done by others, you > > know the NIH syndrome... > > agreed it will be painful. i don't think we should force edje > into a thumbnail format - BUT eet is possibly useful there as its > agnostic when it comes to glib, qt, efl etc.. the gtnome/kde crowd > as best i know do not have any such "container format" handler to > pack many data items compactly into a single file with an easy api > to access it again. so we are not competing. I can't see why what FDO wants or doesn't want to support as 'acceptable' formats should stop anyone from doing otherwise. In fact, I can't understand why any reasonable, OPEN format would not be acceptable, nor the reason for *requiring* that some particular format *must* be accepted.. and none others?? None of this sounds to me like a body whose decisions should be respected - if indeed that's the way it operates.. it doesn't sound to me like the spirit of foss to do so. jose. _ Find the military school that meets your standards. Click now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l91uO8BwI8E6hEJHRkt2eScxmPs1zdarLaGSbnXUKoFNHdu/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
Carsten wrote: > > > At the very least, it should be a negotiable process where > > > clients can specify the result formats they can support and > > > the thumbnailer can select from those supported formats. > > > A fallback requirement of png or some other standard format > > > would be reasonable. This would allow us to support jpg, mpeg, > > > edje, or whatever format we choose, and any clients that also > > > support those formats could benefit. > > > > I suppose a minimal 'standard' format for animated images > > would be good. This is something that doesn't seem as well- > > established as say png/jpg are for static images.. eg. things > > like mng/mpeg don't seem too widely used by the 'major' toolkits > > to provide say animated icons or whatnot. Animated svgs are > > lacking as well, but even if used eventually, it's likely that > > one may want to save 'thumbs' of them as animated raster images. > > mpg is very widely used - but it support no alpha channel. > mng doesn't support lossy comrpession to the extend mpeg, xvid, > ogg etc. do (it supports jpeg compression with alpha - that's > about it). mng just never took off. As it turns out though, there's a new attempt to fix many of the 'issues' people had with the original mng format. It's being proposed by the Mozilla project, and its main focus is to have a simple format for obtaining animated pngs (with alpha), which they're calling "apng". Here's a link to their spec: http://wiki.mozilla.org/APNG_Specification I briefly looked at it and it does indeed seem well suited to the goals they had in mind. I'd brought this up briefly with Vincent a few days ago since I was curious of the animated image format work he'd started a bit back (I can't recall the original email where he mentions it). Vincent had something similar in mind to Mozilla's as well, but he'd like to use some method of further compressing the animation. I'm sure he can be more specific for anyone who might be curious to help him with it.. it could end up being very nice. In any case, Mozilla's apng seems like a reasonable animated image format for people to use right now, and I hope it'll get wide adoption (I think the png group still wants to stick by mng, even if essentially no one uses it). They even have some tools to create apngs from various kinds of sources. jose. _ Click to become an artist and quit your boring job. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mzjrY1oPA0xIernC8yoLkHVhbIwrQl7DJmjShiM7bB8krqg/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Bang Revival !!
Dave wrote: > For all of you that like desktop effect ala compiz there is a good > news. > > I make some works on the old bang module, if you don't know bang is > a compiz derivate packed in e module. So a module that do composite > using OpenGL. :) > > . This might actually inspire me enough to fix my glx issues, just so I can give it a try and see what it's all about. Very nice. :) Just as an aside here, and something I've mentioned before: If anyone ever gets the urge to try and implement 'gl native surfaces' in evas (via say gl textures), which raster started to stub-in support for, then as long as one's willing to draw with gl to such surfaces, you could do all sorts of 3D stuff and have it display (in a gl-engine evas) as an image object. What could one do with that..? Well, that'd be up for some experimentation to discover, but one could at least use it to import 3D objects from disk (there are various formats), and use some known 3D rendering apis (so long as they can draw to a given gl texture), and go from there... for those who are 3D or OpenGL inclined to experiment with. There's also 2D stuff like OpenVG, which could be used (for whatever). Cool or not, useful or not, it doesn't all have to be at the 'global' desktop-windows level. jose. PS. Simon, didn't you have something similar at some point? Maybe called egloo or such? _ Discount Online Trading - Click Now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mJ8Xc8SFAFGVwn1gjLV3tNiIr6i0hdx40xuRDAKarQr72mU/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje Editor digest
> > Cvs, svn, git, twit,... It's all weird mojo. Maybe Michael could > > write an eterm 'module' of some sort that would feature nice, > > friendly, easily understood commands for interfacing with any of > > these - ones where it doesn't matter which one is really being > > used. > > http://beta.kainx.org/wiki/view/Mezzanine > > CVS works, SVN is about 95% working in the 1.9 tree, and others will > come later. > > Michael Did you just do this or have you had this before? Very nice. But what's that other stuff on your 'wiki' about eterm's future and some "unresolved childhood issues"? :) _ Not having a degree dragging you down?? Click here for free information. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nNfabty0xlQaINh8KTfmzQUYqm9CiqfZgaw9CtfhJyjO7W4/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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] [Evas] possible bug in gradient
Vincent wrote: > before putting that in bugzilla, here is what I obtain with the > following code: > > [code] > > o = evas_object_gradient_add (evas); > evas_object_gradient_fill_angle_set(o, 90); > evas_object_gradient_fill_spread_set(o, 1); > evas_object_gradient_fill_set(o, 0, 0, w, h); > evas_object_gradient_clear(o); > evas_object_gradient_color_stop_add(o, 255, 0, 0, 255, 2); > evas_object_gradient_color_stop_add(o, 0, 255, 0, 255, 2); > evas_object_resize(o, w, h); > evas_object_image_fill_set(o, 0, 0, w, h); How did that last line sneak its way in there. :) > evas_object_move (o, 10, 10); > evas_object_show (o); > [/code] > > the result: > > http://www.maths.univ-evry.fr/pages_perso/vtorri/files/ > gradient_bug.png > > that is, there is a red vertical line at the left of the gradient, > while that line should be at the right (imo) > > is it a bug ? I would say it is a bug. If you have a chance to look into it, please do so Vincent. I probably won't be able to look at it for several days at least. jose. _ Click here for free information on nursing degrees, up to $150/hour http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nEnkqsCC5gFaXv4Ikwr77eXJ1Awq2LPpIvUf2DraNworXcs/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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] Evas_Event propagation
Dave wrote: > Hi all, > I'm in trouble with the evas event system :( > Working on esmart_container to make an iphone-like scrolling list > (with friction) this is the situation: > I have a trasparent evas_object (big as all the container) used > to grab mouse events. When you click & drag the mouse I make the > container scroll. The objects of the list also need mouse events > so I used evas_object_repeat_events_set(cont->grabber, TRUE); > to pass the mouse events. > > The problem is that I want to 'repeat' the events only when is not > a dragging operation. > In the grabber mouse,down callback I need to stop the propagation > of the event to the object below... > > Some idea? > In other toolkits this is done by returning a NULL value from the > callback... Did you make any progress with this? Evas' event model is pretty basic, though you can build on top of it in various ways. I think andruko (of canola fame) may have done something similar.. maybe he, or others involved with the gui toolkits, can give you ways they've used for dealing with things of that sort. _ Need cash? Click to get a cash advance. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mKes7x8X2N0ELQz3clzANSuWChFs5lTPzhDa7qfiG061o2M/ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Edje improvement
> >A last topic I would like to discuss is FPU need by Edje. > > Right now without hardware floatting point, Edje could loose > > around 30% of time in soft float when you have many objects > > on the screen. I don't know what would be the best solution to > > this problem, doing some fixed point calculation or caching > > result, updating them when required. If people have idea on this > > I would like to ear as it is something I want to fix. > Some actual use-case profiles of this would be good.. How many objects and which calculations show significant performance loss due to floats vs. some fixed point version? > Good point, floating point operations can be emulated through > fixed point, enesim has a directory utils with several routines > that are useful not only for enesim but for other projects / > project types, one of them is a small (incomplete) collection a > header files with inline functions for fixed point math, of course > im not telling that adding enesim as a dependency to edje is an > option, it is not, but my plan with enesim's utils was to actually > merge them at some point with edata as a common place for data The actual use of floats in edje that might be a source of 'slowdowns' would need to be determined first, and if there is a problem of some sort there, it should be fairly easy to replace with fixed point calculations without having to use a separate lib that provides utilities for that - unless those utilities are already part of evas (or something else edje would depend on). > containers/operations. I wont start the discussion about splitting > ecore_data from ecore, mainly because edje already depends on ecore, > so the logical option if fixed point math is needed is to add that > to ecore, but then enesim (and evas in case we replace the fixed > point algorithms: line drawing, etc with a known implementation > which is good) will depend from ecore which is again not an option > (recursive dependencies, etc)... Too much fine-grained splitting of things is not that great a help if in the end you just need to include all of them anyway for anything to work.. or if you start running into issues with circular dependencies. Splitting really needs to be organized according to more-or-less logically separate domains and more-or-less commonly used ones as well -- eg. one large 'split' that people often have is "gui" vs "non-gui", even though that's not always so clear. If indeed it would be useful to split-up ecore, then something like that, ie. a base non-gui part and a gui one that would depend on the base one, might be a good way to do it. Wether or not the gui one itself should be split into sub-parts, or if the base one should allow for further modularization, is yet another question. Right now, things are convoluted in places, but it's not clear though that doing this, without first looking into those aspects in more detail, would be necessary right now. jose. _ Get DVDs Delivered to your Door. Click Here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nSQh6yVOE8DWIJd1n4QIje14KcYlyVd4lmECpqy38jQvlKQ/ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje Editor digest
I should add that I hope you suceed with this effort, one way or another. An edje-editor is a very important thing to have, and should be a top priority for an efl based project. I'm curious though.. What do other 'WYSIWYG' editors that deal with similar doc based things do? eg, those that deal with html (svg, mxml, xaml, xul, ... ??). There aren't too many html rendering libs around, do they allow for direct editing of displayed content too? Or do the editors create small doc pieces which get reloaded.. or what? Does anyone have any knowledge or insight into what WYSIWYG editors for things like html (or flash, or MS-Silverlight, ...) do? Obviously you're going to end up having to work with the format's structure as well, but what about the real-time display part? _ Click here to find all of your computer accessories for less! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m9eNpt71hQUvvInBAQPYjMTGT71CbtPJkxUnejLeAVYAYas/ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje Editor digest
Dave wrote: > Hi all, > Just two words to make you inform the new edje_editor status. > I have now reach a first stable version of the patch to edje > (bugzilla #294). In my opinion this version is ready > to be committed to the edje cvs, but I didn't get any devs > opinion :( At this point, since you're starting to dwelve further and further into things, you'd likely want edje's maintainer to give feedback - and that would be Carsten.. who seems to be very busy at the moment. Tilman and Brian Mattern might also be able to help, though Brian is likely too busy with his physics studies. I don't think any 'issues' with your work would be ones of people thinking that the code might not be 'good enough' or whatnot, but rather wether it should be part of edje, or wether it might have problems being completed satisfactorily (due to edje internals being what they are), and those kinds of things. Maybe you could take a tentative look into what issues you might run into as you try and advance things further? eg, what happens if you try to implement adding/removing parts, what happens if you try to implement editing an animated edje (tweened images or whatnot), what do you do about transitions, programs, etc, etc. jose. _ Click here for free information on how to become certified as a project management professional. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oHL9blk6iCm4AHbsWPGuBxwWRbzYSujWrgU59LEik6nEIa8/ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje Editor digest
> > he have to "cvs add" it, not available in some cases (anoncvs). > > He's a developer. He doesn't use anoncvs. > > > Also, having an weird interface that nobody uses it make it suck, > > see? > > Sorry, but there's nothing weird about "diff -Nu" since it's exactly > the same options normal diff takes. And it's perfectly reasonable > that the file has to be added; otherwise, there's no way to tell new > files from extraneous ones. Cvs, svn, git, twit,... It's all weird mojo. Maybe Michael could write an eterm 'module' of some sort that would feature nice, friendly, easily understood commands for interfacing with any of these - ones where it doesn't matter which one is really being used. Maybe an interactive kind of thing, so that you can get feedback if you don't know what you're doing: "Hey moron, did you mean..." :) _ Looking for insurance? Click to compare and save big. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m276DBT4SuNSXEx13DbvvquJJdd5LaYjKR5FAc2sAok347G/ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
> One thing that isn't really dome in e, but could be, is to > let edjes that correspond to backgrounds provide 'large&small' > thumbs in the edje itself.. ie. have two additional groups, say > "thumb_large" and "thumb_small", that give a (tweened) image > representation of the thumnailed main background. Thus, the edje > already contains the two generic fdo-'sized' thumbs, in the edje > bg file itself - and thus no need to generate the things and save > them to some other file, at least not for the two fdo-'sizes'. Let's play with this idea a bit and see what we can squeeze out of it. Let's suppose we want to write an e17 module to display e17 backgrounds in a way similar to Apple's iTunes "coverflow". Now, it's not difficult to actually do this exactly the same as they've done it, we might just need to be able to projectively rotate and gradient-fade images - and indeed evas may one day get such a capability, one way or another. But we could do something like this without direct support from evas if we had a little support from the bg's themselves. Let's say that some bg's had "thumb_large_front", "thumb_ large_left" and "thumb_large_right" groups which held thumbs with gradient reflections, with the latter at some left/right angles. Given that, it would be just a matter of implementing the dynamics of an e17 "coverflow-like" background browser.. It might not be exactly as smooth and whatnot as Apple's, but it'd likely be nice enough - and quite fast (and with animated 'covers'). We could go all the way and do this exactly (or better) than Apple's, just use a "thumb_large" group if there, or generate the live thumb (as is now done) if not, and dynamically generate the projective rotations and grad-reflections via fast-enough software routines (it's not difficult), then do the browser-module. Or do other similar kinds of ideas.. maybe things with shadows, maybe things that come in at some angle, like raster's expedite flowers but with the thumbs slightly overlapping, or whatever. The point here being that the notions of a "thumbnailer" and that of the "thumbnail display browser" might optionally be 'fitted' to work together, or not, and that one really has a lot of flexibility in what can be done here.. either way. _ Credit card rates to high? Click here to find home equity line of credit options. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m3ub5L2NtUoQSXl6grLlNO0R2cb8FBzXn6DwOFfq84wsawQ/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
Nathan wrote: > > I don't think there's a need to require that 'thumbnailing' > > must involve a specific means for storing some standard image > > format somewhere.. one may not want or need to store anything > > ... > > At the very least, it should be a negotiable process where clients > can specify the result formats they can support and the thumbnailer > can select from those supported formats. A fallback requirement of > png or some other standard format would be reasonable. This would > allow us to support jpg, mpeg, edje, or whatever format we choose, > and any clients that also support those formats could benefit. I suppose a minimal 'standard' format for animated images would be good. This is something that doesn't seem as well-established as say png/jpg are for static images.. eg. things like mng/mpeg don't seem too widely used by the 'major' toolkits to provide say animated icons or whatnot. Animated svgs are lacking as well, but even if used eventually, it's likely that one may want to save 'thumbs' of them as animated raster images. One thing that isn't really dome in e, but could be, is to let edjes that correspond to backgrounds provide 'large&small' thumbs in the edje itself.. ie. have two additional groups, say "thumb_large" and "thumb_small", that give a (tweened) image representation of the thumnailed main background. Thus, the edje already contains the two generic fdo-'sized' thumbs, in the edje bg file itself - and thus no need to generate the things and save them to some other file, at least not for the two fdo-'sizes'. _ Boost your business with a small business loan. Click now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3no7boEJlIdW6uesq3bZQ1Bys0EO5gL12fgDhJFHDs2D73La/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
I wrote: > For jpgs you don't have to worry about it since we only > deal with rgb images then, hence there's no difference (and no > premul or un-premul takes place). It does matter for pngs with > alpha though, and then it's fastest to deal with pngs embedded > in eet. But I think the cost of disk access is likely a far > greater factor than any premul/un-premul operations anyway. I forget that the system you're dealing with is flash-drive based, not disk-drive.. so maybe it might have some impact to have to do the premul/un-premul conversions - if saving images with alpha to png. Both premul and un-premul conversions use only ints though, no floats. _ Free information on hiring a Business Consulting Service. Click here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m0mYEcDI9G4NoYxgzY3bLAGgAk35H8Jh0LfBtPMnL14vCQo/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
Nathan wrote: > 1. Split thumbnail generation into pluggable processes. If we can > specify external commands for generating thumbnails, we reduce the > amount of code necessary to support new formats. This also gives us > robustness when a dependency mis-behaves and crashes the thumbnailing > process. > > 2. Switch to dbus for client to server IPC. Many of the issues > currently with the epsilon daemon stem from some initial problems > with ecore_ipc, and the hacky conversion to ecore_con. Dbus is also > targeted at remote method invocation, which is essentially the goal > of the epsilon daemon communications. > > 3. Develop a dbus standard communication protocol with FDO. Ideally, > we could get a protocol adopted by the major desktops which would > allow for a single thumbnailing process to be present regardless of > your application mix. For instance, if you are running nautilus under > E and it handles thumbnailing requests, then we don't need to start a > background epsilon process. I think these are all reasonable ideas. I especially like the idea of having pluggable thumbnail generation that can be used by different desktop/handheld environments. It's absurd that right now there's really just: everything has to be some 'standard' image format or everyone does their own thing and no one else can use it but them. I don't think there's a need to require that 'thumbnailing' must involve a specific means for storing some standard image format somewhere.. one may not want or need to store anything really. There's really very little difference between 'thumbnailing', 'iconifying', 'pre-viewing', ... or 'full-viewing'. If "web-browsers" have a notion of interfaces for plugings that can display stuff as varied as they do, there shouldn't be any reason why "desktops" can't be as flexible, or maybe do even better. jose. _ Looking for insurance? Click to compare and save big. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m275pfSc0Kmxy2ouBR0YuLqtPmFmIrPpMwHwci7k448XSWU/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
> > Depends. If you're already using evas, and want to load > > and save image files to smaller sized (thumbs) versions, then > > using evas rather than going thru imlib2 could be faster - > > certainly for jpegs. Maybe for pngs, *if* you're saving to eet. > > Evas premuls all loaded non-premul argb data, and when saving > > back to png it un-premuls back, so we have: png-file-in -> premul > > -> scale-down -> un-premul -> png-file-out. Which is slower than > > what imlib2 would do. But, if you save the png to an eet, then > > as raster wanted to go with the "premul flow", he made it so > > the no un-premul takes place when saving pngs to eet.. and > > likewise, no premul takes place when loading pngs encoded in eet > > (like eg, in edj files). > > Hum... that pre-mul conversion just went unoticed to me :-) > BTW, how does it pre-unmul? It looks like the conversion looses > bits that you can't get anymore if you're using no-premul (other > softwares other than evas-based), but maybe I'm overlooking things > (maybe to get the blend done you'd loose the bits anyway). Premul vs. non-premul is a long story.. I'm not sure any of us has enough years left of life to get into it here, much less when you're pressed for time (we can take it up later if you wish). :) Yes, there are 'issues' either way with this, eg. scaling deosn't give the same results with premul vs non-premul, and many other aspects here and there. But overall, premul is the way that makes the most sense for what evas is doing and what it's working with. For jpgs you don't have to worry about it since we only deal with rgb images then, hence there's no difference (and no premul or un-premul takes place). It does matter for pngs with alpha though, and then it's fastest to deal with pngs embedded in eet. But I think the cost of disk access is likely a far greater factor than any premul/un-premul operations anyway. > > load-thing-at-its-natural-size-to-buffer-evas1 -> resize-evas1- > > to-thing-size -> draw-it-to-evas1 -> set-pixels-of-buffer-evas1- > > as-data-of-image-obj-of-buffer-evas2 -> resize-evas2-to-whatever > > -> set-fill-and-size-of-image-obj-to-size-of-evas2 -> draw-image- > > obj -> [write-pixels-of-evas2-to-out-file-somehow] this last step > > either directly or again via setting the resulting pixels of > > buffer evas2 to another image obj that you'd have created when you > > 'resized' evas2, and then saving the image obj It's somewhat > > convoluted. > > I don't get why I'd need these extra steps. I'll not use current > Canola's Evas to generate the thumb because the thumb generator will > run on another process. But from that process I plan to just create > the ecore_evas_buffer at the right thumb size and load image there > (img1) resize and show, then use a hidden img2 to set the pixels > based of buffer pixels, just to be able to save... I guess this is > almost what you mean in your fast case? Yes, except that img2 will need to allocate its own pixels no matter what you do - because evas doesn't really allow you to set external data without it first allocating data the size of the image you want (unless there've been changes I don't know about). So, either you create the buffer evas at thumb size and also create img2 at that same thumb size (thus allocating another set of pixels) and either copy the buffer pixels to img2 pixels, or just set the buffer's pixels as img2's pixels (which will cause evas to free the pixels it first allocated for img2, since it will note that the data being set is different from the one it had) -OR- you'd first want to create img2, set its size to the thumb size, get its data, and use that data as the buffer evas' pixels, then render img1. But setting up the buffer evas this way is a bit more subtle. Neither of these are the best way though, not for images. A better way is to set img1's load options to have the image load the file data at the thumb size, and then just save it - that's all. Except of course that won't work for all image formats since it hasn't been completely implemented.. :( > About size option to save, yes, it would be awesome. It's a good way for more efficient thumbing of things like edjes, and also for being able to do custom drawing on image data and have that saved directly. One other aspect I think evas could use is the ability to really set external data on images, ie. have the user set its own data+size+has_alpha, without evas allocating extra stuff. > One extra idea: maybe this thumbnailer could have the > ecore_evas_buffer +2 image objects created on the master process > and used by children processes? Maybe this help a bit since it would > be just a copy on write, no calcs would have to be done... maybe > just a minimal saving? Do you see any problems with that (some file > descriptors that would be inherited and problems could show?) Ummm... let's hold those thoughts til a bit later
Re: [E-devel] Epsilon problems
I wrote (regarding raster's thumb), > It seems to have an evas-object interface that abstracts away > the 'thumb file' concept and just concentrates on giving you the > display-object you want for a given input 'uri' and desired size > (probably could give more info as well). It's.. kinda nice. :) I wonder if the "fdo standards" could be somehow geared more towards providing something like 'interfaces' of some sort for things like this.. rather than specifying that one should to give large and small image files somewhere. _ Dog supplies that give joy to man's best friend. Click Here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3naZ3vo7pnPMWDZKbC65edgry6H9JU4KlnEAklozN3Ee5KkA/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
I wrote: > I looked at "e_thumb_main" - it saves to eet files directly. > That's not really sufficient for giving flexible thumbnail-file > saving functionality for others to use - it's just too restrictive > ... Having said that, I also just took a quick look at epsilon.. and it seems to me that 'e_thumb' has some nice aspects as well over epsilon - for efl based stuff. It seems to have an evas-object interface that abstracts away the 'thumb file' concept and just concentrates on giving you the display-object you want for a given input 'uri' and desired size (probably could give more info as well). I'm not sure what the real difference is between an "e_live_thumb" vs a 'plain' "e_thumb", though the former seems to want the latter. Well, maybe there's room here for some kind of revamp/merger/ new-thing or whatever that could take the best from both.. But I think that something like this could benefit greatly from: 1. Contrast and compare with other existing solutions, say from kde/gnome. 2. Feedback from people who could use such a thing, say toolkit, fm, wm, ... writers. jose. _ Click for free info on earning your associates degrees. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l8StEIKOKuEUXtIZoRwUDYMvjvRS7bBFdvoSgHrd4cnXnaY/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
Gustavo wrote: > > > - how expensive is evas/ecore_evas_buffer in comparison to > > > imlib2 to generate thumbs; > > > > You don't need ecore_evas_buffer to generate 'thumbs' > > of jpg/png/svg, that's only for generating smaller views of a > > 'general' evas canvas rendering. For example, if you want to > > show a live thumb of an animated edje, or bunch of edjes, or > > just about anything. > > that's why I asked, without any testing I'd say it will be slower/ > overkill... > Depends. If you're already using evas, and want to load and save image files to smaller sized (thumbs) versions, then using evas rather than going thru imlib2 could be faster - certainly for jpegs. Maybe for pngs, *if* you're saving to eet. Evas premuls all loaded non-premul argb data, and when saving back to png it un-premuls back, so we have: png-file-in -> premul -> scale-down -> un-premul -> png-file-out. Which is slower than what imlib2 would do. But, if you save the png to an eet, then as raster wanted to go with the "premul flow", he made it so the no un-premul takes place when saving pngs to eet.. and likewise, no premul takes place when loading pngs encoded in eet (like eg, in edj files). What would be slower is if you went thru intermediate buffer evases to do down-scaling, ie. one would then have: load-thing-at-its-natural-size-to-buffer-evas1 -> resize-evas1-to- thing-size -> draw-it-to-evas1 -> set-pixels-of-buffer-evas1-as-data -of-image-obj-of-buffer-evas2 -> resize-evas2-to-whatever -> set-fill -and-size-of-image-obj-to-size-of-evas2 -> draw-image-obj -> [write- pixels-of-evas2-to-out-file-somehow] this last step either directly or again via setting the resulting pixels of buffer evas2 to another image obj that you'd have created when you 'resized' evas2, and then saving the image obj It's somewhat convoluted. I looked at "e_thumb_main" - it saves to eet files directly. That's not really sufficient for giving flexible thumbnail-file saving functionality for others to use - it's just too restrictive (and not really as fast as it could be in some cases). I think evas needs to add an image saving 'size' option, maybe best done via the current "flags" for saving, so that you can save an image that alreday exists at some size (for whatever reason), to a file at whatever other size one wants. > seems that JPEG loader does respect load_size, PNG doesn't, not sure > about others. Bummer. But it's very easy to finish this off, for anyone who wants to give it a shot.. :) > I'm newbie to this project, so maybe you can help me understand this: > is epeg just a test and the functionality was integrated to Evas's > JPEG loader? This would be amazing. That was raster's great desire - to have the evas jpeg loader do what epeg did, and so did he add that in. :) As to your being a newbie to the project.. I think you've been a tremendous inspiration to everyone here Gustavo, you and your friends and collegues there at Canola. Really. jose. _ Study law at a school near you. Click for more info. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oFGmXCSm0cvWIFZ0N1bFZGJDUQ6vQVhZYPYDKK05IzLH0Ji/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
> > - how expensive is evas/ecore_evas_buffer in comparison to imlib2 > > to generate thumbs; > > You don't need ecore_evas_buffer to generate 'thumbs' of > jpg/png/svg, that's only for generating smaller views of a 'general' > evas canvas rendering. For example, if you want to show a live thumb > of an animated edje, or bunch of edjes, or just about anything. Unless... Oh, oh.. unless we didn't finish off implementing the load-size option for all loaders. I know we did it for the svg loader, and that the jpg loader respects loading scaled-down-by-dyads, but I can't recall if we really did finish off making sure that all loaders respected the load-size option.. need to take a look. If not, then it should be filed as an evas BUG. _ Surf a world without wires. Click now for great wireless Internet solutions! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mFpiycmcZ4UgiHjwK5y5QltR0iyZyopTyddMt9vTAwuygac/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
> > As raster mentioned, and as I believe, the best thing for epsilon > > would be a rewrite using evas instead of imlib2... something > > extremely similar to e_thumb. Raster said that if this did occur, > > e would likely change to using epsilon as well. If epsilon is still using imlib2 for creating thumbs, it must be either because at the time it first appeared evas could not then save images to files, or maybe because it wanted to use more image loaders/savers than evas had (evas had built-in jpg/png/eet only at first, or rather at second - at first it also used imlib2 for loading, and the original-original evas used imlib2 for drawing too). If so, these two issues should no longer be relevant: evas can save to files, and one can write as many loaders/savers as desired. In fact, I think that imlib2 doesn't have an svg loader, which evas does. Any special-purpose loaders that one may want for epsilon, but not in current evas, one could write expressly for epsilon if desired. On the other hand, uing evas for simply loading and saving 'thumbnails' of a couple of images is somewhat of an overkill.. but not if you're doing many. > - how expensive is evas/ecore_evas_buffer in comparison to imlib2 > to generate thumbs; You don't need ecore_evas_buffer to generate 'thumbs' of jpg/png/svg, that's only for generating smaller views of a 'general' evas canvas rendering. For example, if you want to show a live thumb of an animated edje, or bunch of edjes, or just about anything. > - saving to eet the uncompressed data really help? Ok, this is > more about testing on our hardware, but maybe it will not help > and it's cheaper to uncompress a JPEG than read pixels from flash > (flash slowness versus cpu usage). In that case, what's the best > option to save the image as JPEG? Create an evas_object_image on > the same canvas, set it's pixesl to buffer pixels and then > evas_object_image_save() it? Saving what to eet? Thumbs of jpgs/pngs? Depends what you want to do with them, and how many... The "best option to save the image as JPEG" is somewhat hard to say - it depends on the context you're working with. But if you're using evas, and you want to use it to load and save 'thumbs' of jpgs back as jpgs, then just create an image object (hide it), set the load size (evas uses the same 'quick' thumbing mechanism for jpgs as epeg), set the file, and then save it to the thumb file (use flags for jpg quality and compression), repeating for as many image files as you want. Or if you want to do this in a separate evas, then create a buffer evas and then do as above. > Also, what to change in e_thumb to make it the perfect "epsilon"? > fdo-compatible saving? Use epeg? What is "fdo-compatible saving"? A more general question would be: What does epsilon not have right now that would make it better for people's needs? Any capabilities it's missing that people want? Any api additions or modifications anyone have in mind? jose. _ Discount Online Trading - Click Now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mJ8XfD6Y4cnWo37eHOLUtROMi38mJQe5Buj2XyWLbBt0ctS/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] News from the E stables
Michel wrote: > On the 3D topic, I've read in this list that many people want > to keep away from 3D rendering. I've no problem with that. > > But improving the 2D rendering with some tricks using GL is > the sort of things I'd like to contribute to ;o))). > As to the gl and 3D stuff.. well, as you mention just getting current gl related 2D stuff to work better would be good. There's also something that's been mentioned before, which is to have engine-specific 'data' for setting on evas image objects (for an evas of that engine), in the case of the gl engine this would be texture and/or pbuffers. This would allow people to draw to evas image objects using gl. One could use this with various libs that give gl based drawing, or import 3D stuf, or allow for toolkits to give the equivalent of "gl widgets" for people to draw on with gl. Similarly, one could have an evas gl engine that draws to a texture or pbuffer rather that the current one that draws only to the standard gl buffer. You might also want to speak with Cedric, who mantains the evas-software-sdl engine and ecore-sdl, and see if maybe an evas-gl-sdl engine might be desirable, maybe write the gl backend for that to be different than the current gl backend that evas uses for the gl-x11 engine. Maybe see if something like 'ecore-gl' might be something that makes sense. Jorge (aka. turran) also nice work going on with the "enesim" gfx lib, and maybe you could speak with him about having a gl-based backend for it. > Anyway, maybe there is also good stuff to do in E config part ? I'm sure there is.. it's just a question of wether or not your experience and interests might be best served by looking into that vs other areas. On the other hand, maybe you could do that now and move on to other stuff later, ... or whatever. :) jose. _ Click here for free information on earning a criminal justice degree today. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nNLMdfdsFhx4XFTEBPdLxGYYAPGkKPa0X1KRwxY69Fp0EMw/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje editing proposal
> > One 'problem' with an edje api for getting/setting properties > > is that it exposes edje's internal structure more and more.. which > > may or may not be desirable. > > > The api I have in mind don't have this exposure problem: > I don't want to return pointer to the internal structs, > but only the asked value: > ... I understand, but it's not that you're exposing actual internal structs, just that one starts to expose more and more properties that are part of the edc description (and some also just happen to be part of edje's current internal variables). Some of these might indeed be useful to query (eg. maybe the list of parts, their types, and such), but others may not be that finalized or whatnot. Again, it may or may not be useful to have those kinds of edje api funcs, but in the end it's really the '.edj' eet file that you really need to work with, ie. you really want to have an eet_edj lib for working with .edj stuff that is general to the edje lib. > I have never looked at eet... but this raise to me a question: > after the edje has been modified in memory, how can I save it > back to the edje/eet file? That's one of the reasons why working directly with the edj eet file would be useful. You're either going to have to add edje functionality for 'saving' from an edje object, or you use eet to read/write the edj file you need via a suitable api. It's been a looong time since I last really looked at edje, and I've forgotten most of what I never really gathered then anyway.. but it seems to me that all these things are best dealt with working with the .edj eet file. You may even be able to get away with simply calling an edje_reload api function in order to get the edje to re-read and update all relevant data in its file/group that has changed.. so, you just work with the edj file and modify that as you wish. I tell you what, why don't you take a few days to look at not just edje, but eet and edje_cc (maybe embryo too), and maybe speak with raster, tilman, and rephorm (if he has time), and then we can pick things up again then if you haven't become an "edje-expert" by then -- I'm certainly not one, but I do know that there's a lot of stuff that can be done to make edje better. :) jose. _ Free information on the best online trading options. Click here! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mJ8YAXV47QvcaC1zvDK8fir8qwrGHtxCfkMWWKWqMEdzlOI/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] News from the E stables
Michel BRIAND wrote: > ... > I'm skilled in > ... > -3D scene graph and rendering with OpenGL > ... > > I like very much the E config scheme that Raster ask me to > look into recently... Raster asked you to look into E config.. as opposed to maybe getting the evas gl engine working better? (need render-to-texture support, bugs in this and that, better implementations of some things, maybe using meshes for bordered scaling,...) Maybe some gl work on the compositing manager.. Or other potential new projects/ideas that could add 3D stuff to E? Maybe you could tell him you're busy or something.. :) _ Discount Online Trading - Click Now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mJ8YHAGRUXTiUvi7D0Y5WcmJOmsRvQZRffWUlVGOjdQSDIs/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje editing proposal
Yet one more bit here (as I slowly regain my "E" memory), One other thing of relevance here is the notion of "styling". Just as xml based formats like xhtml, svg, ... allow for styling via css, ie. allow for one to vary certain values of properties of a 'src document' (but not the structure), one could also have a similar notion for edje (edc syntax based or not). Brian and I actually discussed this a bit, back when the 'GROUP' part stuff was added, but we got side-tracted with other things and never followed up on it (we also discussed things like perhaps having loadable modules via a 'PLUGIN" part type, and a couple of other aspects..). But again, useful as such a notion itself might be, it only deals with varying the values of certain existing properties of an edje group, not with varying the structure, eg. one could not use that to add/remove parts, etc. jose. _ Click here to get free info on vending machines and vending service. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oCSwRH7I0Q44SQNH6aFIVh6jBY1jDRtxpNZ07neSurFn7CY/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje editing proposal
I wrote: > Things like edje-editor and evolve could've been much further > along if these kinds of issues weren't there.. and it's where having > used already existing tools for 'edje' could've helped. > One could have other formats/scripts as inputs to create > eet-encoded .edj files (I believe Tilman's "redact" is somewhat > like that), but it still leaves needing an api for the edje lib > to dynamically create/modify edje objects, to query properties, > determine structure, dependencies, etc. Just to add another bit to that.. One 'problem' with an edje api for getting/setting properties is that it exposes edje's internal structure more and more.. which may or may not be desirable. Another way would also be to have a function like the current 'file_set' one, but which would allow one to set raw eet binary data. Then, different apps/libs could use different formats/syntax/ whatever to work with and just convert this to eet binary.. feeding that to the edje in order to create/modify it. It would be up to the app/lib to keep all relevant state rather than getting/setting such via edje lib calls. However, in order to modify edje objs loaded from existing edje files, it would help to have available an eet-binary read/write lib that could do the querying of stuff.. and that would bring things back to a good api for that. There are also some caching related issues, especially if you start trying to deal with image sources and such, and other stuff, that could come up here. jose. _ Click now and choose from a selection of top performing bonds! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m5XftFiNIajJGI0DiwHsSnaqHaYAnF8fkJ5bkoeyFO4myAg/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje editing proposal
I wrote: > Isn't what you're after (in full) something akin to a 'DOM' > kind of capability for edje/edc? I believe Brian and Chady had > expressed an interest in this at some point as well. Just to add a bit to that.. Hisham had also expressed a similar interest as well. For his work on "evolve", he wanted to be able to dynamically create/modify edjes, and also a similar DOM-like ability for 'edc' syntax based stuff in general. Things like edje-editor and evolve could've been much further along if these kinds of issues weren't there.. and it's where having used already existing tools for 'edje' could've helped. One could have other formats/scripts as inputs to create eet-encoded .edj files (I believe Tilman's "redact" is somewhat like that), but it still leaves needing an api for the edje lib to dynamically create/modify edje objects, to query properties, determine structure, dependencies, etc. jose. _ Discount Online Trading - Click Now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mJ8YXJYBzXrE65SCgiMv5YEHxlVMfuPcENbn6IjMhUbYovG/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje editing proposal
Dave wrote: > > > > Nothing more for now as this require some addition to the edje > library and first I want to hear the voice of the mantiners: > This is the first stub I have done of the new api I'm not one of those voices, but there's something curious here. Isn't what you're after (in full) something akin to a 'DOM' kind of capability for edje/edc? I believe Brian and Chady had expressed an interest in this at some point as well. jose. _ Make the world a better place. Click now and become an international volunteer! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mjVCRjG5s1VEyOZ57w7FCohi2Ca9XHOEfsLxj6y7XMUWftG/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] News from the E stables
Michael BRIAND wrote: > LOL > > it's a sort of dangerous journey... being stuck into a words > demonstation like this... Not at all. I know that KainX is just extremely rigorous and demands a lot from himself -- and others. He showed me that he did indeed know what he was talking about, and I'd been mistaken. He just didn't realize that I had no idea what "HTH" means, so I just started imagening what the hell it might be.. and given all the talk from the stables and all the hippocritters around, that's what came to mind. BTW, is there some area of "E" that you feel you might like to work on? Some area you have some experience in? jose. _ Click to find local singles for dating, romance and fun. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nguDj2o28bEIEvw8ZNU7TvKjLxhDw9OViT55SocKAeLzh1G/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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] News from the E stables
Morten wrote: > > What does "HTH," mean? > > "Hope That Helps" Ahh, thanks. I kept seeing things like "Hitting The Hay", "Higher Than High", "Hotter Than Hot", "Humping The Hippo", ... ? and was having problems visualizing Michael and the ... (just kidding MJ. :) ) _ Click for a free comparison on healthcare coverage and save 100's. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m3B8eFrS6PyPJK8DDXP4S8h2UJ4Kws67ztyb8v04TuDA8Gk/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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] News from the E stables
Michael wrote: > > So, either I misread your intended meaning, or you've > > misread mine. You decide. :) > > You misread mine. "Of course" was used as a conjunction, nothing > more. I could have said "however" or "but then" or any number of > others. Had I meant "of course" as a way to agree with Simon, > (1) I would still have needed a subordinating conjunction to > introduce the subsequent dependent clause; and (2) I would have > needed a semicolon instead of a comma since "of course" would > have been a complete thought. Ah Of course! > HTH, > Michael What does "HTH," mean? _ Save on an Orlando Vacation. Click Now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nK7uN4h1gZogDkXBihmOoxHmIVnxyBn2guIfGQLaMq0smOc/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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] News from the E stables
Michael wrote: > > It does sound a bit hypocritical. I would disagree with both > > you and Simon on this. > > But my only point was that he was being hypocritical, so you can't > agree with me and then disagree with me. That makes *you* > hypocritical. :) Well, not quite. You did in fact make the point that you agreed with Simon that there shouldn't be several toolkits -- or at least that's what I took you mean. Here's the original whole of it: > > There is no good reason to have three different toolkits in > > the same project, > > > Of course, this is what a lot of other people said about Etk back > before it got thrown in CVS. So now you sound hypocritical. I took your "Of course,..." to mean that you agreed with Simon that there were no good reasons for having Where I disagreed with both you and Simon was that aspect, not your subsequent statement that he sounded hypocritical. So, either I misread your intended meaning, or you've misread mine. You decide. :) jose. _ Find loans exclusively for members of our military. Click now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3olPs8caOkTRZ9dmwf6Ox3Tzb60vxe6jMOPbQaGrjEmjyVQk/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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] News from the E stables
Michael wrote: > > There is no good reason to have three different toolkits in > > the same project, > > Of course, this is what a lot of other people said about Etk back > before it got thrown in CVS. So now you sound hypocritical. It does sound a bit hypocritical. I would disagree with both you and Simon on this. I tend to see apis as languages anyway, and consider both etk and ewl as different C "bindings" to the more abstract concept of gui widgetry and such stuff. There are good aspects to this, just as there are good aspects to having other programming language bindings to a given C api. There are bad aspects as well.. some amount of duplicated effort and other things. But if the developers of all these various 'bindings' would cooperate better, would actually work together to further some shared common goals, then the benefits eventually outweigh the negatives. They don't have to love each other, or agree on everything. It may that at some point much further down the road these could be 'supplanted', or they could 'merge', or they might continue, or maybe something else... who knows. Some may prefer ewl, some etk, others something else, and others may want to write things independent of either one. Having such choices available seems closer to the claimed 'spirit' of E than imposing one-true-toolkit or whatnot. From a practical point of view, etk offers people an easier path from the well known and widely used gtk toolkit, and that's something that all who feel a shared grounding in the common E project should see as valuable. Let's take the high-road and value and appreciate both these excellent sub-projects and the work of their talented developers. jose. _ Get a life insurance quote online. Click to compare rates and save. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oib3C2cjGpOZN5cnWBf4SFbQ2ToWOEqbHUubsDNtmE6NmFy/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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] larger gadgets/shelves?
> > If the desktop (and/or fm) component can do whatever it now > > does with "icons", and whatever else it does with "gadgets", then > > why can't it do anything with "whizblings"? Or with "wambots", or > > with . ? > > > you can. its a few trivial lines of module code to go put any evas > object on the desktop. anywhere. a few more to allow you to just > move it around anywhere - and a few more to resize. if you REALLY > want that. a shelf is NOT THE SOLUTION TO THIS. tyring to use the > shelf shows a fundamental mis-understanding of e's internal code > and how it all works, and just how trivial it is to do it yourself > with custom objects. You mean to tell me that someone(s) could write say a lib that has some sort of api for creating "worblets", which beasts are displayed as evas objects of a given evas canvas, and this could be used, via a suitable e17-module, to display such things on the e17 desktop? Maybe even on particular virtual desktops? How about on an instance of a fm view? Could they maybe use ewl or etk or python-efl or ruby-efl or ... to write such a worblets lib? Nah, I don't believe it. Show me the "big-clock" example. :) _ 0% intro APR on Balance Transfers Fraud protection and cashback bonus. Apply now! http://thirdpartyoffers.juno.com/TGL2121/fc/JKFkuJi7DeW1Oc5ATbJdnIUIPaZcu8JJ4rvdzT3WjCtIFJxcX9cdbq/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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] larger gadgets/shelves?
Gustavo wrote: > I'm using a shelf at the right border with size set to HUGE > (120px) and below all windows so it can be nice and use > transparency, staying at the bottom of my desktop and working > like KDE's superkaramba, GNOME desklets, Windows Vista gadgets > and ... > > It works great, I'm using calendar, clock, forecast, cpu > frequency and battery. Most looks good, but some could use > better the big space, like calendar could scale the font, > battery could be centered (with power indicator relative to it). > > I tried to fix calendar and could make some improvements, but > it's hard to make things good at 40 and 120 pixels... also, > 120 pixels is not that big, it could be 256 easily... > > So, my idea is either to provide larger shelf size or provide > another shelf category, maybe desktop applets, that could be > placed everywhere (if it makers hard to efm icons, then maybe > disable those or make this new shelf attached to borders, with > icons evicting it). Larger shelf is easy to add, just change > the max constant, but I really thing the other option is more > interesting, we could have more specialized applets, like, > the calendar view could toggle between large Month-Day/Week-Day > and full edje-beauty calendar, other modules could provide more > information, like forecast could provide more info on click, > using Edje, instead of opening another popup... but how feasible > is this? Whats the directions to implement this? Ahhh... the desklets/applets thing. :) There was a thread about this sometime back. I have some questions about this myself.. Like, what exactly is an "icon"? (vs. say a "gadget") How does a fm (or a wm) know how to 'draw' such a thing? Where does it get info about the thing so that it knows what to do about it? If the desktop (and/or fm) component can do whatever it now does with "icons", and whatever else it does with "gadgets", then why can't it do anything with "whizblings"? Or with "wambots", or with . ? jose. _ It pays to Discover. Apply now! 0% into APR on balance transfers. http://thirdpartyoffers.juno.com/TGL2121/fc/JKFkuJi7EM0epMP0mou33qRPD9g8ZCKxKmBsOfUsEE0ICmUwcRCdTq/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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] News from the E stables
Simon wrote: > > I hope that everyone can be just as excited. I know I am. > > I smell a new age of... Enlightenment. :) :) > > I'm really excited about this too! Especially about the new > communication plan! I actually even think we should do more on > the communication point. It would be great to establish a roadmap > for example, with a list of items to get done in priority, for the > different release-candidates, with eventually some mock-ups. It > would also be good to have a place where designers or users could > share easily some UI ideas. And not only for Enlightenment itself, > but for all the libs/apps around E. > A good thing to do too would be to *really* define the scope of > the project. Are we just doing a WM, or are we aiming at something > bigger? > If this is something bigger, what should be the caracteristics of > an E-app? Should it just use EFL? Should it be sexy? These questions > would have to be answered if we want to get somewhere imo. Ok, so what is it that you want raster to tell you here? He's already made it clear that his main interest is in the wm and the core efl libs, and that's likely all he really has time for - besides everything else. But again, since he's the "project" leader, things like this keep being thrown at him. Do you really want him to be responsible for the direction of etk too? Or maybe just bless it as the 'official' raster-sanctioned gui toolkit? What happens when something like etk or ewl, or some other large 'thing' whose scope in many ways overlaps or even overwhelms the scope of something like the wm, is also part of the "E" project? If raster says "...we need to...", or "... I'd like to see...", or something similar, then is he speaking for all "e", all projects, or just for e-the-wm, or what? Or if he doesn't say anything about 'myProject' then is it irrelevant to "E"? You're the "project" leader of etk Simon. What do you want to do? How about a framework like javaFX, or Mozilla's xul, or MS's xaml? Would that be something you'd like to see? What are your thoughts on the future of graphical UIs? Do you have a 'roadmap' for etk+whatever? jose. _ It pays to Discover. 0% Intro APR. 5% cashback bonus. Apply now! http://thirdpartyoffers.juno.com/TGL2121/fc/JKFkuJi7D6pVbTzJh1jOy7MhejicTzlUY9Bsj7P81ToRL02ZpPJAgw/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] News from the E stables
Hisham wrote: > mailing list / #edevelop and off) share your same opinions. > So, whats next? I don't know what's next - we're ALL going to have to determine that.. Carsten proposed some very good steps in his initial email. But I do know what's first: It's to get these kinds of things understood, so that others can proceed - in a coherent, constructive way. So the mistakes of the past aren't done again. jose. _ 0% intro APR on Balance Transfers Fraud protection and cashback bonus. Apply now! http://thirdpartyoffers.juno.com/TGL2121/fc/JKFkuJi7DiZ09s7WZLuyxaGdo1k80jzvrOghUkcw9WgTWwqaPpeEzO/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] News from the E stables
Hisham wrote: > > As I have talked to both, a lot, about this matter, I'm starting to > develop a feel to the true issue here. > > . The 'problem' here is actually deeper than some of what you mention Hisham. Imagine for a moment that you try to build something like an automobile, or an aircraft, or a tv set,... in the same manner that E 'works'. Well, maybe you can - and I guess e-the-wm plus some 'core' libs, are something like that.. But at least everyone knew that's what was being built (more or less, that wasn't all that clear at times). Now, you want to 'build' something more? Like what? Gee, I don't know.. maybe this here, maybe that there... Well, just go do it.. get it done, if you want. Hey look there, someone did something like a fm, or a media player, or a blimey lib, or a gizmabob,... Hey, do "we" need this.. how about "let's" do that... Nah, I think "the" website should say.. U, I wonder. If one of those 'things' is something like a "development platform", how well that approach is going to work within the context of "E" as the 'parent' project. jose. _ It pays to Discover. 0% Intro APR. 5% cashback bonus. Apply now! http://thirdpartyoffers.juno.com/TGL2121/fc/JKFkuJi7D2mRiufwWGlfgNMPkiWWsUHNj5OdgTjNR1tEkz5r649OtC/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] News from the E stables
That last email: > > > > so what you want is me to simply say "yes yes - do whatever you > > want" > ... > > No, I want you to put on a big "E" logo outfit and dance around > and the next/first e "rave". But that's just me. > > Anyway, let's leave this. Concentrate instead on making all > those things you say you want "E" to become - happen. was supposed to go to raster, not the list! I'll leave it at that. :) _ 0% Intro APR. 5% Cashback bonus and Fraud Protection. Apply now! http://thirdpartyoffers.juno.com/TGL2121/fc/JKFkuJi7DSOiTfamxVodGSNt9bZfz31rz5DVYt8qs4qslABQrzCyfu/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] You and e.
Carsten babbled endlessly on: > > so what you want is me to simply say "yes yes - do whatever you want" > ... No, I want you to put on a big "E" logo outfit and dance around and the next/first e "rave". But that's just me. Anyway, let's leave this. Concentrate instead on making all those things you say you want "E" to become - happen. _ Click for your daily horoscope, learn about money, love & family. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3ly8liAloDl1iUL4z14i89T0hMgXdVLho4CH9EEDrrtJQOcI/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] News from the E stables
Carsten wrote: I'll keep this short, since I really don't want to prolong this sub-thread between us. > > > > Busy or not, you've never expressed any interest or support > > for seeing this project become a true community one. > > i have done just he opposite - i have encouraged people to > DO THEIR OWN THING. most of the time people come and ask me or > > > i now have more time. regardless of tyring to get people to just > take things on their own shoulders and do it - tonnes of things > just end up back in my lap. i have retracted what it is i do to > a small subset of whats in EFL and CVS. i ignore everything else > and let others handle that. > Ummm. > but community does NOT mean everything goes through me. i am a > single point of failure. i want people to stand up and be leaders > on their own - stand on their own 2 feet and be counted. Exactly. And for that, you can't really have ONE person who has basically ALL decision making authority. Some devs just recently brought up the issue of using git instead of cvs, and while there were varying points of view on it, the bottom line seemed to be that YOU don't want to move things to git - not that there was a concensus on that, or that people were not going to be responsible, or whatnot. It's that you don't want it. Why would anyone even contemplate doing anything that you might not want? I have the feeling that you and I have two radically different notions of what a "community" means, and I guess we'll just have to leave it at that. jose. _ Click here for free information on earning a criminal justice degree today. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nNLNOuOffGwFODijHteRRiRuNrlMhQ0MmdB0tbXSljbkxa4/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] News from the E stables
Carsten wrote: > First. > > I need to offer some big apologies. I have been pretty bad at being > . Well, I'll give you my own thoughts on this. These new "developments" in E may well be exciting new opportunities and whatnot, but for some e-developers at least, there are long-standing historical issues with this project. What you call your 'lack of leadership', some saw rather differently. Indeed, some saw it as a good approach, a benevolent- dictator kind of approach. Maybe they're right, and that is a 'good' way to develop something like a wm plus its supporting libs.. but it's not likely to scale well much beyond that - eg. to scale to something like a serious development platform (unless perhaps you envision the wm+modules as a kind of limited platform itself). On several ocassions, some developers here have brought up some of the things you seem to be addressing now - essentially, to have the project run as a true 'community' project. But, they were either ignored, brushed-off, or even treated with some hostility. Busy or not, you've never expressed any interest or support for seeing this project become a true community one. Why the sudden change of heart? Because you have a new employer and can now be the "leader" you say you haven't had the chance to be? While I applaud your statements to (finally) want to see this project move in the direction of a true community effort, and I believe the things you've proposed are good... Do you really expect everyone to feel warm and fuzzy all over, ignore the past, and joyfully embrace this 'new age of enlightenment'? I hope they do, honestly - but I think that it's not going to be that easy.. not for those who were satisfied with the "old order", and not for those who've questioned things and called for change before. jose. _ Click for your daily horoscope, learn about money, love & family. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3ly8kw6Kq0SdgSaubx9a4J7TZF52NdjtfrVt8447rKt2qTQc/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas, Fonts, cache and performance
Gustavo wrote: > so, how to speed up text rendering? raster suggested me to create a > render cache so scaling, font and etc would be cached and maybe ... There are several basic ways, associated with 'caching', by which drawing styled text could be optimized. 1. At canvas level, 'draw' to engine provided "render buffers", and cache these on a per-obj basis as need be. pros. Easiest to implement. Would provide such buffers for other uses. cons. Some engine renderers, eg. gl, would need work. More mem use per-text-obj. Possible issues with some render-ops. A 'coarse' kind of optimization, more involved at the canvas level. 2. Cache styled glyph 'components' as alpha (and/or color) masks. pros. Fastest way to draw large amounts of styled text. Least per-text-obj mem use. Can be extended to cover other text styling. cons. More involved implementation. 3. Similar to 1, but cache result of drawing, at engines level, to alpha (and/or color) buffers, using separate buffers for style 'components'. pros and cons. Between those of 1 and 2 above. Or any combination of the above.. as desired on a per engine renderer basis. In general, 'object rendering', at the canvas level, should be 'atomic' -- ie. avoid drawing manipulations (that involve an obj's internal state) at the canvas level. Many extensibilty and optimization issues that evas has, stem from doing drawing manipulations at the canvas level. 1 above would bypass having to make text drawing atomic, but would be the easiest one to do. jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
> > about that, why not doing a branch in cvs ? Branches exist for > > that kind of stuff. > > a perfectly sane idea. we use branches rarely - but this is a case > where it would be good. we should add jose to the cvs access/devs. > jose - if you want, send me your ssh public key (id_dsa.pub in > ~/.ssh) then fill in this "developer info" form: > > Login:??? > IRC Nick: ??? > Name: ??? > Location: ??? > E-Mail: ??? > WWW: ??? > Managing: ??? That might be a good idea, evas internals do need a fairly large reworking if the lib is to be able to expand in capabilities, and it may also lead to other work being done that might not otherwise be attempted. As to "cvs access" for me... Well, as you know Carsten, this is something I've not wanted (for several reasons we don't need to go into here). It's been a bit of a pain for both of us sure, but so it goes.. :( Maybe at a later point in time. I'm going to take a month away, or maybe two, for now.. hopefully some interesting stuff (besides in evas or e17) will be further explored over that time. :) [eg. Simon's 'glade-like' ideas, and I think a good 'desklets' lib of some sort (with a suitable description format) that would allow for edje based gadgets (not tied exclusively to e17 please) like clocks, rss-feeds, maybe a simple text-entry gidget, and things of that sort.. would be useful and interesting. Maybe a list of ideas/projects/needs/... that "e" as a whole could benefit from would be good thing for people to stare at.. ] See you in a bit. jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
Gustavo wrote: > Great you're already doing it, at least it will serve as reference > if not integrated/used... is there any CVS/SVN/GIT/... we can follow > and do some testing? None except my local copy.. and as it's partly working, partly in the process of being worked out.. until I feel that it's something that's complete enough to be 'usable', it'll likely stay that way. It may well stay that way in any case, if there's little or no interest in having this in evas. In fact, given raster's recent remarks on this, I'm rather inclined to just let it go as of now. It'll have to wait til he decides to get to it instead. :) jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
I wrote: > Let's take your example of an 'evas_object_transform_set' > api function that you want. > Ok, when you come to actually implement this, you will add > some 'transform' to the evas object structure so that all objects > keep the transform state. Then, when the canvas calls the object's > render function it needs to draw the transformed object.. so in > each object's render function you need to 'implement' the drawing > of such a trnasformed object. > > But, you can only call 'engine functions' for this.. that's > ALL you can work with. > > Suppose you then want to be able to set a 'filter' object > on an evas object, eg. to blur, bumpmap, ... an object. Again, > you will add such state to the evas object structure and in each > object's render function you need to 'implement' the drawing of > such an object with such a filter, and with the transform you > wanted for the object before, and maybe the filter itself admits > transforms, and maybe you have the object clipped by an image > object and this image object has borders, and is itself transformed > in some way, and possibly another filter is being applied to it, > and the image object has another clip object which is a path which > is and the object you're drawing is a rounded recangle, which > is to be stroked with some color and filled with some gradient > texture, and the gradient is a radial one, and is trasnformed in > some way, and... > > And all this you have to 'implement' via the set of "engine > functions" beacuse that's ALL that the canvas can access to do > anything. That set of engine functions is the canvas' gfx api, not > the actual engine gfx backend apis. > > See the problem? > > Fortunately, there is a way to do this. :) I should've added: and that involves a very large rewrite of the engine level internals. There is no way to avoid this -- if one wants evas to be able to do much of anything beyond what it now does. It's what I've been working on recently.. but it's a large amount of work - in itself not necessarily 'difficult', but a lot.. with many, many details. Not to mention that I had to work out a fair amount of other things, like a reasonable mechanism to do such clipping, and image fill-transforms, and textured stroke/fill of rounded rects, and try and figure out a better way to deal with styled-text (eg. something like what I did sometime back with imlib2 text-styling), and clean-up and improve a bunch of things... And it's going to take yet more time and work to finish off a lot of it still. jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
> > The way Carsten setup clip-object semantics in evas is > > that any object can clip any other, and this can be arbitrarily > > iterated (since a clip object can have a clip object as well). > > Also, an object can clip any number of objects. > > right now clip is all about rectangle operations to limit the visible > are... or is anything else supported? Nothing else is 'supported' except plain rectangles, but it was intended as decribed.. and the canvas level does try. :) > > The way the internals are set up, it's just not feasible.. > > and neither is doing *anything* much beyond what raster initially > > set things up for (eg. rotations or any kind of transforms on > > image objs.. just can't really be 'done' right now, no matter how > > 'easy' it might be to accomplish that with any of the gfx > > backends). > > I don't get what you mean with rotations/transitions. > If clip object is rotated, then you'd consider it rotated and > you're done, just like you get its current size. > In order to minimize work, we could do regular bounding box clip > and when to process scanlines, segment it into intervals, these to > be segmented by the next clip object and so on... > In the end you get the continuous segments you would > blit/blend/transform (in the gradient case). That's one way, software-wise. But it's just not the issue here. > > Do this, and all the things everyone wants for evas to be > > able to do, and things that no one has maybe even thought of... > > will at least be feasible to *attempt* to implement. It simply > > isn't feasible or reasonable right now to even try otherwise. > > Well... moving everything to engine will leave us with just a common > API and very different implementations, that will be really > extensible, trade off is consistency, complexity and possible more. > > If we extend clip to be any polygon or curve (if we allow ellipses, > circles, ... in future) and also enable cumulative transformations > we can do many things without all that pain. The former is not > difficult, since well known algorithms exists, the later is more > related to implementation details, while I know it's possible to > do JIT and remove overhead of functions, just getting the operations > on i686+software_x11, I'm not sure if it fits other sytems (GL?)... > if we trade off memory in favor of performance we can always render > to an auxiliary buffer and then do some operation (sub, add, or, > and, mul, ...) while rendering clipped objs. > > That's my understandings so far, I don't know any engine or even > the API that well, if I'm wrong just let me know. Well, you see.. the issue here isn't really about being able to implement things with software algorithms, or with some other gfx backend (gl or xrender or cairo or whatever). All that can be done. The problem is that evas just won't let you even try, not without extensively rewriting a large amount of things. Again, the way the internals are setup, every evas object calls a generic 'render' function to draw itself.. and this is an abstract kind of function since the rendering target and the rendering mechanisms can vary (different engines). But, this render function doesn't get directly implemented by the rendering backends. Instead, it uses a set of abstract 'engine functions' which are themselves what get implemented by each rendering backend. Those functions are what the canvas can use to draw an evas object.. and ONLY those functions. Let's take your example of an 'evas_object_transform_set' api function that you want. Ok, when you come to actually implement this, you will add some 'transform' to the evas object structure so that all objects keep the transform state. Then, when the canvas calls the object's render function it needs to draw the transformed object.. so in each object's render function you need to 'implement' the drawing of such a trnasformed object. But, you can only call 'engine functions' for this.. that's ALL you can work with. Suppose you then want to be able to set a 'filter' object on an evas object, eg. to blur, bumpmap, ... an object. Again, you will add such state to the evas object structure and in each object's render function you need to 'implement' the drawing of such an object with such a filter, and with the transform you wanted for the object before, and maybe the filter itself admits transforms, and maybe you have the object clipped by an image object and this image object has borders, and is itself transformed in some way, and possibly another filter is being applied to it, and the image object has another clip object which is a path which is and the object you're drawing is a rounded recangle, which is to be stroked with some color and filled with some gradient texture, and the gradient is a radial one, and is trasnformed in some way, and... And all this you have t
Re: [E-devel] RFC gradient clip
Gustavo wrote: > I want to know how difficult would be to implement support for clip > using gradient objects. > ... > ... > > We are willing to implement it if you give us some hints :-) Just thought I'd go back to this a bit here, and see if I can give you an idea of what's 'really' needed for this. The way Carsten setup clip-object semantics in evas is that any object can clip any other, and this can be arbitrarily iterated (since a clip object can have a clip object as well). Also, an object can clip any number of objects. It's a very nice idea, though with that kind of generality it's going to be tough to do anything involved very efficiently. However, the real problem in evas right now is just trying to get this implemented *at all*. The way the internals are set up, it's just not feasible.. and neither is doing *anything* much beyond what raster initially set things up for (eg. rotations or any kind of transforms on image objs.. just can't really be 'done' right now, no matter how 'easy' it might be to accomplish that with any of the gfx backends). I've pointed this out several times in the past, but let me explain in a bit more detail exactly why this situation exists and what's needed to correct it. The canvas level has a structure that holds the state for an evas object (eg. size, clip-obj, etc). This structure also has a pointer to any type specific state (ie. things for rects, images, etc). It also has a pointer to a 'render' function that is called whenever a given object needs to be drawn - this function is given for each specific type of object, and has a generic form, eg. draw something to some dst at some point... and such things. The way these object render functions are obtained is in turn via certain other 'engine functions' which are implemented by the various engines, ie. by the various rendering backends. The problem is that this set of 'engine functions' then defines an immediate mode rendering api which is ALL that the canvas can work with. It ties the canvas lib's capabilities to the specific rendering model/api that this set of interfaces defines. Unfortunately, the current such interfaces, ie. the rendering model.. is extremely limited. That's the source of all the problems that evas faces right now as far as extending its capabilities to allow for such things as obj transforms, clipping, texturing, and any number of other gfx aspects. Now, one can say "Well, let's use eg. a vgfx rendering model, that's a powerful one...", or maybe say "No, let's use a compositing rendering model, it's more flexible yet smaller...", or any number of other things.. and how is one to choose? (and the choice must make it easy for it to be realized with various other gfx libs. eg. xrender, gl, cairo, ...) Very easily: Let the canvas api be the rendering model, rather than impose some other. After all, what one wants is to modify 'obj' state, setup things, and draw the 'obj' as need be. What that means is that one needs to push all relevant canvas level 'object' state down to the engines level, and let things be implemented there as each 'engine' sees fit. Do this, and all the things everyone wants for evas to be able to do, and things that no one has maybe even thought of... will at least be feasible to *attempt* to implement. It simply isn't feasible or reasonable right now to even try otherwise. jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
Gustavo wrote: > On 5/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Carsten wrote: > > > > > the advice is "i would like this and it would be good" but its > > > not trivial to do right/well and right now i really don't have > > > the time to do it - thus it's one of those backburner "when i > > > get to it" things. > > > > Ahhh... Well, if you're going to do it.. then I'll just > > leave it be. :) > > Well... raster is just one (busy) guy, we could help with some > things, specially because these "when I get to it" things can > (will) be avoided as much as possible ;-) I agree completely with you here.. and I know Carsten is indeed busy. Very likely the emails that breed in his mailbox are about to eat him alive again as well. :) He's right about it being quite a bit of work to get this done. But it's really not that difficult - once things are set up correctly in evas at the engines level.. that's the bulk of the work really. Things can be further tweaked/optimized later if need be. I just personally happened to find his reply to Jason a bit odd that's all. :) jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC evas_object_transform()
Simon wrote: > For the GL engine, you can probably modify the texture matrix to > transform the filling of an image. I'm not sure how well it would > work with borders though (but actually, what borders "mean" when > the fill is transformed?) Two different sets of 'transforms' are involved here: Simon wrote: > For the GL engine, you can probably modify the texture matrix to > transform the filling of an image. I'm not sure how well it would > work with borders though (but actually, what borders "mean" when > the fill is transformed?) One would be those which apply to how the image-fill should behave, ie. border-scale the fill, then rotate/skew that, etc. So, you need to border-scale first to a buffer and then apply any further trans (ie. any rotation/skewing/whatever) to *that* buffer result (and repeat/reflect/restrict as need be). That is basically independent of any engine particulars -- We need to fill-scale to a buffer first in order for the 'pieces' of the image to fit together accurately and without 'seams' when further tansformed and composited. The only way to avoid doing this is if the rendering engine has the ability to deal with the 9 abutting pieces as a 'whole', so that no edges get sampled/composited twice. It's possible that gl may be able to do that via meshes. The second set of transforms would be as applies to the obj as a whole, and there what one actually does depends on what the engines have available as being easiest.. But the semantics would be that the result is that the object as a whole is transformed, after the filling transforms are done. If you think of an image object as a rectangle which has been filled with a "pattern" (in vgfx terminology.. or "textured" as I prefer to call it), then transforms to the image object (as opposed to the fill, ie. the pattern), are the same as transforming the patterned rectangle. :) jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC gradient clip
Carsten wrote: > the advice is "i would like this and it would be good" but its not > trivial to do right/well and right now i really don't have the time > to do it - thus it's one of those backburner "when i get to it" > things. Ahhh... Well, if you're going to do it.. then I'll just leave it be. :) jose. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
