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... 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.
On Mar 17, 2019, at 12:15 PM, Chris McCormick chris@mccormick.cx wrote:
Hi Dan,
Thanks so much for looking at this.
What I really want as an end-user is to be able to know "has this particular rectangle received mouse-down, mouse-motion, or mouse-up?"
I think this would bring huge flexibility in allowing people to build complex user interfaces at the patch level. Things like ribbon controllers max/min selectors, click-and-hold buttons etc.
Cheers,
Chris.
On 16/3/19 10:01 am, Dan Wilcox wrote:
Howdy all, I played around a bit with forwarding canvas mouse click events to a [mouse] object. This works fine using a bind to a global "#mouse" symbol, however this means all objects receive events from all canvases. How can I change this to be local canvas only, as in only [mouse] objects within the canvas receive the events? I was thinking to generate a symbol with the canvas id ala how [openpanel] and [savepanel] work: sprintf(buf, "d%lx", (t_int)x); x->x_s = gensym(buf); x->x_canvas = canvas_getcurrent(); pd_bind(&x->x_obj.ob_pd, x->x_s) However, this means the canvas mouse function would need to generate the equivalent symbol each time the event is called in order to check if anything is bound to it. This seems wasteful. I suppose I could add a cached symbol somewhere, maybe to the g_canvas instance struct, however I'd like avoid that.
Dan Wilcox
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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... 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 http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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
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" 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
On 3/17/19, Christof Ressi christof.ressi@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@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
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@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at Betreff: Re: [PD-dev] Fw: Re: local canvas-only pd_bind
On 3/17/19, Christof Ressi christof.ressi@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@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
Katja: Do you have some sample code using this implementation? I've not looked into this in depth yet.
On Mar 17, 2019, at 4:38 PM, katja katjavetter@gmail.com wrote:
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.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan, the code isn't published but could be shared somewhere for the purpose of discussion if that is useful. Not sure what is a good place.
Frankly I've spent quite some time investigating the subject and my conclusion is: it is not at all self-evident what a mouse class should do exactly, even when just considering a widget. IEM GUIs have a single outlet that produce simple messages of their status. A widget for mouse data must produce several kinds of data. But being a GUI element it is also supposed to send and receive data cordless. Multiple message types over a single 'channel', that means we have to use message selectors even if the messages are just floats. And when using message selectors for cordless communication, it makes sense to do the same for the 'physical' outlet rather than define an outlet per message type. This alone makes it an anomaly among the GUI objects. It is not the only doubt that I had, maybe now is the time to discuss.
Despite my earlier promotional words about Pd's widgetbehavior infrastructure, I'd like to mention a major advantage of a 'message-to-canvas' approach if that is a feasible alternative: no need for Tk-related code in the class definition. If a mouse widget can be emulated as a GOP abstraction like proposed by Christof, existing IEM GUIs could be emulated in a similar fashion. Property boxes can also be implemented in the form of abstractions rather than Tk widgets. That is what I've done for my [mousepad] widget as well. As a bonus, the mouse widget itself can be incorporated in the properties box to manipulate the width and height of the object under concern. No need for cumbersome handles that double the code size!
Katja
On 3/17/19, Dan Wilcox danomatika@gmail.com wrote:
Katja: Do you have some sample code using this implementation? I've not looked into this in depth yet.
On Mar 17, 2019, at 4:38 PM, katja katjavetter@gmail.com wrote:
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.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
A precursor of this code can be found at https://github.com/electrickery/pd-playground/tree/master/GUI in the GUI5.c and GUI6.c objects.
Greetings,
Fred Jan
On 17/03/2019 22.27, katja wrote:
Dan, the code isn't published but could be shared somewhere for the purpose of discussion if that is useful. Not sure what is a good place.
Frankly I've spent quite some time investigating the subject and my conclusion is: it is not at all self-evident what a mouse class should do exactly, even when just considering a widget. IEM GUIs have a single outlet that produce simple messages of their status. A widget for mouse data must produce several kinds of data. But being a GUI element it is also supposed to send and receive data cordless. Multiple message types over a single 'channel', that means we have to use message selectors even if the messages are just floats. And when using message selectors for cordless communication, it makes sense to do the same for the 'physical' outlet rather than define an outlet per message type. This alone makes it an anomaly among the GUI objects. It is not the only doubt that I had, maybe now is the time to discuss.
Despite my earlier promotional words about Pd's widgetbehavior infrastructure, I'd like to mention a major advantage of a 'message-to-canvas' approach if that is a feasible alternative: no need for Tk-related code in the class definition. If a mouse widget can be emulated as a GOP abstraction like proposed by Christof, existing IEM GUIs could be emulated in a similar fashion. Property boxes can also be implemented in the form of abstractions rather than Tk widgets. That is what I've done for my [mousepad] widget as well. As a bonus, the mouse widget itself can be incorporated in the properties box to manipulate the width and height of the object under concern. No need for cumbersome handles that double the code size!
Katja
On 3/17/19, Dan Wilcox danomatika@gmail.com wrote:
Katja: Do you have some sample code using this implementation? I've not looked into this in depth yet.
On Mar 17, 2019, at 4:38 PM, katja katjavetter@gmail.com wrote:
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.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Mousepad code is up for inspection at:
https://github.com/katjav/pd-mouse-trial
So far it was built on Linux and tested with Pd 0.48 and 0.49, not sure if it will work right away on other platforms.
The implementation is unconventional; it doesn't use the iemgui framework and replaces Tk properties dialog by an abstraction. This is done for reasons explained in the code but I'm not enough of a developer to know the difference between innovation and aberration. For the moment, maybe just try the test patches to get an impression of what mousepad can and can't do.
Katja
On 3/17/19, Dan Wilcox danomatika@gmail.com wrote:
Katja: Do you have some sample code using this implementation? I've not looked into this in depth yet.
On Mar 17, 2019, at 4:38 PM, katja katjavetter@gmail.com wrote:
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.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Hi Katja, et al
Just tried this in Mojave, it works really nice!
I just made an issue with a bit more info: https://github.com/katjav/pd-mouse-trial/issues/1
Hope it helps!
fede
On Tue, Mar 19, 2019 at 4:19 PM katja katjavetter@gmail.com wrote:
Mousepad code is up for inspection at:
https://github.com/katjav/pd-mouse-trial
So far it was built on Linux and tested with Pd 0.48 and 0.49, not sure if it will work right away on other platforms.
The implementation is unconventional; it doesn't use the iemgui framework and replaces Tk properties dialog by an abstraction. This is done for reasons explained in the code but I'm not enough of a developer to know the difference between innovation and aberration. For the moment, maybe just try the test patches to get an impression of what mousepad can and can't do.
Katja
On 3/17/19, Dan Wilcox danomatika@gmail.com wrote:
Katja: Do you have some sample code using this implementation? I've not looked into this in depth yet.
On Mar 17, 2019, at 4:38 PM, katja katjavetter@gmail.com wrote:
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.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 19/3/19 11:17 pm, katja wrote:
Mousepad code is up for inspection at:
This is great!
Cheers,
Chris.
I love the idea of a native 2d slider, but how about providing the same functionality from [cyclone/mousestate]?
Em qui, 21 de mar de 2019 às 01:47, Chris McCormick chris@mccormick.cx escreveu:
On 19/3/19 11:17 pm, katja wrote:
Mousepad code is up for inspection at:
This is great!
Cheers,
Chris.
My tech development newsletter: https://mccormick.cx/subscribe
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
[cyclone/mousestate] is very raw compared to [mousepad]. You can have one or more [cyclone/mousestate] and they all will just output the same xy coords for the screen (not the patch).
Probably is very easy for [mousepad] to incorporate an option like "global sender" to give the same functionality as [cyclone/mousestate].
[mousepad] is totally cool.
:)
Mensaje telepatico asistido por maquinas.
On 3/21/2019 5:30 AM, Alexandre Torres Porres wrote: I love the idea of a native 2d slider, but how about providing the same functionality from [cyclone/mousestate]?
Em qui, 21 de mar de 2019 às 01:47, Chris McCormick <chris@mccormick.cxmailto:chris@mccormick.cx> escreveu: On 19/3/19 11:17 pm, katja wrote:
Mousepad code is up for inspection at:
This is great!
Cheers,
Chris.
My tech development newsletter: https://mccormick.cx/subscribe
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 3/21/2019 6:18 AM, Lucas Cordiviola wrote:
You can have one or more [cyclone/mousestate] and they all will just output the same xy coords for the screen (not the patch).
I meant many [mousestate] in different opened patches.
Mensaje telepatico asistido por maquinas.
Em qui, 21 de mar de 2019 às 06:18, Lucas Cordiviola lucarda27@hotmail.com escreveu:
[cyclone/mousestate] is very raw compared to [mousepad]. You can have one or more [cyclone/mousestate] and they all will just output the same xy coords for the screen (not the patch).
actually there are 3 modes of operation in [mousestate], but it's not like I'm defendind the idea we should have the exact same object, design and functionalities
Probably is very easy for [mousepad] to incorporate an option like "global sender" to give the same functionality as [cyclone/mousestate].
yup, I think so. I'd be happy with just being able to get mouse clicks anywhere in my patch window along with coordinates (which could be for the whole screen or relative to the patch window, two of the options from [mousestate].
Well, I don't know, what do you all think?
cheers
Hi, the concepts of [mousestate] and [mousepad] are different, they complement each other. [mousepad] is a widget, like slider & Co. If they are stacked, only one at a time can have mouse focus. [mousestate] doesn't steal mouse focus of widgets above it. Both concepts have their own use cases.
Katja
On 3/21/19, Alexandre Torres Porres porres@gmail.com wrote:
Em qui, 21 de mar de 2019 às 06:18, Lucas Cordiviola lucarda27@hotmail.com escreveu:
[cyclone/mousestate] is very raw compared to [mousepad]. You can have one or more [cyclone/mousestate] and they all will just output the same xy coords for the screen (not the patch).
actually there are 3 modes of operation in [mousestate], but it's not like I'm defendind the idea we should have the exact same object, design and functionalities
Probably is very easy for [mousepad] to incorporate an option like "global sender" to give the same functionality as [cyclone/mousestate].
yup, I think so. I'd be happy with just being able to get mouse clicks anywhere in my patch window along with coordinates (which could be for the whole screen or relative to the patch window, two of the options from [mousestate].
Well, I don't know, what do you all think?
cheers
Yeah, I think you're right Katja.
But i could still ask how about providing the same functionality from [cyclone/mousestate], but maybe in another mouse oriented object? Not sure how to call it.
Em qui, 21 de mar de 2019 às 17:23, katja katjavetter@gmail.com escreveu:
Hi, the concepts of [mousestate] and [mousepad] are different, they complement each other. [mousepad] is a widget, like slider & Co. If they are stacked, only one at a time can have mouse focus. [mousestate] doesn't steal mouse focus of widgets above it. Both concepts have their own use cases.
Katja
On 3/21/19, Alexandre Torres Porres porres@gmail.com wrote:
Em qui, 21 de mar de 2019 às 06:18, Lucas Cordiviola lucarda27@hotmail.com escreveu:
[cyclone/mousestate] is very raw compared to [mousepad]. You can have
one
or more [cyclone/mousestate] and they all will just output the same xy coords for the screen (not the patch).
actually there are 3 modes of operation in [mousestate], but it's not
like
I'm defendind the idea we should have the exact same object, design and functionalities
Probably is very easy for [mousepad] to incorporate an option like "global sender" to give the same functionality as [cyclone/mousestate].
yup, I think so. I'd be happy with just being able to get mouse clicks anywhere in my patch window along with coordinates (which could be for
the
whole screen or relative to the patch window, two of the options from [mousestate].
Well, I don't know, what do you all think?
cheers
What will be provided in Pd (if any of this) is up to Miller of course. The current discussion explores implementation options and challenges. [mousestate] in mode 1 ('patch relative') comes close to 'GOP-relative' mouse tracking as proposed by Christof Ressi earlier in this thread.
Unfortunately cyclone GUI bypasses Pd own GUI framework to a large extent and is still full of 'LATER rethink' and 'FIXME'. That makes it hard to learn from [mousestate] how to design a mouse class to be (hopefully) embedded in vanilla. Maybe a cyclone expert can port [mousestate] to a version employing Pd's own GUI API / core functions to the best possible extent. With that achieved it will be a small step to upgrade 'patch-relative' to the more useful 'GOP-relative'. Such a class would be a dream to have in vanilla.
To be clear: the [mousepad] trial, using Pd's widgetbehavior interface, can not reasonably be extended to include [mousestate]'s canvas/screen-wide functionality. These are two totally different behaviors. A class should do one thing, and do it well.
Katja
On 3/21/19, Alexandre Torres Porres porres@gmail.com wrote:
Yeah, I think you're right Katja.
But i could still ask how about providing the same functionality from [cyclone/mousestate], but maybe in another mouse oriented object? Not sure how to call it.
Em qui, 21 de mar de 2019 às 17:23, katja katjavetter@gmail.com escreveu:
Hi, the concepts of [mousestate] and [mousepad] are different, they complement each other. [mousepad] is a widget, like slider & Co. If they are stacked, only one at a time can have mouse focus. [mousestate] doesn't steal mouse focus of widgets above it. Both concepts have their own use cases.
Katja
On 3/21/19, Alexandre Torres Porres porres@gmail.com wrote:
Em qui, 21 de mar de 2019 às 06:18, Lucas Cordiviola lucarda27@hotmail.com escreveu:
[cyclone/mousestate] is very raw compared to [mousepad]. You can have
one
or more [cyclone/mousestate] and they all will just output the same xy coords for the screen (not the patch).
actually there are 3 modes of operation in [mousestate], but it's not
like
I'm defendind the idea we should have the exact same object, design and functionalities
Probably is very easy for [mousepad] to incorporate an option like "global sender" to give the same functionality as [cyclone/mousestate].
yup, I think so. I'd be happy with just being able to get mouse clicks anywhere in my patch window along with coordinates (which could be for
the
whole screen or relative to the patch window, two of the options from [mousestate].
Well, I don't know, what do you all think?
cheers
Hi,
On 17/3/19 11:38 pm, katja wrote:
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?
Agree, and Jean-Yves suggestion on the other thread does this but from the Tk side which is not as useful as you need to have the user install a UI plugin to make it work. If a widget had mouse sensing like the one you describe elsewhere then you'd want it to universally receive mouseup.
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.
Yep and I think you've had a lot of experience with my exact use-case here which is touchscreen-enabled Raspberry Pi.
My preferred design (please excuse me while I ungratefully conjure a bunch of work for someone):
* Object just like cnv (hopefully just cnv). * Has a checkbox for "report mouse events". * When there is a mouse-down inside its rectangle it reports it with (x, y). * Once it has "grab" it outputs all mouse-move events with both (dx, dy) and also (x, y). * Once it has "grab" it catches the universal mouse-up event and reports it with (x, y). * (x, y) should be relative to the object's internal top-left position, so it can tell where the mouse is relative to itself.
The global receiver ideas are great and I am sure would be useful to others but for me personally at this time I can do that stuff with GUI plugins so it is less important.
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.
Exactly yes, with the [cnv] changes above you'd be able to build things like piano rolls, touch-pads, ribbon controllers, min-max selectors and probably many things we haven't thought of, as abstractions.
As you point out all of this would likely require modifying widgetbehaviour, unless mouse-up can be special-cased into one object like cnv.
Cheers,
Chris.
-
Alexandre Torres Porres -
Chris McCormick -
Christof Ressi -
Dan Wilcox -
Federico Camara Halac -
Fred Jan Kraan -
katja -
Lucas Cordiviola