[PD-dev] defining a widget behavior (GUI externals)

[Krzysztof Czaja]

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?

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:
 >
 > 1) 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
 >
 > 2) 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.