[L2Ork-dev] Patch private abstractions

Fri Aug 14 01:12:27 EDT 2020

I think the core problem comes from two conflicting use cases:

1. I want to display the canvas of [ab foo] to get a view of the data
flowing in its instance
2. I want to revise the abstraction and apply those revisions to all instances

Number 1 pretty much requires that multiple instances can be
displayed/dirtied at the same time, at least with the introspection
tools in Purr Data/Pd Vanilla being what they currently are.

Number 2 requires that only one instance be dirtied at any given time.
I offer into evidence the limitations of Rust's borrow-checker as well
as Vim's annoying dialog when opening the same file twice :)

Anyway, with file-level abstractions users often start in one use case
and veer off into another.

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.

-Jonathan

On Thu, Aug 13, 2020 at 11:53 PM Matt Barber <brbrofsvl at gmail.com> wrote:
>
> Let's simplify.
>
> In Pd vanilla the file abstraction UX works like this:
> 1. Create a new file and save it, with or without some editing.
>
> 2. Load as object in desired patch; open and edit.
>
> 3. Eventually you have multiple instances. If you edit one and forget to save, you can edit another instance and lose everything from the first one if you save in the second one.
>
> 4. Somewhat inexplicably, there is a failsafe check in Pd (but not in Purr I think?) where if the instance canvas is dirty and you do something that selects the text of the corresponding object instance – you move it, or you click in the text field – you get a prompt which asks you if you want to save it.
>
> 5. If you edit an instance but don't save, and then load a new instance, none of those edits appear.
>
> The reason for a failsafe on 4 but not on 3 I think is just because it's a lot easier to implement, and would be kind of a pain for the user to have to pop every dirty instance and ask if you wanted it to be saved... saving a dirty canvas means that you're planning not to save changes in any subsequent one, so it should probably exit after any "Yes" selection. But that's a pain, so it's not a feature, and so users just get used to saving appropriately and crying if they accidentally kill a night's work.
>
> --------------------
>
> 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.
>
> 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].
>
> 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.
>
> I think all of this is also compatible with implicit storage of the definition or with [ab define] templates.
>
> ----------------------
> LATER
>
> consider a better failsafe for file abstractions and [ab ] abstractions.
>
> --------------------
>
> Am I missing anything obvious?
>
>
>
>
> On Thu, Aug 13, 2020 at 10:45 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>>
>> On Thu, Aug 13, 2020 at 6:38 PM Guillem Bartrina
>> <guillembartrina at gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > in the last meeting we discussed a bit about the fact the way ab private
>> > abstractions are saved (so the definition is updated) is a little
>> > counter-intuitive for users (e.j. creating a new instance of an
>> > abstraction that hasn't yet been saved gives us an empty canvas).
>> >
>> > On the one hand, I don't see a major issues here. The user just has to
>> > get used to saving the abstractions when he finishes editing them.
>> >
>> > On the other hand, there is the UX side. We can think of a situation
>> > where the user has edited the definition somewhere and forgot to save it
>> > (so it is still dirty) Then he creates new instances and they don't look
>> > as they should, so the user has to find the dirty canvas (perhaps among
>> > many others) and save it.
>>
>> Just as a measuring stick-- I think the ideal UX would be that any change a user
>> makes to a given instance *immediately* updates in all the other instances. Such
>> a design would remove the entire concept of a "dirty" [ab] so that "dirty" only
>> applies to the parent canvas.
>>
>> I *think* implementation details of Purr Data rule out such a design,
>> but I did want
>> to mention it as something to measure UX against.
>>
>> >
>> > An easy solution we came up with was to open the save dialog (Yes, No;
>> > the Cancel option doesn't make sense) within each dirty canvas every
>> > time we create a new instance (or when we close the file). The problem
>> > here is the case when we have multiple dirty canvases of the same
>> > private abstraction.
>>
>> Or even of different private abstractions. This is a problem with file-level
>> abstractions, too. It quickly becomes untenable to track what's going on when
>> abstractions keep popping up to ask for permission to be saved. At least in
>> my own experience, when the number of abstractions that pop up to show
>> the dialog is greater than 1, there is a 100% chance that I've forgotten
>> what I was doing and can no longer provide a useful answer to the dialog. :)
>>
>> >
>> > Do we want the user to go one by one, choosing Yes or No and keeping the
>> > definition of the last Yes-ed canvas? Or when the first Yes is clicked,
>> > all the remaining dirty canvases are discarded?
>> >
>> > Another approach could be to simply warn the user about the existence of
>> > dirty canvases of that private abstraction.
>> >
>> > Another could be a custom dialog (maybe using dialog_external) where all
>> > dirty canvases are listed and the user has to choose either one or none
>> > of them.
>>
>> I see at least one special case:
>>
>> 1. I create [ab new]
>> 2. I add some content to it.
>> 3. I may or may not close the window for [ab new].
>> 4. I create another [ab new].
>>
>> 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.
>>
>> 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?
>>
>> >
>> >
>> > Tomorrow I will also write about the absontrol/absanity topic and some
>> > other things.
>>
>> Sounds good!
>>
>> Best,
>> Jonathan
>>
>> >
>> > Best,
>> >
>> >
>> >
>> > _______________________________________________
>> > L2Ork-dev mailing list
>> > L2Ork-dev at disis.music.vt.edu
>> > https://disis.music.vt.edu/listinfo/l2ork-dev
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> https://disis.music.vt.edu/listinfo/l2ork-dev
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev