Thoughts on new UI

[Frosty-J]

Here are my thoughts on the new UI, and maybe the old UI as well since I don't remember what was carried over:

• Having defaults for the project name etc. would be good for getting started quickly.
• Likewise, going through the project options should not be mandatory. If someone is new, it is likely to be overwhelming and lead to mistakes, e.g. they may set the Java version to whatever the latest is, or they may read the tooltip.
  • This is a side tangent, but Android does not really care what version of Java you target. As I've said before, stuff gets desugared... my Android 1.0 (2008) app is using lambdas (Java 8, 2014, also supported by RoboVM). To use Java 11 APIs, you may need to configure the desugar libs. Who can say for certain - most of the Java features I use are prehistoric.
• Allowing the user to continue past the first page with invalid entries is not ideal. On the last page, it gives no indication as to why the Generate button is greyed-out.
• Some of the menus, in particular the templates one, cannot be exited using the mouse if the window size is small, as they lack a close button.
  • I don't fully understand what's going on, but you can reproduce the tool opening smaller than intended like so:
  • Have two screens as follows. 1: Desktop scale > 100%. 2: Desktop scale = 100%.
  • With Windows Explorer on screen 1 (this is important!), open gdx-liftoff and hope it will appear on screen 2. I don't know how to influence this.
• The settings cannot be reset to default if the window is too small, as the reset button (and version number) disappear.
  • It's such a small button that it could be overlaid permanently without obstructing anything.
• The reset settings dialogue fails to remove keyboard focus from the UI behind it, despite capturing Enter to confirm.
• The third-party extensions are in a strange order, e.g. GDX Dialogs is D in the ordering but GDX Basis Universal is G. gdx-psx is under G but gdx-miniaudio is under M. And so on. It's very confusing to find what you're looking for without knowing where it might be in the list.
• Clicks that occur on the tool are queued up when the file picker is open. Mostly this just results in it opening again after picking the project folder, if the user double-clicked the button.
• The filepath separator being a backslash on Windows is not respected.
• Confirmation button order follows Windows norms. This is more of an observation than anything - I actually find it quite annoying in GIMP and whatnot that the buttons swap over depending on if I'm on Windows or a Unix system.

Is this being nitpicky? Maybe, but the process should be idiot-proof if this is to be the official setup tool.
Is this an exhaustive list? Actually, no, but it would be unreasonable to say "this has bad accessibility and uses too many system resources - please rewrite the entire thing." If you want to, you could investigate keyboard navigation, but last I looked it's a huge pain to do in Scene2D.

For anything that isn't a 2-second job, you may wish to pick which thoughts you care about, track them separately, and close this issue.

[tommyettinger]

Here are my thoughts on your thoughts on the new UI:

• You didn't number your list, so I may be replying to these out of order.
• Are you really sure you want to give me the power to default-name every lazily, hastily, carelessly made project out there? Just reminding you that I could make the default "StayFrosty" or "AskJamesWhatToNameThis".
  • I'm thinking "PleaseNameMe" and I'd include a 🥺 if I could.
• We do configure the desugar libs. You're thinking of gdx-setup.
• The next button should be changed to be disabled if any state is invalid on the current screen, I didn't realize this was the case.
• If the tool opens smaller than expected, what happens when you maximize it? Also, are you developing on a flip phone? How is your screen so small? I take it back, there are flip phones with large enough screens for the fullscreen mode.
• I think it was @raeleus ' decision to just not offer extra levels of support for people with six-pixel screens. There's the storyboard mode for any size screen, and the larger maximized screen for 1080p and up. If your screen isn't big enough for the storyboard mode, that is, a lot smaller than 1366x768, it won't be reflective of how nearly all users will play your game on desktop.
• I have no idea how to handle keyboard focus, but a certain UI-interested zebra probably knows.
• The ordering has been an issue in the older and newer Liftoff, though the new one can search. I think I can sort by display name.
• Dang file picker... It isn't code I ever wrote or would write, and there's no good solution to a file picker widget that I have found so far. I don't know why it would queue inputs.
• The path separator is perfectly valid as a forward slash on all platforms from Windows Vista onward. XP is dead.

So, to summarize, you seem to have two monitors, but they're both tiny or something? You should get bigger ones, to stop hurting your eyes. Maybe buy a movie theater screen and show the Bad Ballsy Benchmark to a cheering crowd. I think we can disable the Next button if there's something invalid on the current screen. I think the reset button can take full keyboard focus, though I have no idea how. I can personally try to fix the ordering right now. A default name/package/main-class is reasonable, though I do feel like unlimitedpower.gif . Nothing else seems especially easy to change.

[Frosty-J]

Here are my thoughts on your thoughts on my thoughts on the new UI. I'm not replying to all of them, leaving an air of mystery as to which reply is a reply to which of which which is a reply to which. Though we could (but certainly not should) ask the father of libGDX what he thinks about setting the window title of the new first impression of libGDX to AskJamesWhatToNameThis.

I didn't realise you have desugar 2.0.4 (the "default" one, no nio). That's the sharp shooting we hire you for.

I said window size, not screen size. Resizing it works but you can't rely on users knowing they have to do this to access a button. To visualise the initial window size at different secondary screen densities (I forgot screen 2 is my primary and 1 my secondary):

100%	150%	200%
As God intended.	Reset button and bottom-right version are absent without indication.	"Retina" display.

File picker: maybe all it needs is to be put on a separate thread so that Liftoff can process events while it's open and internally say to itself "hey, it's already open!"

Just because C:/ is valid doesn't mean it fits in when Windows itself and every other application I've ever seen would use C:\.

[tommyettinger]

I'm definitely confused by the HDPI junk, since I don't have an HDPI monitor and never have. I could probably set the resolution lower to imitate it, though. We can't reduce fonts to a much smaller size when the window is smaller; they just become illegible...

I am very reluctant to touch the file picker code. Just... look at it. We're on version 3.3.1 when 3.3.3 is out because its author (!) broke both versions since then. It is rather thorny.

Backslashes are for escapes, not file separators. If we use forward slashes, it works on all platforms. If we sometimes use backslashes, it breaks on MacOS and Linux.

[Frosty-J]

HDPI confuses me as well. I can reproduce the smaller-than-intended-window issue using the LWJGL3 version of Ballsy (LWJGL2 is fine) but not with GBTK Sort. I suppose we'll find out next year whether it's libGDX 1.12.2-SNAPSHOT that fixes it or if I've done something else that has the side effect of fixing it.

Backslashes don't have to break anything. For the record, I'm not saying to use backslashes everywhere - only on Windows. It can be completely cosmetic, e.g. replace / with \ for the textbox only. To embiggen the paragraph: Windows Explorer/Run doesn't accept forward slashes in UNC paths, though Liftoff manages to write to them without it or the Win32 API falling over.

Oh yeah, I forgot to write that on the final screen it performs no validation beyond checking that the selected folder is a directory. Might be worth having dropdowns for libGDX/Java versions or at least perform some basic validation such as checking it isn't blank.

[tommyettinger]

Validation is a good point... Java versions should be easy enough to wrangle. libGDX ones would need to be updated per Liftoff release, which isn't a huge issue since each Liftoff version has a libGDX version as part of it anyway.

I have no idea how I'd test the window-sizing issue on my laptop with one monitor available.

I find slashes to be easier to read because backslashes often have to be doubled when used in paths (in Java source code). I also don't know what a UNC path is or how it is relevant.

[Frosty-J]

UNC paths are for network drives and whatnot that aren't mounted under a drive letter. If you have WSL installed, you can go to \\wsl.localhost. Liftoff represents this as //wsl.localhost but if you paste that (or a mixture of slash directions à la \\wsl.localhost/Ubuntu-22.04) into Windows it won't work. This isn't hugely relevant but I do find it an interesting exception to forward-slash support.

[raeleus]

Some of the menus, in particular the templates one, cannot be exited using the mouse if the window size is small, as they lack a close button.

All the dialogs have OK buttons to close them and they are visible at the smallest supported resolution. I'm not going to allow the version to be visible at the smallest window sizes. It's only important to be visible for us maintainers when we are evaluating screenshots of the app. @Frosty-J, do you have a mac computer with a retina display? I could use your help debugging a certain feature. Otherwise, I believe I've addressed everything under my purview in my recent batch of PR's. Please let me know if I missed anything @tommyettinger. Thanks.

[Frosty-J]

Sadly, I don't have a Mac. I can set Windows or Linux to Retina density, but that's it. Not without investigating macOS VMs again, which didn't work very well before (might be a bit better now with gdx-angle).

That's a big batch size you've got there!

[JojoIce]

I have a Mac with retina display if you want me to check something out or take screenshots. On vacation so might be slow turnaround but I'll try to follow the tread. I haven't really followed the retina vs external display talk.

I have tested 1.12.1.12, and not found any bigger issues. Two very minor issues: Yes, the version and reset does not show up until the window is really tall if the window isn't very wide. That is even though there is plenty of space for it. The mouse over color (red) shows up when resizing the window if a button ends up where the mouse initially clicked down to resize. I assume that is the same for any platform and display.

[raeleus]

Thank you for offering your assistance, @JojoIce. Can you try the following versions of the app? hdpi-pixels.zip hdpi-logical.zip Please take screenshots of the app at its default window size and when the window is maximized. Which one do you think is better?

I've tried both on my 4K windows screen and it seemed to make no difference at all. I was hoping it would have an effect on Mac.

The mouse over color (red) shows up when resizing the window if a button ends up where the mouse initially clicked down to resize. I assume that is the same for any platform and display.

I have a solution for that, but it requires making changes to libGDX and I don't like doing that unless I feel really perturbed by the behavior.

Thanks!

[JojoIce]

Hi @raeleus

So just starting liftoff gives you this:

logical to the left and pixels to the right. I notice that in pixels the white has gone a bit more towards gray.

When minimizing the window you will get this:

On the external screen, they both look like the logical window.

Will send fullscreen images in a bit, but for me logical behaves like most other apps in that it does not change while dragging between external and laptop screen and does not have lots of empty space while having (for me) a bit too tiny font. Only thing is that pixels show the version in more window sizes, but I feel that is a minor thing and can possibly be solved in the same way as the reset button was in these builds.

[JojoIce]

Just to contradict myself right away, here is the 3rd party list in a minimal window:

Here I'd say the right pixels window is slightly more useful, but the best solution would probably just be to use a bit smaller font as was done for the paths input fields, and still go with logical setup. When maximizing the windows the pixels is a small list with tiny font inside of a very big and mostly very empty window.

[JojoIce]

The logical fullscreen is a bit of a mystery. If I just maximize the screen (dbl-click toolbar) on my 14-inch Mac book I still have to flip between the pages SOMETIMES! Have not yet figured out when I get the single screen and when I have to click Options and Next. If I instead enter fullscreen mode then I get the one page view:

In pixels mode I have so far gotten he one page setup even when I just maximize the window:

See the top area for the difference.

Again Logical is the winner for me. Easier to read and less "wasted space". Could possibly be different on a smaller screen.

So for me the overall winner is hdpi-logical. If you'd wanna go fancy, then maybe change some font-sizes depending on window size, and then it would be the winner on all accounts.

But then... The beauty is in the beer holder or whatever you say, but that is my take on it.

Lemmi now if you need any more tests.

Oh, and is it possible to add MrStahlfelge's gdx-gamesvcs and dkimitsa's altpods as 3rd-party plugins?

Great work all!

[tommyettinger]

RE: new libraries, sure, I'll definitely be able to add gdx-gamesvcs, but I don't know the first thing about altpods. If they're normal Gradle dependencies, they'll work fine.

EDIT: I didn't realize gamesvcs was actually quite a few different dependencies, all apparently not updating for 3 or 4 years. I hope the services haven't changed too much... It should still be possible but I don't know which services are still even online.

[JojoIce]

I started using gamesvcs about 5 years ago, and it still works for what I do (Google Play Games, Apple Game Center and GameJolt). I know of no other abstraction layer for these and as long as it still works I keep using it. It is mostly for submitting scores and achievements and requesting leaderboard and achievement list, so not much is changing there.

Not sure what other devs for mobile use to be honest.

So it is one "API" from the core code point of view and then it can be implemented in different ways in the back-end so to speak, which is the clever thing about it, but possibly a tiny bit more complex from the plugin perspective, but I imagine that it will be just a few different plugins and one would simply select the ones you want to use plus the "core".

Regarding the Altpods... They are Gradle plugins. If they are normal depends on the definition of normal. I think they are very valuable. I currently mostly use the Firebase: Analytics and Google mobile ads. If you are somewhat serious about making iOS games, then something like that is needed and the robopod firebase is the best I have found: https://github.com/dkimitsa/robovm-robopods/tree/alt/firebase . One will have to compile the iOS libs on your own, but that can mostly be copied from the alt-pod-tests: https://github.com/dkimitsa/alt-pods-tests/blob/master/libs/copy_firebase_libs.sh . Probably enough to link that that and have the firebase pod as a plugin.

Any plugins that do this would work, but these are the ones I have found that handle Game Services (cross-platform) and Ads (iOS) satisfactor.

All that in action in beta-test lib-gdx game here: https://trilligames.com/?page_id=164 It works well.

[raeleus]

Thanks for the followup on the retina stuff, JojoIce. You've given me a lot to think about and I'll have to make some decisions by next week.