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" katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at, "Dan Wilcox" danomatika@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@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@gmx.at An: "Dan Wilcox" danomatika@gmail.com Cc: pd-dev pd-dev@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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at, "Chris McCormick" chris@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@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=obj...
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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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" christof.ressi@gmx.at An: pd-dev pd-dev@lists.iem.at 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" katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at, "Dan Wilcox" danomatika@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@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@gmx.at An: "Dan Wilcox" danomatika@gmail.com Cc: pd-dev pd-dev@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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at, "Chris McCormick" chris@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@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=obj...
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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 18/3/19 12:44 am, Christof Ressi wrote:
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.
I would personally like it to be exactly that capable and no more. :)
Features are the enemy of good software!
Cheers,
Chris.
Hi,
On 18/3/19 12:31 am, Christof Ressi wrote:
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.
I wanted to provide an illustration of what is possible with just a mouse-up event in vanilla Pd.
Here is a small animated gif screen screen capture of two abstractions:
https://raw.githubusercontent.com/chr15m/pd-push-and-hold/master/screencast-...
These use the pd-push-and-hold GUI plugin which sends global mouse-up events. Other than that they are built using one vanilla hslider and a canvas each. The plugin is available via externals search.
The first one is useful when you are building effects which have a quantized range that you want to operate with a finger on a touch screen. For example if you are playing live music and you want a punch-in effect to turn on when you're pressing, and the ability to quickly switch between four versions/settings of that effect (for example four different delay line timings, or four different synth notes to be played as you drag.
The second one is useful for selecting a start/end range. So you might hook it up to a sample looper and you can use a finger on a touch-screen to select small ranges to loop over in real time.
Anyway, I've scratched my own itch with this plugin for the Raspberry Pi touchscreen thing I am building.
If the mouse-up event was made into a global that would do away with the need for a plugin.
If there was a 2d surface which worked like hslider + vslider in a single UI that would enable even more interesting widgets to be crafted as abstractions.
Cheers,
Chris.
-
Chris McCormick -
Christof Ressi