LinwoodDev
[Feature request]: Splitting rendering and handler logic into own package
Is your feature request related to a problem? Please describe
Linwood Setonix uses Flame which is a bit tricky to use. Since Butterfly has it's own Rendering Engine we could use this to improve Setonix and improve the rendering system at the same time
Describe your feature request!
Create a package butterfly_engine with directory engine to put the handler and rendering logic in it.
I'm currently not sure about the license, maybe AGPL, maybe Apache (since it's technically a library).
It would be a big project since it is very interlinked into the app.
Additional context
For a potential license change:
@chriscavalluzzi what do you think about splitting this into it's own library and giving it a new license?
Code of Conduct
- [x] I agree to follow this project's Code of Conduct
Hey :)
I think this is a fun idea, but like you said, it would probably be a ton of work. My only other caveat would be that there are some open issues related to the performance of Butterfly's rendering engine when there are lots of renderers on the page, which I imagine would probably also be an issue for games once they reach a certain scale. But of course, using the engine in more than one project would just be more incentive to solve those issues!
And just to be thorough, there is also the option of exploring more engines that have been built by others, some of which have the benefit of being very mature, performant, and having large communities. However, I realize how fun it is to build everything yourself, so I wouldn't blame you for not wanting to do this :)
So if you think the benefit to Setonix would be worth the effort required to decouple the engine from Butterfly, and if you think any performance issues would either be solvable or irrelevant, and if you would not rather explore other engines, then I say go for it! (Though I think it would be wise to wait until after Butterfly's next stable release before starting the changes in Butterfly, since the transition will probably be bug-prone.)
For the license, Apache 2.0 is a wonderfully-permissive license, and MIT is even more so! AGPLv3 is great for ensuring related projects are source-available, but it comes with a lot of restrictions that could deter interested parties (like how all projects using the library would need to also be distributed under AGPLv3, which they may not want to do). This is of course entirely your decision, so I guess it just depends on if you would rather give people freedom to create non-free works (MIT/Apache) vs. force them to abide by certain rules (AGPL)
Yeah,
This would be a lot of work since the rendering is very tight to the CurrentIndexCubit which also holds values like the navigator page state, the current tool which shouldn't be out of the engine. But it could help separating the app from the engine which could also help solving future issues that happens because of the connection.
I also searched for other engines and only found flame which is currently working but is really much connected to games with components. I tried some things there but also had some issues: https://github.com/flame-engine/flame/issues/3270 which also results in performance problems. Other than that, I see the butterfly engine like a "graphics engine" rather than a "game engine" where you can decide if you are going the game engine route and use renderers like game objects where you can interact or a graphic engine where you can handle the events on a root level. Flame also lacks on some input events which is related to parts of the code being a bit outdated.
I have the same opinion. I would wait for 2.3 to finish and maybe start on 2.4 to work on this. Maybe I'm also working on a different branch to do this, since 2.4 should also get more features than this refactoring.
On license side, I'm using the principle: Library -> Apache, Apps/Games -> AGPL.
I think Apache is better than MIT for patent rights and big industry and I'm also using this on my dart_pkgs repo.
I think you are also contributing on this rendering side so I need your permission to distribute it on a different license. Are you okay with that?
That all makes sense to me!
I think you are also contributing on this rendering side so I need your permission to distribute it on a different license. Are you okay with that?
Yes, you have my permission to do whatever you want with my contributions! Thanks for asking though :)