[PD-dev] devel_0_37: widgetbehavior, garray dirty flag

Thomas Grill t.grill at gmx.net
Tue Aug 5 12:26:29 CEST 2003


Hi Krzysztof,

> I feel it is more like time for protecting widgetbehavior type
> itself, instead of exposing its objects.  I expect the type
> definition is going to change, after people start complaining
> about flext objects being visible on-parent...

Maybe my ignorance in this respect comes from the fact that i try to avoid
GOPs whenever possible...
However, it's not clear for me how the cloning of the original gobj behavior
differs from defining a whole behavior struct for a graphical object (which
is considered to work for GOPs). Could you please elaborate on this?

>
> Besides, the long-term goal should be for externs to include only
> m_pd.h -- g_canvas.h is declared unstable.

This implies that all graphical objects are unstable.....

>
> So my short-term proposal is to have an access call, declared
>
> EXTERN t_widgetbehavior *class_getwidget(t_class *c);
>
> The longer-term proposal is to have a set of access calls, one
> for every callback, like
>
> EXTERN void class_setpropertiesfn(t_class *c, t_propertiesfn f);
>
> These routines would first check for an 'iscloned' flag introduced
> into t_widgetbehavior (along with a 'visedonparent' flag).  If the
> 'iscloned' flag for a class c is zero, the routine will clone the
> widgetbehavior, and set the flag.
>
> This way, an extern would just have to define a callback, and call
> class_set<whatever>fn() in class' setup routine, without bothering
> about other callbacks at all.

If you could implement that i'll happily use it....

best greetings,
Thomas





More information about the Pd-dev mailing list