[L2Ork-dev] Patch private abstractions

[Guillem Bartrina]

Jonathan wrote:

> In all cases I can think of, the user will want that 2nd instance to
> be filled with the
> contents they added to the 1st instance, *regardless*  of whether they saved the
> contents in the first instance.

Yes. The problem here is the case that we have multiple dirty instances of that abstraction. Which one do we pick?
For this reason I set out this problem as if we saved all dirty instances before creating the new one. In this way the new one is created using the latest definition.

> Also: if I create [ab new] and there are currently no definitions for
> "new", shouldn't
> the subpatch window automatically be displayed like [pd]? What's the
> use case where
> the user doesn't immediately want to start adding content to that
> private abstraction?

Yes, It was implemented in the first instance but I removed it because it caused problems during the reloading of the instances. It's on my TODO list.

-----------------------
Matt wrote:

> *explanation of pd vanilla abstraction UX*

Thanks for the clear explanation.

> So for [ab ] objects, the UX could be more or less identical, but there are
> two options:

> A. [ab ] canvases themselves are marked dirty, and saving them updates the
> definition in memory but not in the file. To do that, you have to save in a
> root window or [pd] subpatch etc.

This is how it is currently implemented. I think it is the closest thing to how file abstractions work and therefore, since we are talking about private abstractions, how they should behave.

> B. a change in an [ab ] canvas marks the root dirty, as with [pd ]
> canvases. Suppose you've edited several instances without an intervening
> save, when you do save, which of the edits should be saved? Probably
> whichever one was most recently edited, and damn the rest, with wailing and
> gnashing of teeth if you edited the wrong one most recently.

> I *think* that the 4. failsafe above would be possible with both of these
> options. And if you went with option B. here, there's no harm if, as with
> 5. above, new instances don't reflect unsaved changes, so long that making
> a new instance doesn't count as most recently edited – the user will
> probably default to "oh shit forgot to save" and then save immediately, so
> that should reflect the desired result. I think both options are also
> compatible with an [ab define].

This approach brings private abstractions closer to subpatches. I see a couple of problems here:
- We cannot save/update an ab definition without saving the whole file, which can lead us to side effects.
- Saving the most recently edited instance canvas is also confusing for the user. It's kinda inconsistent and can be the source of many problems. Every time the user wants to save/update the definition, will be forced to check if the one that he wants to save is actually the last one he edited. Maybe a visual mark of which has been edited the latest could be useful.
- It forces us to keep track of which is the last edited instance canvas.

> Dynamic patching marks no canvas as dirty unless there are mouse/keyboard
> events. Assuming there aren't, with option B, a save should not save the
> dynamically patched results of any instance, but keep the original
> definition. Option B. amounts more or less to keeping track of a
> pseudo-dirty flag on each [ab] canvas, reflected as an actual dirty on root.

The dynamic patching stuff is doable as long as the user doesn't open an instance canvas with dynamically created objects, edit the patch and save it. In this case, all dynamically created
objects will be saved as well, as with file abstractions.

--------------
Jonathan wrote:

> I think it's an argument for explicit definition. But to keep on the
> implicit definition bandwagon, here's a wacky solution:

> 1. First [ab foo] instance to be dirtied gets flagged as the "primary"
> 2. Subsequent instances which get dirtied get flagged as "secondary"
> 3. CSS of "secondary" has a background with the words "temporary:
> cannot save" or something.
> 4. If a user attempts to save "secondary" instance a dialog pops up
> telling them it's not allowed, perhaps offering to make visible the
> "primary" dirty subpatch.

> That probably way more complicated than needed. I'm just trying to
> grope toward behavior where the dialog
> and UI gives the user a fighting chance.

This another affordable option.

--------------

Well, I think that we should first consider if we really want to continue with this implicit definitions approach. It is clear that this is the most ergonomic way for the user but at the same time it forces us to design and implement some non-trivial patches to cover all its flaws: the saving problem, the multiple dirty canvases problem, the dynamic patching problem, the 0 instance problem (aka abcontrol/absanity) and so on.
*Note that some of them are also present with file abstractions, so we need to consider if we want prioritize coherence between them or if we want to solve the problems only for private abstractions (and maybe for file abstractions at the same time, idk)


If I'm not missing anything obvious, using [ab define] we would get rid of all mentioned problems but on the other hand we lose a bunch of dynamism. Moreover, some other problems may appear: scope problems, dependency problems and so on.

I'm still liking implicit definitions the most, so I'm going to continue developing them until we reach a wall that forces us to change focus or until we get something more or less consistent and usable.

--------------


Best,