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
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
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:
We are also considering using SkiaSharp instead of MonoGame, which would provide the following benefits:
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:
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
Milestone 2
Milestone 3
Milestone 4
Milestone 5
Milestone 6 - undos and file IO (saving)
Milestone 7 - state UI
Milestone 8 - Search