[L2Ork-dev] GSOC – auto abstraction save

[Matt Barber]

Hello,

Guillem and I have been discussing what the user should see when converting
a subpatch to an abstraction, for his GSOC project. There are many
possibilities; here's one scenario I came up with as a starting point (w/
some additions by Guillem):

1. User is in a subpatch window OR has a single [pd ] object selected
(Guillem added right-click popup for the latter scenario – extremely
convenient, and could have the same thing right-clicking subpatch canvas).
2. They hit the hotkey/menu/whatever.
3. Up comes the file chooser. Suppose they want to store it in a "Tools"
directory, which is in the same directory as the root patch.
4. Get path from that selection, and convert to relative path if possible.
5. Bring up new dialog asking if they want to replace the subpatch with the
abstraction yes/no, and a toggle to "try to replace every copied instance
of this subpatch with abstraction". They hit "yes"
6. If the Tools path is [declare]ed on the root patch, replace the subpatch
with the abstraction basename. Otherwise, [Tools/basename]. If the toggle
was selected, run routine to go through the root patch and compare binbuf
for replacement.
7. Preserve connections, of course.
8. Anything to do about the new abstraction creation arguments? Presumably
nothing.
9. What to do about subpatch recursion? Ico suggested throwing an error
like when you try to include an instance of an abstraction in itself.
10. What does undo do? I think it must undo the subpatch replacement(s), if
any.
11. What happens with namespace clash? If I save with an object name that
already exists, I think it throws an error only if you try to replace.

Much of the complexity is due to path. Any way to simplify? Could bring up
the secondary dialog to replace subpatches only if the path is at the same
level as or deeper than the root patch, so no ../ or absolute paths.

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200701/e14c8e5f/attachment.html>