[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Evas 'shaped' gradient type



On Thu, 10 Aug 2006 17:59:48 GMT "jose_ogp@juno.com" <jose_ogp@juno.com>
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)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)