Gum 2.0 Planning

[vchelaru]

Introduction

Gum 2.0 is a planned upgrade to the Gum UI tool which overhauls many of the existing systems.

Trello board: https://trello.com/b/yFK0tkeD/gum-20

Gum 2.0 Goals

Gum is a powerful UI tool but it has some limitations from the technologies used in the existing version of the tool. Gum 2.0 changes some of the main systems in Gum to address these limitations. The desired outcomes from Gum 2.0 are:

• New users no longer need to install the XNA runtime to run Gum since XNA will be replaced with a cross-platform rendering backend
• Ability to run Gum natively on Mac, and possibly Linux by replacing WPF and WinForms with Avalonia
• Improved performance from a modern version of .NET (8.0)
• Unified style and styling using Avalonia for dark mode and a more modern appearance
• Fix the "device has been lost" bug which occurs whenever the computer goes to sleep, a full-screen game takes over the graphics device, or an app is installed
• Better support for contributors using more unified and modern technology

We are also considering using SkiaSharp instead of MonoGame, which would provide the following benefits:

• Better support for clip regions, including rotated clip regions
• Simplified support for container-wide alpha and scaling
• Better font rendering support including infinite zooming and no pixelated textures - this may or may not be desirable depending on whether Gum users want to view things as they would be in MonoGame/FRB or not
• Anti-aliasing
• Better line/indicator support in tools by using Skia's path rendering
• More advanced rendering features for implementations non XNA-like implementations. In other words, Gum users who are not using Gum for games will benefit from a Skia rendering engine which would provide lots of functionality such as blurring, drop shadows, and other visual effects

The use of SkiaSharp does not necessarily need to happen immediately. If it's easier, we could use MonoGame to take advantage of the "RenderingLibrary" library. The editor window should be more of a plugin than it is in Gum 1.0 so that it can be swapped out later if desired.

Update 1

After having written this, I realize that using SkiaSharp would provide some benefits, but it would require a lot of additional new code. A lot of the existing edit window code will work if we stick to MonoGame instead of Skia so we'll use that for 2.0. Later versions can add plugins which allow SkiaSharp rendering.

Incremental Upgrading

While desirable, an incremental upgrade to Gum 2.0 is not possible. Currently some efforts have been made to modernize Gum incrementally. These include:

• Support for Skia rendering, so that Gum 2.0 could potentially use Skia for its rendering. The Skia rendering engine has been used extensively in a commercial project for many years. It is also used in a number of FlatRedBall Editor plugins so this technology has been proven.
• Separation of Gum core libraries from XNA/MonoGame. This happened in 2023 as a result of wanting to use Gum in a pure MonoGame environment without FlatRedBall. The new separation allows any rendering backend to be used with Gum and has been proven in a number of environments including XNA, MonoGame, Kni (web), SkiaSharp (in WPF, Xamarin.Forms, and backend SVG rendering), SAD console, and on a Meadow device.

The next incremental step would be to begin replacing parts of Gum UI with Avalonia islands. Unfortunately, Avalonia does not support .NET Framework 4.7, and upgrading Gum to a modern .NET would be complicated, and may break XNA support. Therefore, since the upgrade path is complex enough, it may be worth starting Gum 2.0 as a separate project.

It is important to note that the effort to create Gum 2.0 should attempt to reuse as much existing code as possible. The specifics of this will be outlined in the next section. Systems will only be rewritten if absolutely necessary. Also, Gum 2.0 will still be built incrementally and as it is built, we may find opportunities to reuse code from Gum 1.0 with small adjustments.

High Level System Discussions

TreeView

The current TreeView is using a modified WinForms tree view which originated at Wahoo/NinjaBee. The upgrade to Avalonia would require a new TreeView which supports multiselect and no selection on push. This is critical since Gum currently allows users to push+drag one component onto another Component/Screen, or into the wireframe preview window.

While this may seem simple, this push+drag without selection has always caused problems with both Gum and the FlatRedBall editor's TreeView (which is currently WPF).

Currently Gum's SelectedState object directly interacts with the TreeView (through a manager). Instead, we should incorporate a plugin style selection similar to FRB which pushes selections to a centralized object then notifies all plugins of the changed selection.

Editor Window (Wireframe)

The Editor Window, whether using SkiaSharp or MonoGame, should use the same object creation logic as is used in MonoGame projects. In other words, it should not have custom code for creating instances. Rather it should convert the elements to instances using the standard conversion tool, and also the standard variable assignments.

