Re: [E-devel] Shared Strings
On Tue, Jul 8, 2008 at 8:52 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > Jorge Luis Zapata Muga schrieb: >> >> Having a common agreement isnt easy but we should make one. Cedric >> ideas of providing a common API and just do some macros is useful, i >> agree that the structure of the code using might have to change, but >> either way a list API of any kind, is more or less common, you iterate >> over it with the next and prev and you get data, the rest is an >> extended API. A big effort has to be made from us to port everything >> on cvs to it, but one time or another this has to be done. >> > > I don't think that an unification of the list APIs is possible. And even if, > we'd end up to change thousands of lines of stable code, which was tested > over many years. And that without any reasonable benefit. Here you'll find a simple implementation of ecore_dlist using evas_list as its backend http://code.google.com/p/efl-research/source/browse the module is called ee_list, you'll see that not every function is implemented but enough to see that there's no difference in the API or in the result. So in my opinion it is possible. IMHO Is not a problem of possibility but of will, if we want to have only one double linked list implementation we should do the effort. The benefits are several, beside consistency on the code, is good for newcomers, every time a new dev come around he asks what list/hash to use and what toolkit, etk/ewl ? (but a toolkit isnt core, data types are). > >>> Iirc, there are some things in eina that raster didn't want to have in >>> the data type. I haven't looked into eina lately, but last time i did he >>> >> >> Well, having some subsystems of eina not desirable isnt an excuse to >> have 5 implementations of the same ;) >> > > We have two string pools and the lib I proposed would reduce it to one > implementation. Yes, i wasnt refering to the string pool itself, but to the list and hash, the stringpool already has consensus, but the latter no. > >> >> If stringshare pool already has a common API between ecore an evas >> ones, why not put that on the current effort of a common data type? >> > > I'm not sure if I understand you correct, but that's exactly what edt was > meant for. When i said "current effort" i meant actually the old edata or eina, as it has appeared on the ml and irc several times. > >> eina should be included into cvs, im ok with that, im kind of >> restrictive to indentation changes, but that's another matter :) >> >> In my opinion the first thing that should be done is add the svn code >> into cvs, then add your stringshare there and slowly port the rest, >> eet is a special case because it already has a release, so it should >> depend on another releasable code (eina) which isnt complete, so eet >> might have to be last one to be ported. >> > > Putting eina now into cvs doesn't help anyone at the moment. There are two > ways we can go: > > 1. First we start with a little lib, where we put step by step code into it, > we agree with that it belongs into the common lib. That's what I tried with > edt. > 2. We first discuss how the common lib needs to be en bloc and in detail and > then change eina to match the result of the discussion. And move it then > into cvs. > > It looks like most people here prefer the second way. > >> I think that a good thing to do is to actually compare both API's and >> try (if possible) to merge them, any volunteer? for the simplest use >> cases of course, get a data from the list and iterate over it. >> > > I don't like the two very much, but I believe we have to keep both > implementations. As I said above, I don't think it is worth the effort. And > about merging them, you haven't much space for that, because eet expects a > evas_list-like API. > - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-07-09 07:10:40 -0700
Build log for Enlightenment DR 0.17 on 2008-07-09 07:10:40 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: edvi http://download.enlightenment.org/tests/logs/edvi.log enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log express http://download.enlightenment.org/tests/logs/express.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, evolve, ewl, examine, execwatch, exhibit, exml, expedite, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
On Wed, Jul 9, 2008 at 2:40 PM, Jorge Luis Zapata Muga <[EMAIL PROTECTED]> wrote: > On Tue, Jul 8, 2008 at 8:52 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: >> Jorge Luis Zapata Muga schrieb: >>> >>> Having a common agreement isnt easy but we should make one. Cedric >>> ideas of providing a common API and just do some macros is useful, i >>> agree that the structure of the code using might have to change, but >>> either way a list API of any kind, is more or less common, you iterate >>> over it with the next and prev and you get data, the rest is an >>> extended API. A big effort has to be made from us to port everything >>> on cvs to it, but one time or another this has to be done. >>> >> >> I don't think that an unification of the list APIs is possible. And even if, >> we'd end up to change thousands of lines of stable code, which was tested >> over many years. And that without any reasonable benefit. > > Here you'll find a simple implementation of ecore_dlist using > evas_list as its backend > http://code.google.com/p/efl-research/source/browse the module is > called ee_list, you'll see that not every function is implemented but > enough to see that there's no difference in the API or in the result. > So in my opinion it is possible. IMHO Is not a problem of possibility > but of will, if we want to have only one double linked list > implementation we should do the effort. The benefits are several, > beside consistency on the code, is good for newcomers, every time a > new dev come around he asks what list/hash to use and what toolkit, > etk/ewl ? (but a toolkit isnt core, data types are). I would also add that it will improve memory profile as we will use the same memory pool for all list. >>> eina should be included into cvs, im ok with that, im kind of >>> restrictive to indentation changes, but that's another matter :) >>> >>> In my opinion the first thing that should be done is add the svn code >>> into cvs, then add your stringshare there and slowly port the rest, >>> eet is a special case because it already has a release, so it should >>> depend on another releasable code (eina) which isnt complete, so eet >>> might have to be last one to be ported. >> >> Putting eina now into cvs doesn't help anyone at the moment. There are two >> ways we can go: >> >> 1. First we start with a little lib, where we put step by step code into it, >> we agree with that it belongs into the common lib. That's what I tried with >> edt. >> 2. We first discuss how the common lib needs to be en bloc and in detail and >> then change eina to match the result of the discussion. And move it then >> into cvs. >> >> It looks like most people here prefer the second way. I will say we have a third option. Put a common lib in cvs now. Then slowly move stuff around to the new system. With current work from caro with Evas_Data.h we should be able to provide a set of macro that will help do the move quickly. This move should not impact performance at all (and looking at eina current code, I don't see how it could change something regarding that). -- Cedric BAIL - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] itask-ng issues
Hi, I have two issues with itask-ng which I'd like to mention, and I hope it's ok to post them to this list. The first thing I'm experiencing is a white bar over the entire bottom of the screen where the instance of itask-ng is located as a taskbar (I'm not running a composite manager). It appears only when e is started or restarted and there are no applications to show in the taskbar. Once the first app is running, the white bar disappears and the the icon is shown normally in the taskbar. However, the bar does not reappear when I close all applications, only when e is restarted subsequently. When I enable composite and run e.g. bling, all is as it's supposed to be, only that composite is neither very fast nor very stable here (ATI graphics card/driver), so I cannot really use it. The behavior described above is there for some time now and unfortunately I cannot link it to a specific date or revision. The second issue looks like an itask-ng problem too, but I'm not entirely sure, maybe something changed in e or the libs. It concerns the icons for minimized applications in the taskbar which normally kind of fade out to show that the app is minimized. Since a few revisions they simply disappear, leaving a blank space. The icon reappears on mouse-over, i.e. when the icon/bar is zoomed, so it seems to affect only the normal, non-enlarged icon. Since I prefer itask-ng over the other taskbar/launcher solutions it'd be nice to get those issues fixed, so please let me know if you need any more information. Thanks and best regards, Nick. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] itask-ng issues
Hello, please post issues with itask-ng at http://code.google.com/p/itask-module/issues/list Am Wed, 09 Jul 2008 20:03:13 +0200 schrieb Nikolas Arend <[EMAIL PROTECTED]>: > Hi, > > I have two issues with itask-ng which I'd like to mention, and I hope > it's ok to post them to this list. > > The first thing I'm experiencing is a white bar over the entire > bottom of the screen where the instance of itask-ng is located as a > taskbar (I'm not running a composite manager). It appears only when e > is started or restarted and there are no applications to show in the > taskbar. Once the first app is running, the white bar disappears and > the the icon is shown normally in the taskbar. However, the bar does > not reappear when I close all applications, only when e is restarted > subsequently. When I enable composite and run e.g. bling, all is as > it's supposed to be, only that composite is neither very fast nor > very stable here (ATI graphics card/driver), so I cannot really use > it. The behavior described above is there for some time now and > unfortunately I cannot link it to a specific date or revision. > this should be fixed with the current svn version > The second issue looks like an itask-ng problem too, but I'm not > entirely sure, maybe something changed in e or the libs. It concerns > the icons for minimized applications in the taskbar which normally > kind of fade out to show that the app is minimized. Since a few > revisions they simply disappear, leaving a blank space. The icon > reappears on mouse-over, i.e. when the icon/bar is zoomed, so it > seems to affect only the normal, non-enlarged icon. > hmm, no idea. does it also happen when using a composite manager? > Since I prefer itask-ng over the other taskbar/launcher solutions > it'd be nice to get those issues fixed, so please let me know if you > need any more information. > > > Thanks and best regards, > > Nick. > Regards, Hannes 'jeffdameth' Janetzek - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] itask-ng issues
Hannes Janetzek wrote: > Hello, > > please post issues with itask-ng at > http://code.google.com/p/itask-module/issues/list > Sorry about that, I will do so for future bug reports. > Am Wed, 09 Jul 2008 20:03:13 +0200 > schrieb Nikolas Arend <[EMAIL PROTECTED]>: > > >> Hi, >> >> I have two issues with itask-ng which I'd like to mention, and I hope >> it's ok to post them to this list. >> >> The first thing I'm experiencing is a white bar over the entire >> bottom of the screen where the instance of itask-ng is located as a >> taskbar (I'm not running a composite manager). It appears only when e >> is started or restarted and there are no applications to show in the >> taskbar. Once the first app is running, the white bar disappears and >> the the icon is shown normally in the taskbar. However, the bar does >> not reappear when I close all applications, only when e is restarted >> subsequently. When I enable composite and run e.g. bling, all is as >> it's supposed to be, only that composite is neither very fast nor >> very stable here (ATI graphics card/driver), so I cannot really use >> it. The behavior described above is there for some time now and >> unfortunately I cannot link it to a specific date or revision. >> >> > this should be fixed with the current svn version > Hm, the latest revision I get is 564, but that's the one I'm currently using. How long does it normally take for commits to become available? > >> The second issue looks like an itask-ng problem too, but I'm not >> entirely sure, maybe something changed in e or the libs. It concerns >> the icons for minimized applications in the taskbar which normally >> kind of fade out to show that the app is minimized. Since a few >> revisions they simply disappear, leaving a blank space. The icon >> reappears on mouse-over, i.e. when the icon/bar is zoomed, so it >> seems to affect only the normal, non-enlarged icon. >> >> > > hmm, no idea. does it also happen when using a composite manager? > No, it doesn't, works fine with bling. But the first problem (white bar) does actually become worse when using composite. I thought I tried it before and things looked good then, but now I get the white bar at startup as well as a semi-transparent "composite-like" dark grayish bar with both the taskbar and the launcher instances every second time I restart e (works like a switch). Best, Nick. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ 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
I wrote: > >>> So, if anyone has any comments, suggestions, issues.. *anything* with >>> evas gradients -- now would be a good time to pipe in. :) >>> >> >> I'd _love_ using gradients, in fact I would use them much more often, >> _if_ not everytime I start using them, it all feels like I'm >> operating a powerful machine that has 100s of controls and I don't >> understand anything. >> >> Perhaps this is an inherent problem from the gradient complexity, but >> I'd appreciate if we had some documentary material that outlines how >> to achieve which kind of results, which gradient type to use for >> what, how many stops for what effect etc. etc. >> > > Ok, let me try and give you a fairly simplified description of what > gradients are basically about, and how evas tries to deal with this.. for > better or worse. > > ... > ... > ... > But to get back to the subject at hand here, and before going on > to give > more details on current evas gradients, let me ask you this: > How would you answer the above two 'general' questions.. or rather, > what would > *you* like to see as an api that would make you want to use gradients > more? > Not much time to reflect on this? Well, that's understandable :) Let me go ahead and review the current set of gradient api funcs in evas, give some criticisms, and propose some changes I'd like to make to improve things there (and yes, they would break all gradient stuff). First, recall I mentioned the two parts involved in gradients: 1) Those aspects related to defining a 1-dim image (or "spectrum" as I sometimes call it). 2) Those aspects related to defining how to map the above to a 2-dim region - and this covers things like the gradient type, spread-mode, and such things. Ok, for (1) in evas we currently have the following (set) api funcs: void evas_object_gradient_color_stop_add(obj, r,g,b,a, int delta); void evas_object_gradient_alpha_stop_add(obj, a, int delta); void evas_object_gradient_color_data_set(obj, *data, len, has_alpha); void evas_object_gradient_alpha_data_set(obj, *data, len); void evas_object_gradient_direction_set(obj, *data, int direction); void evas_object_gradient_offset_set(obj, *data, float offset); and also, void evas_object_gradient_clear(obj); The 'clear' api func removes any stops or data that might have been set before. The 'offset' api func effectively moves the origin of the 1-dim image, this is something that as far as I know isn't supported by any vgfx api/spec (which is unfortunate since it can give very nice animation effects which are otherwise difficult to obtain for some gradient types, eg. radial ones). The 'direction' api func just reverses the start/end of the 1-dim, and though not directly supported by most vgfx apis/specs, it can be easily obtained - it's mostly a simple convenience function. The 'color_data' and 'alpha_data' api funcs are to allow for setting such a 1-dim image with premul and alpha-only data, rather than going thru any kind of procedural description. It's not supported by any vgfx api/spec that I know of, not directly anyway.. though you can certainly consider such data as an equi-distant set of stops and add it that way (modulo some gymnastics with premul data and alpha masks and such). The 'color_stop' and 'alpha_stop' api funcs evas' current procedural descriptions for defining the spectrum -- and these I have real issues with. Not only is this method of specifying stops not supported by any 'standard' vgfx api/spec, the use of the "int delta" as either some kind of 'weight' or maybe 'distance to a next' is somewhat un-intuitive and very difficult to work with for gui editors and such. I propose getting rid of this legacy stuff (inhereted from the equally archaic Imlib2 method), and adopt a more standard method. In fact, let's start from scratch altogether here and let me propose a minimal set of grdient-spectrum related api functions that more closely matches what's given by most vgfx apis/specs: void evas_object_gradient_clear(obj); // keep this one void evas_object_gradient_color_stop_insert(obj, r,g,b,a, float pos); // where 'pos' is clamped to be in [0,1]. Any previous stop at same pos // will be overwritten. Must insert one stop at pos 0 and one at pos 1 // to get a valid gradient spectrum. This and matches what most use. One could then possibly add the following funcs to make it easier/more-intuitive to input, query, and manipulate such gradient stops: void evas_object_gradient_color_stop_get(obj, int index, *r,*g,*b,*a,*pos); // get the value of the stop at 'index', where these are ordered from 0 to // (number_of_stops - 1) according to increasing position. If 'index' is >= // the current number of stops, or index < 0, this does nothing. void evas_object_gradient_color_stop_set(obj, int index, r,g,b,a,pos); // modifies the r,g,b,a,pos values of the stop at the given index
Re: [E-devel] {Spam?} Re: [Evas] possible bug in gradient
On Wed, 9 Jul 2008, Jose Gonzalez wrote: I wrote: I'd _love_ using gradients, in fact I would use them much more often, _if_ not everytime I start using them, it all feels like I'm operating a powerful machine that has 100s of controls and I don't understand anything. Perhaps this is an inherent problem from the gradient complexity, but I'd appreciate if we had some documentary material that outlines how to achieve which kind of results, which gradient type to use for what, how many stops for what effect etc. etc. Ok, let me try and give you a fairly simplified description of what gradients are basically about, and how evas tries to deal with this.. for better or worse. ... ... ...But to get back to the subject at hand here, and before going on to give more details on current evas gradients, let me ask you this: How would you answer the above two 'general' questions.. or rather, what would *you* like to see as an api that would make you want to use gradients more? Not much time to reflect on this? Well, that's understandable :) Let me go ahead and review the current set of gradient api funcs in evas, give some criticisms, and propose some changes I'd like to make to improve things there (and yes, they would break all gradient stuff). First, recall I mentioned the two parts involved in gradients: 1) Those aspects related to defining a 1-dim image (or "spectrum" as I sometimes call it). 2) Those aspects related to defining how to map the above to a 2-dim region - and this covers things like the gradient type, spread-mode, and such things. Ok, for (1) in evas we currently have the following (set) api funcs: void evas_object_gradient_color_stop_add(obj, r,g,b,a, int delta); void evas_object_gradient_alpha_stop_add(obj, a, int delta); void evas_object_gradient_color_data_set(obj, *data, len, has_alpha); void evas_object_gradient_alpha_data_set(obj, *data, len); void evas_object_gradient_direction_set(obj, *data, int direction); void evas_object_gradient_offset_set(obj, *data, float offset); and also, void evas_object_gradient_clear(obj); The 'clear' api func removes any stops or data that might have been set before. The 'offset' api func effectively moves the origin of the 1-dim image, this is something that as far as I know isn't supported by any vgfx api/spec (which is unfortunate since it can give very nice animation effects which are otherwise difficult to obtain for some gradient types, eg. radial ones). The 'direction' api func just reverses the start/end of the 1-dim, and though not directly supported by most vgfx apis/specs, it can be easily obtained - it's mostly a simple convenience function. The 'color_data' and 'alpha_data' api funcs are to allow for setting such a 1-dim image with premul and alpha-only data, rather than going thru any kind of procedural description. It's not supported by any vgfx api/spec that I know of, not directly anyway.. though you can certainly consider such data as an equi-distant set of stops and add it that way (modulo some gymnastics with premul data and alpha masks and such). The 'color_stop' and 'alpha_stop' api funcs evas' current procedural descriptions for defining the spectrum -- and these I have real issues with. Not only is this method of specifying stops not supported by any 'standard' vgfx api/spec, the use of the "int delta" as either some kind of 'weight' or maybe 'distance to a next' is somewhat un-intuitive and very difficult to work with for gui editors and such. I propose getting rid of this legacy stuff (inhereted from the equally archaic Imlib2 method), and adopt a more standard method. In fact, let's start from scratch altogether here and let me propose a minimal set of grdient-spectrum related api functions that more closely matches what's given by most vgfx apis/specs: void evas_object_gradient_clear(obj); // keep this one void evas_object_gradient_color_stop_insert(obj, r,g,b,a, float pos); // where 'pos' is clamped to be in [0,1]. Any previous stop at same pos // will be overwritten. Must insert one stop at pos 0 and one at pos 1 // to get a valid gradient spectrum. This and matches what most use. One could then possibly add the following funcs to make it easier/more-intuitive to input, query, and manipulate such gradient stops: void evas_object_gradient_color_stop_get(obj, int index, *r,*g,*b,*a,*pos); // get the value of the stop at 'index', where these are ordered from 0 to // (number_of_stops - 1) according to increasing position. If 'index' is >= // the current number of stops, or index < 0, this does nothing. void evas_object_gradient_color_stop_set(obj, int index, r,g,b,a,pos); // modifies the r,g,b,a,pos values of the stop at the given index, // where 'pos' is clamped to lie between the prev and next (if any) stop // positions in the gradient, and again does nothing if 'index' >= current // number of stops or index < 0. void
Re: [E-devel] [Evas] possible bug in gradient
forget my previous mail; it was a problem with my mail client sorry Vincent - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ 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
I had worked on the gradient & spectra manager in edje_editor, it is ready now, you will see my work in cvs soon. I have done a cool spectra editor and yes, the 'delta' param is a hell! I agree with you also with the rest of the api :) ...but updating all the code that use gradient could be paintfull... Dave - "Jose Gonzalez" <[EMAIL PROTECTED]> ha scritto: > I wrote: > > > >>> So, if anyone has any comments, suggestions, issues.. *anything* > with > >>> evas gradients -- now would be a good time to pipe in. :) > >>> > >> > >> I'd _love_ using gradients, in fact I would use them much more > often, > >> _if_ not everytime I start using them, it all feels like I'm > >> operating a powerful machine that has 100s of controls and I don't > > >> understand anything. > >> > >> Perhaps this is an inherent problem from the gradient complexity, > but > >> I'd appreciate if we had some documentary material that outlines > how > >> to achieve which kind of results, which gradient type to use for > >> what, how many stops for what effect etc. etc. > >> > > > > Ok, let me try and give you a fairly simplified description of > what > > gradients are basically about, and how evas tries to deal with > this.. for > > better or worse. > > > > ... > > ... > > ... > > But to get back to the subject at hand here, and before going > on > > to give > > more details on current evas gradients, let me ask you this: > > How would you answer the above two 'general' questions.. or rather, > > > what would > > *you* like to see as an api that would make you want to use > gradients > > more? > > > > Not much time to reflect on this? Well, that's understandable > :) > Let me go ahead and review the current set of gradient api funcs in > evas, > give some criticisms, and propose some changes I'd like to make to > improve > things there (and yes, they would break all gradient stuff). > > First, recall I mentioned the two parts involved in gradients: > 1) Those aspects related to defining a 1-dim image (or "spectrum" as > I >sometimes call it). > 2) Those aspects related to defining how to map the above to a 2-dim >region - and this covers things like the gradient type, > spread-mode, >and such things. > > Ok, for (1) in evas we currently have the following (set) api > funcs: > > void evas_object_gradient_color_stop_add(obj, r,g,b,a, int delta); > void evas_object_gradient_alpha_stop_add(obj, a, int delta); > void evas_object_gradient_color_data_set(obj, *data, len, has_alpha); > void evas_object_gradient_alpha_data_set(obj, *data, len); > void evas_object_gradient_direction_set(obj, *data, int direction); > void evas_object_gradient_offset_set(obj, *data, float offset); > and also, > void evas_object_gradient_clear(obj); > > The 'clear' api func removes any stops or data that might have > been > set before. > The 'offset' api func effectively moves the origin of the 1-dim > image, > this is something that as far as I know isn't supported by any vgfx > api/spec > (which is unfortunate since it can give very nice animation effects > which are > otherwise difficult to obtain for some gradient types, eg. radial > ones). > The 'direction' api func just reverses the start/end of the > 1-dim, > and though not directly supported by most vgfx apis/specs, it can be > easily > obtained - it's mostly a simple convenience function. > The 'color_data' and 'alpha_data' api funcs are to allow for > setting > such a 1-dim image with premul and alpha-only data, rather than going > thru > any kind of procedural description. It's not supported by any vgfx > api/spec > that I know of, not directly anyway.. though you can certainly > consider such > data as an equi-distant set of stops and add it that way (modulo some > gymnastics > with premul data and alpha masks and such). > > The 'color_stop' and 'alpha_stop' api funcs evas' current > procedural > descriptions for defining the spectrum -- and these I have real issues > with. > > Not only is this method of specifying stops not supported by > any > 'standard' vgfx api/spec, the use of the "int delta" as either some > kind > of 'weight' or maybe 'distance to a next' is somewhat un-intuitive and > very > difficult to work with for gui editors and such. > I propose getting rid of this legacy stuff (inhereted from the > equally > archaic Imlib2 method), and adopt a more standard method. > > In fact, let's start from scratch altogether here and let me > propose > a minimal set of grdient-spectrum related api functions that more > closely > matches what's given by most vgfx apis/specs: > > void evas_object_gradient_clear(obj); > // keep this one > > void evas_object_gradient_color_stop_insert(obj, r,g,b,a, float pos); > // where 'pos' is clamped to be in [0,1]. Any previous stop at same > pos > // will be overwritten. Must insert one stop at pos 0 and one at pos > 1 > // to get a v
Re: [E-devel] [Evas] possible bug in gradient
>> So, if anyone has any comments, suggestions, issues.. *anything* with evas gradients -- now would be a good time to pipe in. :) >>> >>> I'd _love_ using gradients, in fact I would use them much more >>> often, _if_ not everytime I start using them, it all feels like I'm >>> operating a powerful machine that has 100s of controls and I don't >>> understand anything. >>> >>> Perhaps this is an inherent problem from the gradient complexity, >>> but I'd appreciate if we had some documentary material that outlines >>> how to achieve which kind of results, which gradient type to use for >>> what, how many stops for what effect etc. etc. >>> >> >> Ok, let me try and give you a fairly simplified description of what >> gradients are basically about, and how evas tries to deal with this.. >> for >> better or worse. >> >> ... >> ... >> ...But to get back to the subject at hand here, and >> before going on to give >> more details on current evas gradients, let me ask you this: >> How would you answer the above two 'general' questions.. or rather, >> what would >> *you* like to see as an api that would make you want to use gradients >> more? >> > > Not much time to reflect on this? Well, that's understandable :) > Let me go ahead and review the current set of gradient api funcs in evas, > give some criticisms, and propose some changes I'd like to make to > improve > things there (and yes, they would break all gradient stuff). > > First, recall I mentioned the two parts involved in gradients: > 1) Those aspects related to defining a 1-dim image (or "spectrum" as I > sometimes call it). > 2) Those aspects related to defining how to map the above to a 2-dim > region - and this covers things like the gradient type, spread-mode, > and such things. > > Ok, for (1) in evas we currently have the following (set) api funcs: > > void evas_object_gradient_color_stop_add(obj, r,g,b,a, int delta); > void evas_object_gradient_alpha_stop_add(obj, a, int delta); > void evas_object_gradient_color_data_set(obj, *data, len, has_alpha); > void evas_object_gradient_alpha_data_set(obj, *data, len); > void evas_object_gradient_direction_set(obj, *data, int direction); > void evas_object_gradient_offset_set(obj, *data, float offset); > and also, > void evas_object_gradient_clear(obj); > > The 'clear' api func removes any stops or data that might have been > set before. > The 'offset' api func effectively moves the origin of the 1-dim > image, > this is something that as far as I know isn't supported by any vgfx > api/spec > (which is unfortunate since it can give very nice animation effects > which are > otherwise difficult to obtain for some gradient types, eg. radial ones). > The 'direction' api func just reverses the start/end of the 1-dim, > and though not directly supported by most vgfx apis/specs, it can be > easily > obtained - it's mostly a simple convenience function. > The 'color_data' and 'alpha_data' api funcs are to allow for setting > such a 1-dim image with premul and alpha-only data, rather than going > thru > any kind of procedural description. It's not supported by any vgfx > api/spec > that I know of, not directly anyway.. though you can certainly > consider such > data as an equi-distant set of stops and add it that way (modulo some > gymnastics > with premul data and alpha masks and such). > > The 'color_stop' and 'alpha_stop' api funcs evas' current procedural > descriptions for defining the spectrum -- and these I have real issues > with. > > Not only is this method of specifying stops not supported by any > 'standard' vgfx api/spec, the use of the "int delta" as either some kind > of 'weight' or maybe 'distance to a next' is somewhat un-intuitive and > very > difficult to work with for gui editors and such. > I propose getting rid of this legacy stuff (inhereted from the > equally > archaic Imlib2 method), and adopt a more standard method. > > In fact, let's start from scratch altogether here and let me propose > a minimal set of grdient-spectrum related api functions that more closely > matches what's given by most vgfx apis/specs: > > void evas_object_gradient_clear(obj); > // keep this one > > void evas_object_gradient_color_stop_insert(obj, r,g,b,a, float pos); > // where 'pos' is clamped to be in [0,1]. Any previous stop at same pos > // will be overwritten. Must insert one stop at pos 0 and one at pos 1 > // to get a valid gradient spectrum. > > This and matches what most use. One could then possibly add the > following > funcs to make it easier/more-intuitive to input, query, and manipulate > such > gradient stops: > > void evas_object_gradient_color_stop_get(obj, int index, > *r,*g,*b,*a,*pos); > // get the value of the stop at 'index', where these are ordered from > 0 to > // (number_of_stops - 1) according to increasing position. If 'index' > is >= > // the current num
Re: [E-devel] [Evas] possible bug in gradient
While everyones talking about gradients, Ive a request... Id like to
be able to create a gradient that goes from sollid white to alpha then
clip an image to it so that the image fades away. Something like
this...
spectra {
spectrum {
name: "sp2";
color: 255 255 255 255 1;
color: 0 0 0 0 1;
}
}
collections {
group {
name: "Test";
parts {
part {
name: "base";
type: GRADIENT;
mouse_events: 0;
description {
state:"default" 0.0;
gradient.spectrum: "sp2";
fill.spread: 1;
}
}
part {
name: "chinaman";
mouse_events: 0;
type: IMAGE;
clip_to: "base";
description {
state:"default" 0.0;
image.image: ChinaManBeard.jpg" COMP;
image.normal: "ChinaManBeard.jpg";
}
}
}
}
}
In this example I was trying to get this image to fade like the
gradient does. If you clip the image to a normal RECT then fade the
clip box it will fade the image too.
Would be nice, but not essential. Im guessing the mechanics behind it
are alot more complex than I comprehend...
Toma
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
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
Toma wrote:
> While everyones talking about gradients, Ive a request... Id like to
> be able to create a gradient that goes from sollid white to alpha then
> clip an image to it so that the image fades away. Something like
> this...
>
> spectra {
> spectrum {
> name: "sp2";
> color: 255 255 255 255 1;
> color: 0 0 0 0 1;
> }
> }
> collections {
> group {
>name: "Test";
>parts {
> part {
>name: "base";
>type: GRADIENT;
>mouse_events: 0;
>description {
> state:"default" 0.0;
> gradient.spectrum: "sp2";
> fill.spread: 1;
>}
> }
> part {
>name: "chinaman";
>mouse_events: 0;
>type: IMAGE;
>clip_to: "base";
>description {
> state:"default" 0.0;
> image.image: ChinaManBeard.jpg" COMP;
> image.normal: "ChinaManBeard.jpg";
>}
> }
>}
> }
> }
>
> In this example I was trying to get this image to fade like the
> gradient does. If you clip the image to a normal RECT then fade the
> clip box it will fade the image too.
> Would be nice, but not essential. Im guessing the mechanics behind it
> are alot more complex than I comprehend...
> Toma
>
>
This is something very useful and indeed I would like to add this
ability to evas. I would add this as the ability to "mask" any object by
either an image or gradient object.
I *don't* want to add it via the current clipping mechanism. Why?
Because I implemented just that sometime back and ran into several semantic
and practical 'issues' that I truly don't like. I'd leave clipping as is -
clip to rectangles and ignore any transforms, corners, whatnot these objs
might have.. ie. a pure rectangular display region clipping mechanism.
The separate "mask" approach allows for a simpler, easier to optimize,
directly supported by most engines, and gives a powerful method since the
mask objects (images or gradients) can be transformed and/or filtered.
With it, you can get all the nifty 'new' reflection stuff that apple's
made famous recently, and a lot more such masking effects (eg. mask with
a buffer evas, indirectly, by masking with the associated image).
NB: This is somewhat similar to (though not exactly the same as)
fill and/or stroke "texturing" of vgfx objs with image or grad objects.
Click to become a designer and quit your boring job.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3l7MABetj9UMyNeM7OIM8bHr74HKPatHWDUwfP2rv45TmoDt/
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Not directly related to shared-strings or data structures, but as a relevant aside to the more general issue of useful 'core' kinds of libs, there is one lib that Jorge and Hisham recently worked on that might be of interest - namely, the timeline based animation lib "etch". I'm not sure just how finished that might be or whatnot, but I did see a video that Hisham sent me of it being used to animate an etk widget moving around and doing other stuff in an etk canvas widget.. and it was pretty nice. :) Summer Spa Sweepstakes Enter for your chance to WIN a Summer Spa Vacation! http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7UbfFlqaNggsaIGeiSibY7SvTZk96CBWAeILRTlHdeuMfBF/ - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
