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