If using MonoGame, much of the editing logic can come over without changes, so this is a strong reason to use MonoGame instead of SkiaSharp. Unfortunately much of the editing logic may be intertwined with Gum rather than isolated into a separate plugin so this may make migration messy.

Core Libraries

This should use the core libraries that are used by MonoGame projects rather than the combined library that is part of Gum. All code should be the same, but the project structure should reflect a modern MonoGame project. If using SkiaSharp this also applies.

RecursiveVariableFinder

This should come over as-is from Gum, unchanged.

ObjectFinder

This should come over as-is from Gum, unchanged.

Undo

The undo system should come over from existing Gum unchanged. Although it is not perfect, it has worked fairly well and it is best to focus on the required changes.

File IO

This should come over as-is from Gum, unchanged.

DataUiGrid (PropertyGrid)

An Avalonia DataUiGrid will be necessary for viewing/setting properties. The existing DataUiGrid uses WPF so much of it may come over as-is to Avalonia. The Avalonia grid should attempt to reuse as much of the WPF DataUiGrid as possible, including using InstanceMembers so that existing Gum code can come over unchanged. By using InstanceMembers, the Avalonia grid could also be potentially re-used in FRB or other Avalonia-based tools in the future.

Plugin System

The plugin system should remain mostly unchanged, but may need modifications to support working with Avalonia rather than WPF.

Texture Coordiante Window

This should follow the same technology and upgrade path used to upgrade the main editor window. This is not high priority and can follow later.

State Animation

This should mostly come over unchanged, but if difficult this is a low-priority system that can come over later.

Milestones

Milestones will be tracked in Trello. Github's project system has many UI problems making it difficult to work with. Trello is much simpler to work with so it should be used instead.

The goal of each milestone is to make the smallest changes possible while still improving the project. Therefore, the first milestones may be the biggest of all milestones because they require the most changes just to get systems in place. At some point Gum 2.0 will be functional enough that we no longer need milestones, and instead we can move to Github issues for tasks. The point where this happens is unknown and we will decide as the project moves forward.

The following lists possible milestones. Note that as the project advances the likelihood that the later miles remain accurate goes down. This should be used not as a fixed roadmap but just a general idea of what kinds of things are needed for milestones.

Milestone 1

• Avalonia project created in the Gum repository
• Create a tab system similar to Gum 1.0's layout. A more dynamic tab system is acceptable but not required.
• Render a MonoGame window inside one of the tabs. This will get moved to a plugin so do not spend too much time getting actual Gum to work here.
• Tabs can resize
• All Gum projects are linked
• Gum project can be loaded into memory (ObjectFinder)

Milestone 2

• Plugin system brought over from Gum 1.0
• MonoGame rendering handled purely by a plugin, no MonoGame linked by the main project
• Instantiate one of the elements in a project and show it in the window - Create a File -> Load Project menu item. Select the .gumx. When the .gumx is selected, populate the ObjectFinder.

Milestone 3

• Avalonia multi-select treeview
• Show entire project in the treeview similar to Gum 1.0
• Allow drag+drop commands without selection. These don't have to do anything yet, just prove that it can be done with the treeview
• Display the element in the editor window according to selections
• Font cache logic

Milestone 4

• Camera - move, zoom
• Selection of objects in the wireframe, punchthrough

Milestone 5

• Move/resize
• Shift+move to move with axes

Milestone 6 - undos and file IO (saving)

Milestone 7 - state UI

Milestone 8 - Search

[akaadream]

Current state

Currently, the repository architecture is a main branch and eventually other branches for specific features.
The releases are created manually and there is no semantic versioning applied to the released versions of Gum.

For Gum 2.0

An idea to highly improve the project could be a better architecture for the project.

Branches

The branches should be at least main, staging, develop.
Contributors should still work on a fork and create a branch. 1 PR = 1 branch.

• The develop can only be merged to the staging branch
• The staging a branch used to test the application and can merge only to the main branch. It is forbidden to work on this branch.
• The main branch is the default branch where the current state of the application is located. It is forbidden to work on this branch.

Semantic Versionning

Usefull for the milestones, the application could have a version based on the semantic versionning convention. Then we would be able to use the tag system of Github allowing us to have a better tracking of the issues and help us managing milestones for the futures application updates.

Pipeline

Pipelines should be created to make automatic some tasks:

• The staging branch should have a serie of tests run on this branch. It is forbidden to merge on the main branch if the tests cannot pass.
• The main branch could have an action which build automatically the project and create a release based on this build.

[kaltinril]

Adding screenshot of the BUG "The graphics device has been lost. This means you must restart the app."

I was going to open a new ticket but found the old ticket and this 2.0 ticket.