Re: [E-devel] Evas 'shaped' gradient type
> > > > Not from me, sorry.. :( Feel free to use it or let it go
> > > > as you wish.
> > >
> > > who wants to have a go at this? :)
> > >
> >
> > You once asked me to take evas off your plate, and I told
> > you that I couldn't, and shouldn't, do that.
> > There are many things about 'maintaining' such a programing
> > project that I don't know about, and frankly I don't want to know
> > about - I'm just not interested.
> > For those kinds of things, and *many* others, your involvement
> > is crucial to the welfare of evas.
> >
> > However, for quite a few other things, I've come to feel
> > that you are actually a detriment, rather than a help, to that lib.
>
> mostly due to having enough on my plate when i get patches -
> it takes me forever to go over them - yours tend to be enormous -
> thus they end up on the bottom of my list (and often contain lots
> of untested stuff that breaks :() for this i am trying to get off
> my plate some mechanical "add api call that passes in file, key and
> params" as separate options work off my plate. ie - you wrote code
> that offer a feature - GREAT! but the api level access to that
> feature presents problems. there is a good reason we split off key
> and filenames long ago instead of merging them - at the api level.
> internally - is an internal matter. the api gets set in stone -
> the internals are always fixable later :)
>
> as per the other things we have discussed - i have erred on the
> side of minimal breakage as we now have a tonne of code depending
> on evas's api - and changing it all is a large mass of work.
> alternately we could just never write e or any app and forever
> fiddle with the lib and it's api and internals.
>
> evas has reached that state of "good enough" but can definitely
> improve - it's a dangerous state to be in - and i know just why -
> as it's "good enough" to build on and that is just what is
> happening - at it, in turn, is getting neglected. it suffers from
> "too many engines". too many api's to keep in sync.
>
> yes it needs love - but i don't have the time to give it the love
> it deserves. i have to come and go from it. i generally haven't
> stopped a lot from happening to evas - except that your patches
> tend to be massive efforts and they sit in my queue forever. :)
>
> > I can't work on evas as you see fit.. not in good faith
> > to what I think evas needs, and not to efficient use of my time
> > or efforts.
>
> i haven't said no - i just said "this api here need fixing". :)
>
There's a lot I could comment on the above, but let me just
address the grad 'api' issue you seem concerned with now:
As I've explained before, there are a number of pluses
and minuses to the string based (type,type_params) entry point.
There were several things I had to weigh there in going
with this to get things in place.. but mainly it was done in order
to allow for maximum flexibility in the kinds of grads evas could
support.
Given the state of things, without this kind of api entry
point one would need to pick some set of them and add whatever set
of api functions for each supported such.. and if sometime down the
road some new type becomes 'desirable', or more options for some
existing one, then again more api...
How would you go about supporting a flexible set of grad
types that edje could use, without having edje go thru the same..
and without putting a burden on edje to correctly identify values
belonging per type etc.. ?
If you really want an evas api function to set the (file,
key,mode) for just this one grad type, then just add something of
the form (assuming the separator is changed to ://: say)
evas_object_gradient_type_shaped_set(obj,file,key,mode)
{
char s[LONG_ENOUGH];
//check stuff ...
snprintf(s,LONG_ENOUGH,"%s://:%s://:%d",file,key,mode);
evas_object_gradient_type_set(obj,"shaped",s);
}
or something of that sort.
You can do something like this for as many of them as you
want to have separate api functions for.
What gains will this give to their use in general? Or their
use by edje?
If people feel, and have good reason to show, that this
would indeed be a better way to build the grad api, then I would
be more than glad to support that route myself.
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
On Sun, 13 Aug 2006 08:07:09 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled: > > > > Not from me, sorry.. :( Feel free to use it or let it go > > > as you wish. > > > > who wants to have a go at this? :) > > > > You once asked me to take evas off your plate, and I told > you that I couldn't, and shouldn't, do that. > There are many things about 'maintaining' such a programing > project that I don't know about, and frankly I don't want to know > about - I'm just not interested. > For those kinds of things, and *many* others, your involvement > is crucial to the welfare of evas. > > However, for quite a few other things, I've come to feel > that you are actually a detriment, rather than a help, to that lib. mostly due to having enough on my plate when i get patches - it takes me forever to go over them - yours tend to be enormous - thus they end up on the bottom of my list (and often contain lots of untested stuff that breaks :() for this i am trying to get off my plate some mechanical "add api call that passes in file, key and params" as separate options work off my plate. ie - you wrote code that offer a feature - GREAT! but the api level access to that feature presents problems. there is a good reason we split off key and filenames long ago instead of merging them - at the api level. internally - is an internal matter. the api gets set in stone - the internals are always fixable later :) as per the other things we have discussed - i have erred on the side of minimal breakage as we now have a tonne of code depending on evas's api - and changing it all is a large mass of work. alternately we could just never write e or any app and forever fiddle with the lib and it's api and internals. evas has reached that state of "good enough" but can definitely improve - it's a dangerous state to be in - and i know just why - as it's "good enough" to build on and that is just what is happening - at it, in turn, is getting neglected. it suffers from "too many engines". too many api's to keep in sync. yes it needs love - but i don't have the time to give it the love it deserves. i have to come and go from it. i generally haven't stopped a lot from happening to evas - except that your patches tend to be massive efforts and they sit in my queue forever. :) > I can't work on evas as you see fit.. not in good faith > to what I think evas needs, and not to efficient use of my time > or efforts. i haven't said no - i just said "this api here need fixing". :) > >jose. > > > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
> > Not from me, sorry.. :( Feel free to use it or let it go > > as you wish. > > who wants to have a go at this? :) > You once asked me to take evas off your plate, and I told you that I couldn't, and shouldn't, do that. There are many things about 'maintaining' such a programing project that I don't know about, and frankly I don't want to know about - I'm just not interested. For those kinds of things, and *many* others, your involvement is crucial to the welfare of evas. However, for quite a few other things, I've come to feel that you are actually a detriment, rather than a help, to that lib. I can't work on evas as you see fit.. not in good faith to what I think evas needs, and not to efficient use of my time or efforts. jose. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
On Sun, 13 Aug 2006 06:53:10 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled: > > > > This 'one-size-fits-all' approach has its obvious drawbacks.. > > > and benefits (eg. one could have runtime loadable types without > > > needing any included files whatever). > > > > i think - if we want to add this, we need to add an api call that > > accepts 3 params for this - if you can do that and come back with > > the patch again.. then it'd be all good :) > > > Not from me, sorry.. :( Feel free to use it or let it go > as you wish. who wants to have a go at this? :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
> > This 'one-size-fits-all' approach has its obvious drawbacks.. > > and benefits (eg. one could have runtime loadable types without > > needing any included files whatever). > > i think - if we want to add this, we need to add an api call that > accepts 3 params for this - if you can do that and come back with > the patch again.. then it'd be all good :) > Not from me, sorry.. :( Feel free to use it or let it go as you wish. jose. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
On Thu, 10 Aug 2006 17:59:48 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled: > > > > This type, unlike the others, does not use a described > > > geometry, but instead uses an image to specify that. > > > The type has as its params a string of the form: > > > > > > "file:key:mode" > > > > > > Each of file, key, and mode must be present. > > > > personally i would have made this 2 function parameters - > > fielname, key and then an enum for mode. then its split at > > the api level and no parsing need be done :) > > > > The grad type api consists of one entry point: > evas_object_gradient_type_set(grd, char *type, char *type_params); > where the 'type_params' encapsulates type specific data that might > be needed or available for that type. > > This 'one-size-fits-all' approach has its obvious drawbacks.. > and benefits (eg. one could have runtime loadable types without > needing any included files whatever). i think - if we want to add this, we need to add an api call that accepts 3 params for this - if you can do that and come back with the patch again.. then it'd be all good :) > Let me try and explain why I went with this. > > I wanted an extensible set of grad types... Without the > above, we'd need to enumerate each supported type and then have > type-specific api functions of the form: > evas_object_gradient_type_blah_something_set/get() > > With things as they now stand, it would mean around 20+ > api functions, and similar at the engines level. > > Without a decent framework for loadable object types, > I felt that going with the 'type/type_params' approach would be > best (of course an api function for listing the set of supported > types, etc.. would be good). > > If at a later point in time evas does get loadable > obj types, one would only need to deprecate the use of the > 'type_params' string to deal with type-specific data, and > instead use whatever type-specific funcs would be available. > > As far as the shaped-grad-type-params-format goes: > > One thing that could be done instead of the 'file:key:mode' > format, is to use what is currently done internally by the image > loading/caching mechanism.. namely 'file://:key://:mode'. > > > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
On Thu, 10 Aug 2006 22:22:17 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled: > > > > If at a later point in time evas does get loadable > > > obj types, one would only need to deprecate the use of the > > > 'type_params' string to deal with type-specific data, and > > > instead use whatever type-specific funcs would be available. > > > > I'll second the desire for loadable object types. > > BUT, lets keep any drastic evas changes until AFTER we get e17 > > out the door. So, lets focus on the task at hand, then worry > > about the design improvements we can make to the backend libs. > > > > It's not imminent :) However, the move to premul could be, > and some restructuring of the image rendering internals to allow > for image and obj transforms could be nearly so.. > I've actually been hesitant to finish up and send the > premul stuff due to the flurry of recent work.. maybe better > to wait til e17 gets stable/released?? work on the premul code now - but keep it on the backburner until next month IMHO. but work on it - test it, fix it up - make sure it's solid - use this time to be able to do so :) > > > (Edje could use some refactoring of the code paths that handle > > different object types also -- although loadable wouldn't work > > for edje since we'd then have .edj incompatibilities). > > > Not necessarily.. we'd see :) > > > But, good things to keep in the back of our minds for later :) > > > > rephorm > > > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
On Thu, 10 Aug 2006 16:45:51 +0200 Sebastian Dransfeld <[EMAIL PROTECTED]> babbled: > Carsten Haitzler (The Rasterman) wrote: > > On Mon, 7 Aug 2006 08:15:30 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > > babbled: > > > >> Attached is a tgz file containing a patch for a new evas > >> gradient type named "shaped". > >> > >>This type, unlike the others, does not use a described > >> geometry, but instead uses an image to specify that. > >>The type has as its params a string of the form: > >> > >>"file:key:mode" > >> > >> Each of file, key, and mode must be present. > > > > personally i would have made this 2 function parameters - fielname, key and > > then an enum for mode. then its split at the api level and no parsing need > > be done :) > > you mean 3? damn laptop keyboard... :) yes - 3 :) > Sebastian > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
> > If at a later point in time evas does get loadable > > obj types, one would only need to deprecate the use of the > > 'type_params' string to deal with type-specific data, and > > instead use whatever type-specific funcs would be available. > > I'll second the desire for loadable object types. > BUT, lets keep any drastic evas changes until AFTER we get e17 > out the door. So, lets focus on the task at hand, then worry > about the design improvements we can make to the backend libs. > It's not imminent :) However, the move to premul could be, and some restructuring of the image rendering internals to allow for image and obj transforms could be nearly so.. I've actually been hesitant to finish up and send the premul stuff due to the flurry of recent work.. maybe better to wait til e17 gets stable/released?? > (Edje could use some refactoring of the code paths that handle > different object types also -- although loadable wouldn't work > for edje since we'd then have .edj incompatibilities). > Not necessarily.. we'd see :) > But, good things to keep in the back of our minds for later :) > > rephorm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
On Thu, Aug 10, 2006 at 05:59:48PM +, [EMAIL PROTECTED] wrote: > If at a later point in time evas does get loadable > obj types, one would only need to deprecate the use of the > 'type_params' string to deal with type-specific data, and > instead use whatever type-specific funcs would be available. I'll second the desire for loadable object types. BUT, lets keep any drastic evas changes until AFTER we get e17 out the door. So, lets focus on the task at hand, then worry about the design improvements we can make to the backend libs. (Edje could use some refactoring of the code paths that handle different object types also -- although loadable wouldn't work for edje since we'd then have .edj incompatibilities). But, good things to keep in the back of our minds for later :) rephorm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
> > This type, unlike the others, does not use a described > > geometry, but instead uses an image to specify that. > > The type has as its params a string of the form: > > > > "file:key:mode" > > > > Each of file, key, and mode must be present. > > personally i would have made this 2 function parameters - > fielname, key and then an enum for mode. then its split at > the api level and no parsing need be done :) > The grad type api consists of one entry point: evas_object_gradient_type_set(grd, char *type, char *type_params); where the 'type_params' encapsulates type specific data that might be needed or available for that type. This 'one-size-fits-all' approach has its obvious drawbacks.. and benefits (eg. one could have runtime loadable types without needing any included files whatever). Let me try and explain why I went with this. I wanted an extensible set of grad types... Without the above, we'd need to enumerate each supported type and then have type-specific api functions of the form: evas_object_gradient_type_blah_something_set/get() With things as they now stand, it would mean around 20+ api functions, and similar at the engines level. Without a decent framework for loadable object types, I felt that going with the 'type/type_params' approach would be best (of course an api function for listing the set of supported types, etc.. would be good). If at a later point in time evas does get loadable obj types, one would only need to deprecate the use of the 'type_params' string to deal with type-specific data, and instead use whatever type-specific funcs would be available. As far as the shaped-grad-type-params-format goes: One thing that could be done instead of the 'file:key:mode' format, is to use what is currently done internally by the image loading/caching mechanism.. namely 'file://:key://:mode'. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
Carsten Haitzler (The Rasterman) wrote: > On Mon, 7 Aug 2006 08:15:30 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > babbled: > >> Attached is a tgz file containing a patch for a new evas >> gradient type named "shaped". >> >> This type, unlike the others, does not use a described >> geometry, but instead uses an image to specify that. >> The type has as its params a string of the form: >> >> "file:key:mode" >> >> Each of file, key, and mode must be present. > > personally i would have made this 2 function parameters - fielname, key and > then an enum for mode. then its split at the api level and no parsing need be > done :) you mean 3? Sebastian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
On Mon, 7 Aug 2006 08:15:30 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled: > Attached is a tgz file containing a patch for a new evas > gradient type named "shaped". > > This type, unlike the others, does not use a described > geometry, but instead uses an image to specify that. > The type has as its params a string of the form: > > "file:key:mode" > > Each of file, key, and mode must be present. personally i would have made this 2 function parameters - fielname, key and then an enum for mode. then its split at the api level and no parsing need be done :) >'file' is the name of some image file. >'key' is the name of some key for loading from eet files -- > if no key is desired, then one must write NULL as the key. >'mode' is one of: alpha, grey, or color. > The mode will determine how the spectrum is used in conjunction > with the image to obtain the result: > 'alpha' uses the image's alpha channel as the index to > the spectrum. > 'grey' uses the image's grey channel, ie. the values > a*(r+g+b)/3, as the index. > 'color' uses all the image's color channels by using the > spectrum as a color-modifier. > > eg. "/path_to/image.png:NULL:color" > > The evas_test_main program contains a sample of how to > use this grad type... It can be used to obtain scaling/tiling/ > rotating/re-coloring of images... > > >jose. > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
> > If anyone could help out here with a better, fast enough, > > format-spec-and-decoding-implementation, that would be great :) > > [ The implementation of this is done in the function > > "shaped_setup_geom" of the evas_gradient_shaped.c file ] > > I would consider using \0 for a separator.. makes parsing a snap.. > just search for the nth 0-byte to get the nth field, and you get > the string without further processing of the base string.. > > only downside is you can't use the stock string functions on that > piece of data, so it would need to be treated like binary data.. > but it might be a worthwhile tradeoff.. > Yeah... Unfortunately though, too much of the canvas and engine level stuff depends on these input params being a C string. In any case, a reasonable version of a format that would allow for efficiently separating the input string into a triple (file, key, whatever), without having undesirable limitations on the file,key pair... would be good. jose. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
[EMAIL PROTECTED] wrote:
>>> eg. "/path_to/image.png:NULL:color"
>> Is there a reason you chose "NULL" instead of just leaving the
>> field blank? (filename.ext::mode)
>> Also, ':' is a valid character for a filename, so hopefully
>> there's a way to escape it? ("/path/to/foo\:bar.png:NULL:color)
>>
>
> Unfortunately, no. Your points are more than well taken
> though. The primary reasons for choosing this 'format' were:
>
> If anyone could help out here with a better, fast enough,
> format-spec-and-decoding-implementation, that would be great :)
> [ The implementation of this is done in the function
> "shaped_setup_geom" of the evas_gradient_shaped.c file ]
I would consider using \0 for a separator.. makes parsing a snap.. just
search for the nth 0-byte to get the nth field, and you get the string
without further processing of the base string..
only downside is you can't use the stock string functions on that piece
of data, so it would need to be treated like binary data.. but it might
be a worthwhile tradeoff..
--
Cheers,
Morten
:wq
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
> > eg. "/path_to/image.png:NULL:color"
>
> Is there a reason you chose "NULL" instead of just leaving the
> field blank? (filename.ext::mode)
> Also, ':' is a valid character for a filename, so hopefully
> there's a way to escape it? ("/path/to/foo\:bar.png:NULL:color)
>
Unfortunately, no. Your points are more than well taken
though. The primary reasons for choosing this 'format' were:
1. We need a fast, simple way to decode the input param
string.. This decoding is done possibly twice per rendering.
Things could be done to minimize that need, but not right now as
things stand. In any case, a fast decoding is desired.
2. The author was lazy, and is somewhat inept with regards
to such matters.. He was thus led towards 'simple' even more than
fast... or anything else for that matter.
Obviously, (2) is not very satisfactory.
If anyone could help out here with a better, fast enough,
format-spec-and-decoding-implementation, that would be great :)
[ The implementation of this is done in the function
"shaped_setup_geom" of the evas_gradient_shaped.c file ]
> >
> > The evas_test_main program contains a sample of how to
> > use this grad type... It can be used to obtain scaling/tiling/
> > rotating/re-coloring of images...
> >
>
> I'll try to play with this later this week. Time to throw together
> an old Nintendo style game with rotating color palette animations?
> :)
Ok! Now we're talking! :) :)
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas 'shaped' gradient type
On Mon, Aug 07, 2006 at 08:15:30AM +, [EMAIL PROTECTED] wrote:
> Attached is a tgz file containing a patch for a new evas
> gradient type named "shaped".
>
> This type, unlike the others, does not use a described
> geometry, but instead uses an image to specify that.
> The type has as its params a string of the form:
>
> "file:key:mode"
>
> Each of file, key, and mode must be present.
>
>'file' is the name of some image file.
>'key' is the name of some key for loading from eet files --
> if no key is desired, then one must write NULL as the key.
>'mode' is one of: alpha, grey, or color.
> The mode will determine how the spectrum is used in conjunction
> with the image to obtain the result:
> 'alpha' uses the image's alpha channel as the index to
> the spectrum.
> 'grey' uses the image's grey channel, ie. the values
> a*(r+g+b)/3, as the index.
> 'color' uses all the image's color channels by using the
> spectrum as a color-modifier.
>
> eg. "/path_to/image.png:NULL:color"
Is there a reason you chose "NULL" instead of just leaving the field
blank? (filename.ext::mode)
Also, ':' is a valid character for a filename, so hopefully there's a
way to escape it? ("/path/to/foo\:bar.png:NULL:color)
>
> The evas_test_main program contains a sample of how to
> use this grad type... It can be used to obtain scaling/tiling/
> rotating/re-coloring of images...
>
I'll try to play with this later this week. Time to throw together an
old Nintendo style game with rotating color palette animations? :)
rephorm
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas 'shaped' gradient type
Attached is a tgz file containing a patch for a new evas gradient type named "shaped". This type, unlike the others, does not use a described geometry, but instead uses an image to specify that. The type has as its params a string of the form: "file:key:mode" Each of file, key, and mode must be present. 'file' is the name of some image file. 'key' is the name of some key for loading from eet files -- if no key is desired, then one must write NULL as the key. 'mode' is one of: alpha, grey, or color. The mode will determine how the spectrum is used in conjunction with the image to obtain the result: 'alpha' uses the image's alpha channel as the index to the spectrum. 'grey' uses the image's grey channel, ie. the values a*(r+g+b)/3, as the index. 'color' uses all the image's color channels by using the spectrum as a color-modifier. eg. "/path_to/image.png:NULL:color" The evas_test_main program contains a sample of how to use this grad type... It can be used to obtain scaling/tiling/ rotating/re-coloring of images... jose. grad_shaped.tgz Description: grad_shaped.tgz - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
