Hi,
does exist a template for an expandable GOP?

I do this but the controls are not hidden when the switch is set off (they remain visible out of the abstraction box):

It works well!
I'm using a canvas to set the enlarged size and the switch move to the right dynamically.

expandable.pd

Is it possible to detect when the mouse is in/out of the gop to switch the size accordingly?

@FFW Yes...... well it was in Pd extended..... so maybe......
You would need to modify [mouse_region] from the HCS library.
It shows coordinates and constrains output to the mouse presence inside the GOP area.
You would need to remove the mouse click and drag constraint, using just the position so that you get bangs or coordinates only when the mouse is in the gop area.
It needs externals from PurePd and others probably.
You will be able to modify it to do what you want, and it should be more simple when done.
There will be other ways to achieve the same thing as long as you have the mouse coordinates from the window...... coordinates from the screen would not work.
David.

@FFW I do something like this:

Needs an [expr] with some if statements or a few [moses] and comparison/[expr if] to finish it up, but I think that shows the logic?

@oid +1000 !

I'd like to put this whole logic in an abstraction so I'll can reuse it but I don't find how to sendcanvas
to the parent patch

@FFW As far as I am aware there is no good way to determine how deeply nested in the patch an abstraction is. In the past when I have needed this I have used [canvasindex] since it produces no output if toplevel, something like this:

Possibly warrants a feature request on the pd github, results may happen quicker with an iemguts feature request but I am not sure if umlaeute has any interest in extending the features of iemguts but he is quick about dealing with bugs. Probably will not be a feature of vanilla anytime soon since the official way to deal with such things is [namecanvas] and named canvases which covers most use cases. With how things currently stand, numerical depth is more suited to the iemguts workflow than the pd workflow,

Edit: Not completly certain I understood you use case. Do you actually need to determine depth? Is the issue nested canvases? If depth is constant then [iemguts/sendcanvas] will solve your issue. I suspect my post was going the wrong direction and you don't need to worry about depth?

@oid my bad, I wasn't clear enough.
I've done what I mind:

makeExpandable.pd

I've an issue with comments which remain visible when the gop is shrunk.

@FFW That one was my bad, I had not looked closely enough at your screenshot before responding. I am not seeing an obvious cause of your issue but a couple things jump out at me and could be troublesome. You are sending two coords messages for EVERY motion event on the parent canvas, put a [change -1] between the [expr] and the [sel 1] so it only does it once when the state actually needs to change. This will also make your expand and shrink methods work as expected, as of now if you send [expend( to the left inlet when the mouse is outside of the GOP it will immediately shrink back down the second the mouse moves, which I don't think is what you want?

Something like this would also be considerably more efficient than your [expr], as you have things now if you had 20 abstractions in the canvas which use this you do the [expr] 20 times for every motion event, that could really add up and cause problems, Did not test this, believe I have the logic right but if I don't it should demonstrate it. Obviously you would want to update x-max and y-max on every expand/shrink.

Adding in the [change] might fix things, pd might be getting confused by all those coords messages you are sending, not sure, no time to dig into it right now.