Migration from Notan

[Stoppedpuma]

Currently, Oculante is starting to fail to run and build on multiple systems, these in include the following:

• (Run) Ubuntu >=24.04

• (Run) Debian >=13 (GNOME)

• (Run) Arch Linux (GNOME)

• (Run) Anything using GNOME Wayland >=46 (Might affect earlier versions as well)

• (Build) NetBSD (May fail to run next release, fails to build master)

• (Build) NetBSD nasm >=3.0

• (Build) Linux with CMake >=4.0 (Currently known to affect NixOS build system)

There's a big issue which I've learned of from #743, NetBSD does not support Vulkan. This means that NetBSD may or may not be unable to build notan/glsl-to-spirv because of CMake 4.0+, nor can NetBSD use notan/shaderc since it requires Vulkan. This leads to the next section of this issue.

Moving away from Notan:

Currently, there's been plans to move to Bevy, or to go without an existing engine, creating our own implementations. Bevy seems to be the preferred option and would solve all of our issues we are constantly hitting with Notan. We also wouldn't have to worry about it being abandoned any time soon since it's a large project with a source of income via sponsors. This is a good thing, Bevy is well backed, has desirable features, and makes development easier in the long term.

This seems perfect, right? Turns out, unfortunately not. @0323pin raised an issue at #743 regarding our current build issues and has tried to build a few Bevy examples and they will seemingly not run. This is our only major issue that we know of with a bevy implementation so far.

What moving away from Notan accomplishes:

Notan has been our existing backend, it's done well I would say. So what's the issue with it? Notan is practically deprecated and is at the point where it's just causing more issues than it's worth. To keep this already long enough issue a bit shorter, this mainly consists of Notan specific bugs which will likely never be fixed in it's current state, parts of the codebase becoming a mess from Notan, preventing us from updating egui, and causing issues when building.

Moving away from Notan solves a bunch of problems and makes a bunch of improvements such as:

• A cleaner code base
• Less hacks to solve Notans shortcomings
• Being able to stay up to date with major dependencies like egui
• Solving build and runtime issues
• Fixes for Wayland
• Performance improvements
• Reducing build time

And probably a thousand more that I can't begin to think of until we make an implementation

Where this leaves us:

Oculante is probably the only project that does image viewing in an experience which I would describe as great or impressionable. I've introduced this project to several friends, all of which have fallen in love with Oculante. I would like this to run under as many operating systems as possible (within reason) for anyone to be able to use Oculante and experience this awesome program. The problem is, where do we go from here? Bevy seems to only run on the 4 major operating systems (Windows, macOS, Linux, FreeBSD). This prevents existing NetBSD users to continue use as well as from supporting other operating systems in the future.

So what do I think our options are? Well that's a bit of a handful. We could do any of the following as I see it:

• Attempt to get Bevy to run on NetBSD
• Create our own implementations
• Use / create an implementation specifically for NetBSD
• Drop NetBSD

If anyone reading this has anything to say on the matter, please feel free to leave a response!

The next release (0.9.3)

As of writing this, It's been 10 months and a day since the last release of Oculante. To summarise, there's been a shortage of time to work on Oculante, and this big task isn't helping. A release of 0.9.2.1 could technically release at any point with a few changes and fixes. The next major release on the other hand should have these changes and will take a while to get things perfect and make a bunch of the changes we want to like removing old useless dependencies.

[woelper]

My thinking as of now (mostly leaving thoughts here, feel free to challenge)

1. Merge or kill all PRs rigorously, complete freeze for new features
2. Merge or delete remaining branches
3. After 1 and 2, branch off master, remove Notan
4. Remove large image support (tiled display) or disable
5. Remove / disable Notan-specific functionality, decide which can be done with egui
6. Use egui to draw single texture, make sure texture memory is freed correctly
7. start with proper zoom / pan / viewport navigation
8. re-enable items disabled in 5
9. re-enable 4

[Stoppedpuma]

I agree with your thoughts. I believe a complete freeze for anything except fixes is a good idea. I believe putting master into a "maintenance mode" and changing the issue and PR formats to reflect that should get the message across.

Just to make we have the same thoughts on how the start would go, it would look something like this in order?

1. Brief review on existing PRs to see what's worth merging, close what isn't, merge what is.
2. Merge any existing branches with worthy improvements / bug fixes, delete what isn't
3. Put disclaimers that Oculante is in maintenance mode and we are only accepting bug fixes on master, longer delay between updates until the next major release, and that 0.9.3 will be the first version with the rewritten code.
4. Branch off master (maybe oculante-next would be a good branch name?)

If so, that sounds like a good plan. I'll start on the Github things after posting this comment and ping you on ones I'm unsure of.

Regarding the actual development on the other hand, I think it would be best to take this rewrite time to actually do the entire cleanup we originally planned while making improvements along the way. This includes going back to the drawing board on practically everything existing and new. For a rough example, the following ones we both probably agree on and comes right to mind:

Colours:

Colours are currently a mess to put shortly, I blame myself pretty heavily here for not having proper "design breakdowns". Basically how this is a mess is we kind of just put a mixture of things like Color32::White and Color32::from_hex:FFFFFF and they are kind of just scattered. How I would do this would be the following:

In a file like src/colours.rs or similar, we layout all the colours like this:

// Global / Shared Colours are simply "Colour_" or we could even do "Colour_Global_" / "Colour_Shared_"
let Colour_WarningYellow = Color32::from_hex("#FFCC00")
let Colour_ErrorRed = Color32::from_hex("FF0000")

// Theme specific Colours include their theme name (replace THEME with Dark or Light accordingly) "Colour_THEME"
let Colour_Dark_Text = Color32::from_hex("#CCCCCC")
let Colour_Dark_Button = Color32::from_hex("#26262")

let Colour_Light_Text = Color32::from_hex("#333333")
let Colour_Light_Button = Color32::from_hex("#FFFFFF")

Then we use this file in anything related to UI and use it appropriately instead of the mess we currently have.

Icons:

This ones a thing that's entirely on me, we should be making these locally. What this means using the directory at res/icons with all the SVGs and a shellscript to turn them into a font file (the current solution I do for creating one is an absolute mess). Or we just use the SVGs themselves which is easier all around and prevents needing to replace the icons.ttf file constantly.

Dependencies:

There's a lot we can drop, most recently this includes some like light-dark and egui-modal. It would be good to evaluate what's not needed anymore.

Giving some attention to the build scripts and actions:

I did a little work on this at #739, mainly updates. It's still a mess. This should be pretty easy and I can handle this (except maybe needing a bit of help with macOS and NetBSD since they seem to have been giving me nothing but a fight) if you would like me to.

Unit testing and better debugging tools:

Big one! This has been put on the backburner for a while but will make future releases less likely to contain bugs and easier for users to report them. As of 0.30.0, egui has a UI unit testing crate called egui_kittest (https://github.com/emilk/egui/tree/main/crates/egui_kittest). This would allow us to automate unit tests (and we should likely require all new features to have a written test to go with it). In my opinion, the best unit testing implementation is in osu! which you can see below:

tests.webm

Regarding debugging tools, a draw visualiser and global statistics would be awesome for quickly finding things and seeing additional details about them. The same project as above does an amazing job at this as well.

draw_visualiser.webm

Lastly to close this off since it's already way longer than I originally intended, have you made a decision on if we're moving to bevy? I think it's a good choice, but the NetBSD incompatibility is unfortunate.