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

[Christof Ressi]

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

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