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