Closed raeleus closed 2 months ago
Wow! I knew this was going to be big, I didn't know how big! I need to figure out how I can test and run this...
I think mixing Kotlin and Java via interop should be fine; Liftoff at one point had more Java than Kotlin (I think) because it had two or three large LML-related libraries copied into the sources to make small changes. The only reasons to use absolutely pure Java would be file size, and to target GWT for some reason, but we could use TeaVM if there's a Kotlin-Java mix. Generating files would still be hard on any web target.
Also, welcome back (?) @Frosty-J !
So I really have not much idea of what next step I can take. The UI works, it just isn't hooked up to generation. I'm thinking I might spin this off into its own repo, somehow, so I can work on it and get the commits counted... then I can bring back my changes to this PR, merge it, and fix any remaining issues in the main branch here. I want to have this UI in place before I start updating the docs for Liftoff, because the experience would not be the same with the old and new UI.
I think that would be great! That would enable us to start breaking changes too, so that would be nice. I shared the same concern about documentation. Feel free to message me for input whenever. This will be my top priority outside of game jams. Thank you so much!
The changes from https://github.com/tommyettinger/gdx-liftoff-ui-redesign have now been merged into this PR. This is a pretty huge change, and the UI really looks worlds apart from the old one. There's currently a mix of Kotlin and Java code, and some code I'm thinking I will eventually pick apart to fully remove LML and Autumn from the codebase. Autumn in particular was a disaster to get working in a system other than the original Liftoff codebase... I just ended up manually listing anything that would have been dependency-injected, because even that took drastically less time than Autumn was requiring to still not work. LML for GUI isn't needed because the scene2d.ui code doesn't use it on the Java side. However, the Kotlin code to launch the old UI is still present, though it can't easily be launched and probably doesn't work. Stuff like that can be removed in the future. The raw vector assets, where we have them, can also be updated in the future.
This PR is a complete overhaul of the GDX-Liftoff user interface. The goals are as follows:
The work that has been done:
This is probably the limit of what I can do on my own since I barely understand Kotlin. I need your help and direction at this point. The work that still needs to be done:
CompletePanel
You can test the project by running the Main method in the Main.java class. Clicking the square button in the top right activates the "maximized" mode. In the code I refer to this interchangeably with "fullscreen," though that is a misnomer. I do not intend to activate true fullscreen mode because that's kind of janky for a utility app.
I created a new nls.properties in resources/ui-data so that my changes won't affect the original app. I created separate properties files for URL's and app defaults because it's the easiest way to manipulate data in Idea.
Users annoyed with the startup animation can simply click to bypass it or just use the maximized mode. If you exit the app while in maximized mode, next time the app will start in maximized mode. This will all be explained in text-based and video tutorials which I can develop for libgdx.com and your repo.
With that in mind, I intend to continue to support development of GDX Liftoff as the new official libGDX setup app. I will commit continued longterm support just as I have for the new Particle Editor. I will assist you with any new UI features or tweaks you may need as that is my strength.
The aim of this PR draft is to get you first hand experience with the GUI so I can make any changes you need. You can also take a look at my code structure and see if it's too annoying for you to maintain in its current state. Finally, you can help me with project generation because I'm clueless there. The goal is to convert all that code into Java, but if you'd rather do Java/Kotlin interop that's fine. I just foresee that being incredibly messy in the long term. I'm willing to discuss any of your needs. Thanks!