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):

I looked for the pd-tutorial page and tried these

canvas_dialog1.pd

ive got the range numbers wrong whatever

@FFW You need to hide the gop and then show it to force redraw, send 0 then 1 to the third argument. You also will want to send [dirty 0( to the canvas or pd will think the canvas has been edited and prompt you asking if you want to save changes.
gop.pd

@FFW You might have more luck using the coords message rather than donecanvasdialog.... as coords doesn't need the useful hacks that are mentioned above.
I have added a size message to an old gop demo patch and it seems to work reliably with a sub-patch.
I haven't checked for an abstraction
gop_switch_coords.pd
David.

Thank you all! I'm giving a try and will do a feedback.

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.

@oid A realtime on expr indicates a 8ms compute time. I'll try with your version.

I've added a change and a pipe to delay the switch.

It doesn't fix the comments problem, they only disappear when I save their containing abstraction (or when I reload the main patch).

Now I'm looking for a dynamically added and resized background canvas to get rid of the transparency.

@FFW This seems to work, but I can not quite see why yours does not work and I went through it removing every possible cause I could think of until I had pretty much this same patch, and it didn't work. Patch it together from scratch and it works, so probably something stupid and easy to miss in your patch and we are both missing the obvious. I added a third and fourth argument so you have shrunk width and hight and expanded width and height for args now and left some of the details for you to fill in.
ffw.pd

This seems pretty useful, easy way to make menus and dynamic interfaces, good idea to stick this in an abstraction, never dawned on me to do such a thing.

@oid this simple test doesn't work so it's certainly a bug with my system.

I have another issue with comments:

And [donecanvasdialog( is worse: all the guis remain visible as ghosts.

@FFW said:

And [donecanvasdialog( is worse: all the guis remain visible as ghosts.

With your version or with the one I posted?

Your issue with the seq helpfile is just an error in the helpfile, possibly who ever made it used a custom font which can cause such issues for everyone who uses the default fonts.

@oid even with the minimal test

EDIT:
I can force the redraw with

[zoom 2, zoom 1(
|
[sendcanvas]

@FFW That is because you are not sending 0 to the third argument and then 1 or 2 as I do in mine. Sending 0 to that argument disables GOP then sending 1 or 2 reenables it which tells pd to redraw and the reason for all that extra stuff at the bottom of mine. Try something like this for your minimal test:

This should make it work, donecanvasdialog does the exact same thing as the canvas properties dialog does when you click "ok" or "apply," this is the exact message the tcl/tk frontend sends to the pd core so if your canvas properties dialog works than this should work.

Edit: Fixed some errors in the image, had 1 instead of $1.