> > > > 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
