Hi all, flext (cvs version) now contains an attribute editor that can be accessed with the "properties" context menu function of any attribute-enabled flext-based external . However, i'm not really satisfied with the implementation... maybe someone can help me with that:
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.
Am i missing something obvious? Are there other ways, or how can the situation be made better?
thanks for any input, Thomas
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:
- 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.
Hi Krzysztof,
Or, perhaps, having a clear view on what is the best way, would you be willing to code your proposal into the cvs?
i'm sorry but i don't really have a clear view. I'm sure Miller has and he knows better how to do it.
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...
Yes, i also think this is the simplest way to do it. (maybe you could try to do a cvs modification?!)
best greetings, Thomas
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
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) ..
I'm a bit reluctant with contributing really experimental stuff to the cvs for it might break PD (and i think a number of people are using the devel branch regularly) Should we make extra branches for these things or is it ok to directly commit to the devel branch? Normally i have all these changes locally at my machine for at least a few weeks until i commit them....
One example of a dangerous PD modification that i want to try is the splitting of the one dsp chain in multiple ones (one for each main patcher), so that the signal tree gets smaller and the chances of click-free rebuilding of the tree are higher. It is a definite goal for me to achieve completely click-free loading of patchers, e.g. with building the DSP tree in the background and then inserting it on the fly when finished. Has anyone made attempts in this direction?
best greetings, Thomas
Thomas Grill wrote:
One example of a dangerous PD modification that i want to try is the splitting of the one dsp chain in multiple ones (one for each main patcher), so that the signal tree gets smaller and the chances of click-free rebuilding of the tree are higher. It is a definite goal for me to achieve completely click-free loading of patchers, e.g. with building the DSP tree in the background and then inserting it on the fly when finished. Has anyone made attempts in this direction?
best greetings, Thomas
please keep us posted on this if you do experiment with it... i'm trying to use pd live much more in the last few months and the last big monkey wrench in my grand plans is the dsp tree recomputing clicks.
-
guenter geiger -
Josh Steiner -
Krzysztof Czaja -
Thomas Grill