[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:
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'.