Gbx Explorer 2 Design (Nov 2023 ‐ Dec 2023)

Idea

New idea of Gbx Explorer is to not only support Gbx file modification, but also full creation from the ground up (including custom node types), so that we don't have to ever think of the Hex editor again.

Structure & portability

Gbx Explorer 2 should be supported both as a web application (PWA, desktop-first) and as a native executable running under Photino.NET Blazor. There are 5 subprojects to this idea:

graph TD
    A(Shared) --> B(Server)
    A ---> C(Component)
    B -.-|HTTP| C
    C --> D(Client)
    C --> E(Photino)

Loading

• Component - uses Shared
  • Razor component containing the whole Gbx Explorer interface
  • Must not depend on Server - directly and by availability
  • Reusable in different projects
  • Support NuGet packaging
  • Logging via ILogger, similar to previous Gbx Explorer
  • Settings:
    • Server connection URL
  • Use GBX.NET.Extensions.Logging implementation
• Client - uses Component
  • Blazor WebAssembly (PWA) app
  • Additional web browser features
  • Find a way for a near-perfect auto-updator (cache bust)
  • Supported on GitHub Pages
• Server - host of Client, uses Shared
  • Script/plugin center API
    • Minimal API
    • Validators - FluentValidation
    • OpenAPI integration
    • GitHub authentication - per user + per server
  • EF Core communication with SQLite/MariaDB/Postgres
  • Serilog for logging, but with ILogger
  • Cookie policy?
  • Compression techniques
  • Lazy loading
  • Support Docker containers
  • Integrate Dashboard like Seq, but maybe find something better
• Shared
  • Shared logic between Component and Server
  • DTO models
• Photino - Desktop implementation of Component
  • Photino.NET app
  • Direct Gbx file opening
  • UserData directory analysis
  • Works on Windows, Mac, Linux
  • Auto-update

User interface

You should be able to drag & drop files anywhere on the screen. There should be also a smaller import button so that drag and dropping is not required.

There should be multiple theme support based on a class that you can switch.

The UI is made out of two columns and a limited amount of expandable right panels.

Importing

• Allow imports of ZIP files, that will scroll through all Gbx files in there
• On mobile, the import button should be in the middle bottom

Navigation

Navigation is the first column. It will hide under hamburger if the width of the screen is too small for the second column.

• Logo at the top, version in the corner of the logo
• List of Gbx/Pak files, which will become scrollable in its own scope
  • Selectable, moveable, deletable
• An "advertised" list of Gbxs which anyone can close at any time, or it will dissapear once more Gbx/Pak files were imported
  • It will mainly serve as a solution to the "I wanna try the app but I don't have any Gbx files" problem.
  • It could be possible to advertise approved Gbx files there for money, but it might be too difficult and controversial to implement
• List of socials
• Copyright

Node Tree Explorer

• File name at the top
• Class/type propeties below the file name
• Searchbar for searching for names (reflection should be cached in some way to speed this)
• Well-thought node tree (supporting pak files as a directory tree)

Horizontal scroll should work across the screen.

Right panels

There should be a vertical list of expandable panels to enable more functionality in Gbx Explorer. Currently:

• Header preview
• Value preview
• Plugins
• Export

Editor

• Start from scratch by just selecting the class
• Import chunk data as "property packages"
• Possibility to select game version with predefined chunks

Scripting

Scripting will be integrated using interop of the official C API that was compiled into WebAssembly, to allow maximum performance and full functionality, compared to ports that are usually outdated and not compatible with modern .NET features.

Scripting should be implemented in Component, while Server should have a stripped-down version for automatic validation, tests, etc. (implement in Shared and use trimming to do this?)

Testability

You should be able to validate your code by creating and executing test scripts, that work similarly to xUnit or any other unit testing project. This could make it easier to validate if the scripts don't break over time.

Lua

Scripts and plugins will be primarily written in Lua.

Python

https://docs.python.org/3/c-api/index.html#c-api-index

Monaco (BlazorMonaco)

Monaco is an open-source code editor used in Visual Studio Code, so it is a very welcoming editor for a lot of developers and hobbyists.

Any text file (Lua script, YAML, JSON, XML) edited in the browser should use Monaco for editing.

Certain Gbx node parameters could use Monaco too if the text data is large enough and this editor would be any helpful.

Pak

Gbx Explorer should support simple pak exploring, in a similar way like node exploring.