Open Frosty-J opened 1 month ago
Here are my thoughts on your thoughts on the new UI:
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.
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:\
.
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.
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.
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.
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.
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.
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!
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.
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!
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.
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.
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!
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.
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.
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.
Here are my thoughts on the new UI, and maybe the old UI as well since I don't remember what was carried over:
GDX Dialogs
is D in the ordering butGDX Basis Universal
is G.gdx-psx
is under G butgdx-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.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.