UI Redesign

[raeleus]

This PR is a complete overhaul of the GDX-Liftoff user interface. The goals are as follows:

• Eliminate the use of LML
• Create a new, attractive look and feel
• Create workflows that benefit both new and experienced users to libGDX
• Shift design to Java instead of Kotlin to better suit the needs of contributors
• Ease transition from the old to the new. The maintainer can continue to update both the original and new GUI's until it has been determined that the new one is ready.

The work that has been done:

• A new UI skin has been developed
• Advanced layout widgets have been implemented to adapt to extremely small and extremely large displays
• Three workflows have been created: A normal workflow with smooth transitions and a sleek interface, a quick project workflow for users who want the most basic libgdx project, and a maximized workflow for large screens and simultaneous access to all controls.
• A searchable list of Third-Party libraries makes finding specific entries less cumbersome
• Fixes for minor annoyances such as scroll focus and being unable to see what a field is meant to represent
• Rewording of descriptive strings
• Context specific error labels
• App checks for new updates on startup
• All major screens have been implemented and tested
• User selections are stored statically in a UserData class ready for use in project creation
• JavaDocs and comments for all major classes
• Continues to use the same Preferences file as dictated by the old GUI

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:

• Project generation and linking the output to the label in the CompletePanel
• Change the build project to point to the Java code instead of the Kotlin code
• TextField filters (because I'm feeling lazy and drained)
• Converting the rest of your code to Java
• Reorganzing the project and adding any niceties you need going forward
• Removal of the old GUI (probably don't do this without extreme testing and introspective thought)

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!

[tommyettinger]

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 !

[tommyettinger]

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.

[raeleus]

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!

[tommyettinger]

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.