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

Reply via email to