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.
Greetings,
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 <[email protected]> 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 <[email protected]> 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
[email protected]
https://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
[email protected]
https://lists.puredata.info/listinfo/pd-dev
