[PD-dev] local canvas-only pd_bind

[katja]

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/>
>
>
>
>