> 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" <[email protected]> > An: "Christof Ressi" <[email protected]> > Cc: pd-dev <[email protected]> > Betreff: Re: [PD-dev] Fw: Re: local canvas-only pd_bind > > On 3/17/19, Christof Ressi <[email protected]> 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" <[email protected]> > >> An: "Christof Ressi" <[email protected]> > >> Cc: pd-dev <[email protected]>, "Dan Wilcox" <[email protected]> > >> 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 <[email protected]> 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" <[email protected]> > >> > An: "Dan Wilcox" <[email protected]> > >> > Cc: pd-dev <[email protected]> > >> > 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" <[email protected]> > >> > An: "Christof Ressi" <[email protected]> > >> > Cc: pd-dev <[email protected]>, "Chris McCormick" <[email protected]> > >> > 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 <[email protected]> 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 > >> > [email protected] https://lists.puredata.info/listinfo/pd-dev > >> > > > > > > > > _______________________________________________ > > 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
