Tracking Issue: Code quality refactors

[0HyperCube]

Match statements

Some files contain a single match statement that are very long (e.g. portfolio 1356 lines, document 1335 lines, select 1070, path 799). This is rather hard to manage or debug.

• Split message handlers
• Move complex logic outside of the match statement

Cloning the document

History / transactions involve cloning the document many times. This very bad for performance and completely inflexible #2617 . The issue from 2021 still hasn't had any progress due to the enormous refactoring that would be involved in making a system with proper actions. The current system also creates much confusion when history interacts with tools (especially the pen tool #2262.

• Write a system whereby actions and their reverse can be stored instead. This will require a major refactor. I don't really want to undertake this whilst so many of the systems are in flux

UI

UI code is verbose and poorly structured. The current system is partially immediate mode, using all of our custom types. All of the UI is then diffed in a rather fragile way. The callback system is also rather confusing causing issues like #2530.

• Rewrite using a better UI library e.g. iced. Keavon wants to adopt some research project but I'm not sure this is a good idea.
• Make the API for the UI layout more like egui to improve simplicity.

Transforms & Click targets

Transforms are completely broken in many situations. Especially with the node graph allowing transform nodes in any position. There are a series of inconsistent hacks that work around this is certain common situations. However this isn't particularly ideal. The Instances only makes this more confusing. I'm not really sure how to solve this.

Click targets are very confusingly managed. This includes the path tool without a path node. This also interacts with the transform system in ways that aren't particularly robust.

The StartBuffer thing is exceedingly confusing. Each time there is an issue involving it, several hours must be spent trying to figure out what to do about it.

The relationship where the editor updates are theoretically independent of the node graph executor is very confusing since most tools rely on the node grpah being run at least most of the time. This is especially confusing when implementing tests.

I feel like the current systems and the way they interact with the node graph is very hacky. I think it would be best to discuss the requirements for the system to figure out why we have ended up in such a mess.

Tools

• Some tools have a confusing amount of state. For example PenToolData has 31 member variables which are only set is certain situations. This has lead to many bugs.
• FSM states are inconsistent and confusing. For example the select tool fsm state for Ready contains the NestedSelectionBehaviour and the Dragging state contains the has_dragged: bool for some reason?

I feel like some of the tools need a rewrite @Keavon. However there is always a lot of random churn.

Inputs

Rebinding inputs has been requested for a long time. However the input system has thousands of lines of macros involving many repeated things that would require a significant amount of refactoring to make a system that could be exposed to the user.

Translations

Translations are basically impossible to implement now since there are many thousands of string literals scattered all over the code including gcore, editor, frontend svelte etc.

Multiple documents

Having multiple documents visible at once seems to be a goal at some point. It is probably very useful for references / having a zoomed out overview etc. However we have hardcoded the active document many many times so it is basically impossible to refactor this.

SVG

Poor integration with SVG. SVG imports are all flattened to a path rather than maintaining any structure at all. Exports end up as a mess of nested groups that is mostly unusable.

Vector editing performance is very bad with large documents (e.g. try dragging a layer in the red dress demo artwork).