Full rewrite & redesign of PreonEngine #4
Labels
C-2 | consistency
Some code seems off compared to other code
C-2 | ease of use
Something seems much harder to do than it should be
M-0 | preon_engine
This issue applies solely to the preon_engine crate
M-0 | preon_module_xml
This issue applies solely to the preon_module_xml crate
Why
As proven by the lack of useful commits lately, this giant codebase is getting hard to maintain. This is mostly due to the inconsistency of it. Adding features is getting hard, because the point of PreonEngine was to not require a lot of code for a basic app, which as you might have notices, is going the wrong way. For example:
.start_texture()
to the UI..empty_*()
functions, because default styling makes them too small to see. You almost always have to write.start_*().min_size(..).expand_horizontally()
.Idea
The redesigned system will look like bevy and rocket.rs, create a new builder, attach stuff (modules), start.
File structure
File structure and naming should also be reconsidered, it can be confusing, for example:
rendering
module, even though it doesn't include a RenderModule by default.preon_engine/rendering
adds support for implementing your own RenderModules by including definitions for PreonShape and PreonRenderPass. The name makes sense, but it's confusing to newcomers.preon_engine/rendering
, thepreon_engine/components
file is gigantic and houses all logic, rendering, layout systems and definitions for all default components, and all code to make your own. 1100+ line files are just hard to maintain, especially when it does almost everything and code is randomly placedpreon_module_wgpu
is just kinda messed upCurrently, I am only happy with the organisation of
preon_engine/types
, it is very big and could possibly be split up by type. But as it isn't edited much, and it's sorted by type, that isn't top priority.The text was updated successfully, but these errors were encountered: