On Wed, 23 Jul 2003, Krzysztof Czaja wrote:
Thomas, please keep lobbying for this one, which I desperately need too!
Or, perhaps, having a clear view on what is the best way, would you be willing to code your proposal into the cvs?
It might be worth a try, thats what the CVS is for. If its good there are chances that Miller takes it directly from there ... (Still have to ask him though if this way of contributing fits or is to troublesome for him) ..
Greetings,
Guenter
Cyclone's embedding classes use option 1), and this is causing much trouble: I have to build separately for Pd.36 and .37, such faked text objects are visible in gops, etc.
It would be simpler, if there was a call in the API, performing the needed cloning of the entire current widgetbehavior of a class...
...and a set of access calls for assigning to the t_widgetbehavior's fields...
...it would be nice too, if the test condition in text_shouldvis(), was modified, possibly by introducing a flag (or a `type' field, or yet another callback) into t_widgetbehavior, and replacing the check for text_widgetbehavior's pointer with the check for that flag.
Krzysztof
Thomas Grill wrote: ...
Is there a portable way to e.g use only the "properties" or the "save" method of the widget behavior but leave the others as they are (for normal object box behavior)? Using these functions is a good thing for non-graphical objects also. Currently, there seem to be only two non-satisfying ways:
- when the class setup function is called by PD the class widget-structure
is already initialized with the functions for normal object behavior. Copy these to a new structure and modify only the needed ones (e.g. only the "save" method") (as implemented in flext now) This has the drawback that the class structure must be known, which implies the usage of m_imp.h instead of m_pd.h which is not available publicly in /usr/include for linux installations
- Initialize the new widget behavior structure with the PD-internal widget
methods along with one new "save" method. However, these internal PD methods are not exposed in m_pd.h but statically defined. To use them the API has to be changed.
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev