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

[Christof Ressi]

> But, no mouseup unfortunately.

on mousedown, the widget could assign itself to a "grab" variable, and a mouseup event sends a message to the object who has the current grab.

another question: if we choose to go with a widget, can we just add this functionality to [cnv] ? after all, it can be made invisible by setting the visible width and height to 0.

> Gesendet: Sonntag, 17. März 2019 um 17:44 Uhr
> Von: "katja" <katjavetter at gmail.com>
> An: "Christof Ressi" <christof.ressi at gmx.at>
> Cc: pd-dev <pd-dev at lists.iem.at>
> Betreff: Re: [PD-dev] Fw: Re: local canvas-only pd_bind
>
> 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
> >
>