Hi all, i added two more smaller things to the devel_0_37 cvs branch:
1) after the recent communication about cloning widget behavior i found the easiest and equally portable solution to expose the text_widgetbehavior structure in g_canvas.h so that one can copy the respective functions to an object's own widgetbehavior structure, e.g. (from the attribute editor in flext)
//cloned functions widgetbehavior.w_getrectfn = text_widgetbehavior.w_getrectfn; widgetbehavior.w_displacefn = text_widgetbehavior.w_displacefn; widgetbehavior.w_selectfn = text_widgetbehavior.w_selectfn; widgetbehavior.w_activatefn = text_widgetbehavior.w_activatefn; widgetbehavior.w_deletefn = text_widgetbehavior.w_deletefn; widgetbehavior.w_clickfn = text_widgetbehavior.w_clickfn; // special functions widgetbehavior.w_propertiesfn = cb_GfxProperties; widgetbehavior.w_savefn = cb_GfxSave; widgetbehavior.w_visfn = cb_GfxVis; class_setwidget(c, &widgetbehavior);
2) in order to know when an array has been updated and use this information in an external graphical arrays have got a dirty flag in devel_0_36. I introduced this feature into devel_0_37 along with the exported function double garray_updatetime(t_garray *x) in m_pd.h to get the last update time (with the time base of clock_getlogicaltime)
best greetings, Thomas
hi Thomas,
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...
Besides, the long-term goal should be for externs to include only m_pd.h -- g_canvas.h is declared 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.
Krzysztof
Thomas Grill wrote: ...
- after the recent communication about cloning widget behavior i found the
easiest and equally portable solution to expose the text_widgetbehavior structure in g_canvas.h so that one can copy the respective functions to an object's own widgetbehavior structure, e.g. (from the attribute editor in flext)
//cloned functions widgetbehavior.w_getrectfn = text_widgetbehavior.w_getrectfn; widgetbehavior.w_displacefn = text_widgetbehavior.w_displacefn; widgetbehavior.w_selectfn = text_widgetbehavior.w_selectfn; widgetbehavior.w_activatefn = text_widgetbehavior.w_activatefn; widgetbehavior.w_deletefn = text_widgetbehavior.w_deletefn; widgetbehavior.w_clickfn = text_widgetbehavior.w_clickfn; // special functions widgetbehavior.w_propertiesfn = cb_GfxProperties; widgetbehavior.w_savefn = cb_GfxSave; widgetbehavior.w_visfn = cb_GfxVis; class_setwidget(c, &widgetbehavior);
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
hi Thomas,
Thomas Grill wrote: ...
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?
the point is that, if a text object, due to a specialized savefn or propertiesfn, has its wb cloned (by whatever means) or defined from scratch, it is being visible on-parent, while it should not be. In other words, it is treated as a graphical object, while we want it to be handled as a text object.
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.....
true... this is something I have been reminded about many times, after installing several Pd releases... so the goal is, at least, to narrow dependencies on g_canvas.h.
...
If you could implement that i'll happily use it....
I would like to know Miller's opinion first...
Krzysztof
the point is that, if a text object, due to a specialized savefn or propertiesfn, has its wb cloned (by whatever means) or defined from scratch, it is being visible on-parent, while it should not be. In other words, it is treated as a graphical object, while we want it to be handled as a text object.
Oh, i see, thanks. But then there will have to be some changes made to pd that are independent of the way how the wb is defined.
T
Aha... what this tells me is that the "savefn" and "propertiesfn" really shouldn't have been in the widgetbehavior structure (shared by all text objects) but in the "class" structure, with exported functions declared in m_pd.h. I'll try out a version of that for the next "test" release.
In general, at least one and possibly several major upheavals will still be needed in g_canvas.h in the future... I hope someday to be able to export a stable API for writing GUI objects but there's much work to do first.
The first big revision is to make it possible to delay graphics updates so they interefere less (hopefully not at all) with real-time computation. A second, possibly even bigger one, is to modularize out the TK code so people can plug in other GUIs such as WXWorks.
cheers Miller
On Tue, Aug 05, 2003 at 01:03:59PM +0200, Thomas Grill wrote:
the point is that, if a text object, due to a specialized savefn or propertiesfn, has its wb cloned (by whatever means) or defined from scratch, it is being visible on-parent, while it should not be. In other words, it is treated as a graphical object, while we want it to be handled as a text object.
Oh, i see, thanks. But then there will have to be some changes made to pd that are independent of the way how the wb is defined.
T
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
-
Krzysztof Czaja -
Miller Puckette -
Thomas Grill