Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[whatdoesthisbuttondo]

The mod selector dialog in the launcher does not draw properly.

When first opened, it appears all white and cannot be interacted with.

After switching to another window and back (e.g. the terminal I started Starsector in), it is still all white, but randomly clicking inside will reveal controls by forcing a repaint as you hit them. With the bottom buttons, just hovering over where they're supposed to be works as well, as the hoverstate does force a repaint as well.

Not a show-stopper and possible to work around. No stacktraces on my terminal window, let me know if I can do anything to provide more useful debug info.

[Alex]

Hi - what operating system are you using?

[whatdoesthisbuttondo]

Linux, more specifically Fedora 21. Had to install a few libs to make the game work, but all came from default repos.

I'm using the jre the game is shipping with to run it, but just for reference, Fedora uses OpenJDK:

$ java -version
openjdk version "1.8.0_31"
OpenJDK Runtime Environment (build 1.8.0_31-b13)
OpenJDK 64-Bit Server VM (build 25.31-b07, mixed mode)

[Alex]

Thanks for the info.

I think this might be an issue with either OpenJDK or the OS - the code to show the dialog is pretty straightforward and looks right. I did throw in an extra call to repaint the dialog after showing it just now - it shouldn't be necessary, but it also shouldn't hurt anything, and might fix this for you after the next release.

[whatdoesthisbuttondo]

Could you provide me with a basic code sample of the dialog if that isn't too much trouble?

I'm rather curious why this doesn't work properly and would like to investigate further, as ideally java shouldn't require any platform-specific workarounds.

[Alex]

It's:

Code: java

final ModDialog dialog = new ModDialog(frame);
dialog.show();
dialog.repaint();

With ModDialog extending JDialog (and adds a JList, a bunch of JPanels, etc to it), and the last line - the repaint() call - being something I just added.

[whatdoesthisbuttondo]

Hmm, that is pretty straightforward.

On a hunch, maybe there is something inside ModDialog clogging up the EDT specifically on Linux? I wouldn't rule out subtle threading differences between platforms there.

I'm assuming this since the workaround requires me to actually overlap the whole ModDialog with another window, and only after it is brought back in foreground forcing the repaint by clicking inside does work.

If this is the case, then attempting to fix with an extra repaint() after show() will likely not yield any positive result. Anyways, probably not worth wasting a lot of time hunting this down.


On a side note, I've tried to run the game with the OpenJDK that comes with my system and see if the issue is there as well, and it crashed and burned pretty bad

I'll try to see what the issue is there, but for now it appears that I'll have to use the JRE you supply wth the game.

[Alex]

Hmm, I really don't see what it could be. It's all very straightforward, and it's not doing anything heavy in mouse/action listeners and the like. I could very well be missing something, though, not exactly a Swing expert. (In fact, I'd love to eventually recode the launcher in OpenGL.)

[Dark.Revenant]

I can't help you because I think Swing and WPF are the things of the devil.

Most likely, Swing is broken for his operating system.  It can't be much else, at any rate.

[Alex]

I can't help you because I think Swing and WPF are the things of the devil.

(Hear hear. Or it just doesn't fit nicely into my brain - I've spent enough time with it where I feel like I should be pretty decent, but even things like "add a label specifically here" thwart me on a regular basis.)

[whatdoesthisbuttondo]

I can't help you because I think Swing and WPF are the things of the devil.

That quote should actually be at the beginning of every single book on Java UI programming handbook that has ever been written 

Most likely, Swing is broken for his operating system.  It can't be much else, at any rate.

Eh, don't underestimate Swing, it does provide a million ways to shoot oneself in the foot without even noticing until something inexplicably doesnt work at a random client machine...

I've run a minimalist test-case as well as a couple of applications that use Swing, and there are no issues there. Not OpenJDK and not the Oracle JRE, and the issue with Starsector is exactly the same on both (runs prefectly fine with OpenJDK btw, turned out I didnt fix library path before).

---
I don't have any real idea what could be the issue here, though it appears that my initial analysis has been wrong.

The dialog is in fact fully functional and can be dismissed by clicking where the buttons should be, so there is no application freeze, just it is not properly painted.

I've seen similar issues before in a project of ours, and iirc it was due to Swing methods being called randomly instead of from the EDT.


Anyway, probably not worth examining this in-depth if it isnt an issue on other platforms as the workaround is sufficient to select mods.

[Alex]

I've seen similar issues before in a project of ours, and iirc it was due to Swing methods being called randomly instead of from the EDT.

Yeah, I couldn't swear I'm not doing that somewhere. I mean, I'm technically aware of this, but could've well missed something.

Anyway, probably not worth examining this in-depth if it isnt an issue on other platforms as the workaround is sufficient to select mods.

Considering that I'd love to eventually replace this mess altogether, probably not, yeah. Thanks for your understanding