Proof of concept for editor prompt

[ChillerDragon]

It works but I did not spend any time on polishing it yet. Would something like this be merged with the design decisions I made? If yes I can finish this up. When finished it would be a big diff and should be merged fast otherwise it is annoying to maintain all the git conflicts.

https://github.com/ddnet/ddnet/assets/20344300/16d5961d-9ee6-47f5-a928-ef2355f9b67f

closes https://github.com/ddnet/ddnet/issues/7933

[archimede67]

I'm sorry I didn't see your mention in #7933. I am not currently working on this feature, however I also had as a project to rework the editor undo/redo to make it more maintainable and integrate this feature alongside it. Now if you already have something working, and you want to polish it, then you can go ahead (make it very pretty :)) and i'll try to integrate my rework later.

[ChillerDragon]

So whats the status here? Will this be merged if I use robstis approach?

[archimede67]

So whats the status here? Will this be merged if I use robstis approach?

In my opinion that's not the best approach, I don't know if you read the reply to one of Robyt3's comment, but basically this would lead to a huge number of member variables that would need to be manually added, registered, maintained, modified, etc. I am not a big fan of this approach in general.

[Robyt3]

General question: Should this feature eventually support multi-step actions? Or is every quick action only associated with exactly one UI button?

I would also go with the name "(quick) action" instead of "button".

So whats the status here? Will this be merged if I use robstis approach?

Depends on the answer to the question above. If you want to support multi-step actions then this requires some more thinking to properly support them. If you don't, then it should work like this with either approach. I don't like the dynamic memory allocations and usage of integer indices. If you think macros are useful then use them for now, but generate member variables for each individual action using the macros instead of using integer indices and dynamic memory allocation.

[ChillerDragon]

Should this feature eventually support multi-step actions? Or is every quick action only associated with exactly one UI button?

I have not given much thought yet to how many/which features of the editor should be covered by that. What would be a multi step action?

[Robyt3]

I have not given much thought yet to how many/which features of the editor should be covered by that.

You'll need to think about that before we can decide how to implement it.

What would be a multi step action?

Below some different examples for illustration. (They are not necessarily useful to implement.)

Example 1: with fixed steps

1. step: "Add layer"
2. step: "Tiles", "Quads", etc. (this list is static and known at compile time)

Example 2: with user input steps

1. step: "Change grid size"
2. step: "Change grid size: user inputs size as text"

Example 3: with dynamic steps

1. step: "Undo"
2. step: list of all actions that can be undone (this is dynamic based on the actions performed by the user)

Example 4: contrived example with many steps

1. step: "Start transaction"
2. step: perform several other actions
3. step: "Commit transaction" or "Rollback transaction"

[ChillerDragon]

Example 1: I would go with two actions here "Add tile layer", "Add quad layer" Example 2: Yea that sound nice. Example 3: Also sounds good. Example 4: Could be nice but sounds complicated to implement and also to use. Not sure if its worth it.

[Robyt3]

I think the current approach can only potentially handle example 1, where all actions are static. To support multi-step actions I would potentially put the current actions and their context information on a stack, so an action could additionally define which actions are available in the next step after it.