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

["jose_ogp@juno.com" <jose_ogp@juno.com>]

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