> however, there's no event passing like in Qt: all widgets in question get the > event (probably starting from the inmost canvas).
thinking more about it, maybe only the innermost GOP should receive mouse clicks (and own the grab)? then we *could* also implement event passing: if a [mouse] object gets a mouse event, it could send a message like [forward( to itself, in which case the event is propagated to the next GOP (towards the root). maybe this is too much... I could hack together a prototype, but only in April... I'm really thinking in terms of GUI toolkits here because personally I would like the new object to be more capable than just creating a simple tracking area. Christof > Gesendet: Sonntag, 17. März 2019 um 17:31 Uhr > Von: "Christof Ressi" <[email protected]> > An: pd-dev <[email protected]> > Betreff: Re: [PD-dev] local canvas-only pd_bind > > hi katja, > > personally I would prefer 2), simply because it allows you to build custom > widgets as Pd abstractions. a tracking area can be built quite easily with > GOP. > > > 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. > > that's an important point! I've worked a bit with GUI toolkits like Qt and > usually it's implemented so that if you click a widget, it has the current > "grab", and whenever you release the mouse, the widget which has the grab > gets the mouseup event. we can do a similar thing in Pd. > > but there are more general questions about parent/child releationships: > > with iemguts you directly specify the parent canvas from which you want to > receive mouse events. the bad thing is that [receivecanvas] is context > sensitive: you have to know where your abstraction is being used and give the > right parent level!! this is quite bad for implementing widgets, which should > work anywhere. so I'm actually a bit wary about the iemguts approach > (although I've brought it up). > > on the other hand, when you receive mouse events from a GOP, you can do that > on any level as long as the object is visible. you can easily nest GOPs and > every GOP which is under the cursor will receive the click message. however, > there's no event passing like in Qt: all widgets in question get the event > (probably starting from the inmost canvas). this means that there can be more > than one "grab" - rather a "grab list" which is then notified for mouseup > events. > > another question for mouseup events is if only widgets with a "grab" should > get the event - or also widgets which fall under the current cursor position? > the second could be handy for drop&drag funtionality. maybe this could be > controlled by a creation argument/flag. > > Christof > > > 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
