[PD-dev] local canvas-only pd_bind

Fred Jan Kraan fjkraan at xs4all.nl
Sun Mar 17 22:46:38 CET 2019

A precursor of this code can be found at 
https://github.com/electrickery/pd-playground/tree/master/GUI in the 
GUI5.c and GUI6.c objects.


Fred Jan

On 17/03/2019 22.27, katja wrote:
> Dan, the code isn't published but could be shared somewhere for the
> purpose of discussion if that is useful. Not sure what is a good
> place.
> Frankly I've spent quite some time investigating the subject and my
> conclusion is: it is not at all self-evident what a mouse class should
> do exactly, even when just considering a widget. IEM GUIs have a
> single outlet that produce simple messages of their status. A widget
> for mouse data must produce several kinds of data. But being a GUI
> element it is also supposed to send and receive data cordless.
> Multiple message types over a single 'channel', that means we have to
> use message selectors even if the messages are just floats. And when
> using message selectors for cordless communication, it makes sense to
> do the same for the 'physical' outlet rather than define an outlet per
> message type. This alone makes it an anomaly among the GUI objects. It
> is not the only doubt that I had, maybe now is the time to discuss.
> Despite my earlier promotional words about Pd's widgetbehavior
> infrastructure, I'd like to mention a major advantage of a
> 'message-to-canvas' approach if that is a feasible alternative: no
> need for Tk-related code in the class definition. If a mouse widget
> can be emulated as a GOP abstraction like proposed by Christof,
> existing IEM GUIs could be emulated in a similar fashion. Property
> boxes can also be implemented in the form of abstractions rather than
> Tk widgets. That is what I've done for my [mousepad] widget as well.
> As a bonus, the mouse widget itself can be incorporated in the
> properties box to manipulate the width and height of the object under
> concern. No need for cumbersome handles that double the code size!
> Katja
> On 3/17/19, Dan Wilcox <danomatika at gmail.com> wrote:
>> Katja: Do you have some sample code using this implementation? I've not
>> looked into this in depth yet.
>>> On Mar 17, 2019, at 4:38 PM, katja <katjavetter at gmail.com> wrote:
>>> Eventually the widget won my preference because it is easier to use,
>>> and because Pd's widgetbehavior infrastructure is made for such things
>>> after all. My implementation is almost complete except for the thing
>>> that sparked the current discussion: mouseup data. It would be great
>>> if a widget could subscribe to mouseup events, but a callback for that
>>> isn't available through widgetbehavior.
>> --------
>> Dan Wilcox
>> @danomatika <http://twitter.com/danomatika>
>> danomatika.com <http://danomatika.com/>
>> robotcowboy.com <http://robotcowboy.com/>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev

More information about the Pd-dev mailing list