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.
 
 
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