[PD-dev] Fw: Re: local canvas-only pd_bind

katja katjavetter at gmail.com
Sun Mar 17 17:44:13 CET 2019


On 3/17/19, Christof Ressi <christof.ressi at gmx.at> wrote:
>> 1 - as a basic widget, a rectangle without button or label
>
> ah, of course you could use such a widget inside a GOP as the "background"
> to implement other widgets. but at least for me, a simple Pd object which
> you put somewhere in a GOP abstraction feels more natural.

I was just about to say that. The widget can't have its own 'button'
anyway because you don't know how people want to use it. And the
issues you mentioned with respect to level, are automatically solved
by Pd's widgetbehavior functions. But, no mouseup unfortunately.

>
>> Gesendet: Sonntag, 17. März 2019 um 16:38 Uhr
>> Von: "katja" <katjavetter at gmail.com>
>> An: "Christof Ressi" <christof.ressi at gmx.at>
>> Cc: pd-dev <pd-dev at lists.iem.at>, "Dan Wilcox" <danomatika at gmail.com>
>> Betreff: Re: [PD-dev] local canvas-only pd_bind
>>
>> Hello,
>>
>> Metoo, I'm hungry for mouse events since long. Last year I evaluated
>> these approaches (as objects based on unmodified Pd):
>>
>> 1 - as a basic widget, a rectangle without button or label
>> 2 - as a non-widget, tracking mouse events within a GOP rectangle
>>
>> 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.
>>
>> Mouseup is a bit of a maverick: you want to be alerted regardless of
>> mouse position, i.e. any canvas or even outside Pd's territory.
>> Otherwise one could easily get the equivalent of a dangling midinote.
>> Therefore, would it be reasonable to conceive a dedicated class
>> [mouseup], every instance of which would be informed about every
>> mouseup event once? Such a class could also be useful in connection
>> with existing Pd GUIs, for example to turn a single-cell radiobutton
>> into a momentary switch.
>>
>> Anyhow, the other mouse events (mousedown, coordinates) are so much
>> related to position that bundling these in a single class is useful,
>> be it in a widget or otherwise.
>>
>>
>> Katja
>>
>> On 3/17/19, Christof Ressi <christof.ressi at gmx.at> wrote:
>> > on the other hand, I'm not sure if many people actually need to get
>> > mouse
>> > evens outside of GOP areas. I'm having a hard time coming up with useful
>> > examples on the fly...
>> > so a simplified version of [mouse] could just get the relative
>> > coordinates
>> > of the first GOP area it can find (so you can place it anywhere inside
>> > your
>> > abstraction/graph). for advanced use cases, there's always iemguts...
>> > just
>> > thinking out loud.
>> >
>> > Christof
>> >
>> > Gesendet: Sonntag, 17. März 2019 um 16:07 Uhr
>> > Von: "Christof Ressi" <christof.ressi at gmx.at>
>> > An: "Dan Wilcox" <danomatika at gmail.com>
>> > Cc: pd-dev <pd-dev at lists.iem.at>
>> > Betreff: Re: [PD-dev] local canvas-only pd_bind
>> > personally, I like the mechanism of [iemguts/receivecanvas] where you
>> > specify the parent level from where to receive mouse events because it's
>> > quite flexible. one problem, though, is that GOPs are a bit awkward: you
>> > have to get the mouse position from the parent canvas and then substract
>> > the
>> > canvasposition to get coordinates relative to the GOP. you can even hack
>> > together mouse enter and leave events to create advanced widgets, but it
>> > involves quite a lot of thinking.
>> >
>> > maybe the iemguts approach with parent levels can be somehow combined
>> > with
>> > elegant GOP handling? for example, [iemguts/receivecanvas] will never
>> > send
>> > mouse events if GOP is enabled on the given parent (except when someone
>> > opens it via the context menu), so maybe in this case the object could
>> > report mouse events relative to the GOP area. working with parent levels
>> > has
>> > the advantage that you can freely choose the location within you patch
>> > structure, e.g. you can put it in a subpatch and you just have to
>> > increase
>> > the parent level by 1.
>> >
>> > Christof
>> > Gesendet: Sonntag, 17. März 2019 um 14:28 Uhr
>> > Von: "Dan Wilcox" <danomatika at gmail.com>
>> > An: "Christof Ressi" <christof.ressi at gmx.at>
>> > Cc: pd-dev <pd-dev at lists.iem.at>, "Chris McCormick" <chris at mccormick.cx>
>> > Betreff: Re: [PD-dev] local canvas-only pd_bind
>> > Some good ideas.
>> >
>> > I agree that GOP is basically a natural analogy to a tracking area
>> > already,
>> > so that might be a good place to look. Perhaps this can be rolled into
>> > the
>> > name canvas mechanism whereby a named canvas will receive mouse events
>> > when
>> > GOP is enabled?
>> >
>> >>
>> >> Hi Dan, thanks for looking into this! This is really, really needed.
>> >>
>> >> I think with the [mouse] object, [mousearea] can be easily created as a
>> >> subpatch with GOP enabled, so I don't think we need a dedicated GUI
>> >> object for that.
>> >>
>> >> regarding [cnv]: I think getting notifications for mouse clicks would
>> >> be nice (in the past, people have faked this by putting other GUI
>> >> objects below the canvas, but it's really clumsy).
>> >>
>> >>
>> >> Christof
>> >
>> >
>> >>>
>> >>> On Mar 17, 2019, at 1:38 PM, Dan Wilcox <danomatika at gmail.com> wrote:
>> >>>
>> >>> That's a similar concept to Cocoa's NSTrackingArea. It's basically a
>> >>> rectangle in a view that you attach which then receives mouse enter,
>> >>> leave, move, down, up, & drag events. You can update the position and
>> >>> size whenever.
>> >>>
>> >>> https://developer.apple.com/documentation/appkit/nstrackingarea?language=objc
>> >>>
>> >>> I could imagine something similar in Pd, say a [mousearea] object.
>> >>> Also,
>> >>> updating [cnv] with similar functionality would be useful. [mousearea]
>> >>> could be used for arbitrary areas for control interaction and drawing
>> >>> of
>> >>> other objects while [cnv] could be used to create simple graphical
>> >>> regions for things like piano keys. I know there have been different
>> >>> approaches in this area, so it might be helpful to take a look
>> >>> (DesireData, PurrData, etc).
>> >>>
>> >>> I think this would complement a general, canvas wide set of [mouse]
>> >>> objects. I started by following the existing approach and split
>> >>> functionality into [mouse], [mouseup], and [mousemotion]. Another
>> >>> approach would be to use a single [mouse] object with a status symbol
>> >>> in
>> >>> addition to x & y.
>> >>
>> >>
>> >
>> >
>> > --------
>> > Dan Wilcox
>> > @danomatika
>> > danomatika.com
>> > robotcowboy.com
>> >
>> > _______________________________________________ Pd-dev mailing list
>> > Pd-dev at lists.iem.at https://lists.puredata.info/listinfo/pd-dev
>>
>
>
>
> _______________________________________________
> 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