[L2Ork-dev] dynamic patching and undo/redo system

[Jonathan Wilkes]

On Fri, Jul 31, 2020 at 3:10 AM Albert Graef <aggraef at gmail.com> wrote:
>
> On Fri, Jul 31, 2020 at 5:34 AM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>>
>> What I mean is how do we differentiate between dynamic patching and a)
>> loading a patch or b) regular patching through
>> the g_editor.c event callbacks?
>
>
> Hmm yes, you're right. But after loading a patch its undo history should be empty anyway, right?

Yes. But we don't want to be making a call into the undo system for
each object that gets added to the glist. That could
quickly add up in terms of load time.

> (This assumes that the undo history is being kept locally in each patch, if not then all this becomes much harder.) So then we just need to distinguish dynamic patching from the g_editor.c event callbacks, in which case the necessary breadcrumbs could possibly be provided by the undo engine, or by those callbacks themselves. Yeah, it won't be pretty I'm afraid. :(

Yeah, it already severely hampers development time when I spot
something like "dont_redraw_this_time = 1" in the middle
of code I'm amending.

Perhaps I can start with the pointer delete method calling a function
that nukes the undo/redo history and warns about
that. Then each place where we call this function will create a new breadcrumb.

-Jonathan

>
> Albert
>
>> For example, there are no breadcrumbs left in canvas_obj to tell the
>> difference. And I'd hate to add a bunch more globals
>> to track "is_loading_stuff", "is_editing_stuff", "is_dynamically_patching", etc.
>>
>> -Jonathan
>>
>> >
>> > Albert
>> >
>> >> > On Mon, Jul 27, 2020 at 3:48 AM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> >> >>
>> >> >> Hi all,
>> >> >>
>> >> >> It appears that dynamic patching nnd the undo system are irreconcilable.
>> >> >>
>> >> >> For example-- Suppose you do this:
>> >> >>
>> >> >> [namecanvas foo]
>> >> >>
>> >> >> [obj 20 20 clip(
>> >> >> |
>> >> >> [send foo]
>> >> >>
>> >> >> Whenever you click the message box, a new object will be created but
>> >> >> without any undo history.
>> >> >>
>> >> >> That's probably desirable behavior, as we don't want a bunch of
>> >> >> dynamically created gumming up the undo system.
>> >> >>
>> >> >> However, the undo system is based off object indices. So by inserting
>> >> >> "[clip]" into a glist we corrupt that system. You can see this if
>> >> >> dynamic patching in the middle of other editing actions. Doing undo
>> >> >> then redo will put the patch in a corrupt state because the indices
>> >> >> will be off by one due to the "[clip]" object that the undo system
>> >> >> didn't expect.
>> >> >>
>> >> >> I don't know any clean way to deal with this. But it affects more than
>> >> >> dynamic patching:
>> >> >>
>> >> >> [pointer(
>> >> >> |
>> >> >> [canvasinfo]
>> >> >> |
>> >> >> [20 20 $1(
>> >> >> |
>> >> >> [append some_scalar x y]
>> >> >>
>> >> >> Same problem there, as well as:
>> >> >>
>> >> >> [pointer(
>> >> >> |
>> >> >> [canvasinfo]
>> >> >> |
>> >> >> [next, delete(
>> >> >> |
>> >> >> [pointer some-scalar]
>> >> >>
>> >> >> Each one breaks the assumptions of the undo system and undo/redo
>> >> >> actions can have wrong indices.
>> >> >>
>> >> >> Even more pressing-- now that we've got pointer delete method, the
>> >> >> undo system can have an out-of-bounds index and crash when it tries to
>> >> >> deference a null pointer.
>> >> >>
>> >> >> Any ideas on how to approach this?
>> >> >>
>> >> >> -Jonathan
>> >> >> _______________________________________________
>> >> >> L2Ork-dev mailing list
>> >> >> L2Ork-dev at disis.music.vt.edu
>> >> >> https://disis.music.vt.edu/listinfo/l2ork-dev
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Dr. Albert Gr"af
>> >> > Computer Music Research Group, JGU Mainz, Germany
>> >> > Email: aggraef at gmail.com, web: https://agraef.github.io/
>> >> > _______________________________________________
>> >> > 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
>> >
>> >
>> >
>> > --
>> > Dr. Albert Gr"af
>> > Computer Music Research Group, JGU Mainz, Germany
>> > Email: aggraef at gmail.com, web: https://agraef.github.io/
>> > _______________________________________________
>> > 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
>
>
>
> --
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email: aggraef at gmail.com, web: https://agraef.github.io/
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev