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