@Kumasasa: Yeah, I know, but my hope is that if I keep tagging the bug with the latest snapshots maybe someone at Mojang will see this and actually fix it. The launcher hasn't been updated in forever...
Also please give some links to documentation that describes how to handle this issues (in an ideally crossplatform way).
I could if I knew more about the launcher. Do you use an abstraction layer like GTK+? You'll also need a way to store and persist five bits of data (Window Top/Left/Height/Width, and Window State [Restored/Minimized/Maximized], at least that's how MS Windows handles this information), and I don't know if you have a storage library you've written that can read/write this data within the context of the launcher or not. Ideally it would be stored with other configuration data in a file somewhere since this needs to be cross-platform (Linux doesn't have a "Registry" like Windows does, so that won't work, for example).
Basically what it boils down to, in a platform-agnostic functional way, is:
When application opens: Read data store and obtain saved window position, size, and state.
If saved state is null or malformed:
Use default position, size, and state
Else:
Set window's position, size, and state to the values obtained from the data store.
When application closes - or - when the window state changes: Save window position, size, and state to the data store.
Continue silently if this operation fails, we do not want the action of closing the program to be blocked. When the application starts next time, then, the defaults will be used.
Again, with more information I could be more specific.
First, I would think the launcher window and the lwjgl game window should "act" like they are the same window, even if they aren't, meaning they both share window positions and sizes. For example, if you open the launcher and resize the window to where you want it to be on your desktop, then you launch the game, the game window should open and be sized/positioned according to what the launcher just was a moment ago. Similarly, if the game window closes and the user has resized it or moved it, it should save that state to a data file so that when the launcher opens, it will be able to position/size itself accordingly.
So maybe this is a feature that needs to exist both in the launcher, and in the actual game instance, too.
I do agree with you that you probably shouldn't mess with the bootstrapper - the smaller and more lightweight a bootstrapper is, the better (generally speaking).
I'm not sure if you could somehow hook into the window after it's instantiated but before it's actually shown that way you'd be able to set its position/size without the user seeing the window snap/move around when it's first opened.
It's been awhile since I've worked with Java, but if what you said is true and these are just lwjgl Display windows, then I would think the methods contained here would be able to control the window's position and size:
Honestly, so long as you would be able to customize the start position of the game window itself, and have it do that consistently every time, I would be happy (and would consider this bug fixed, myself). So if you guys are indeed planning on doing that, that would be awesome.
Edited title for clarity.
Updated affected versions.
@Kumasasa: Yeah, I know, but my hope is that if I keep tagging the bug with the latest snapshots maybe someone at Mojang will see this and actually fix it. The launcher hasn't been updated in forever...
Affects the current launcher as well as the new, upcoming one.
I could if I knew more about the launcher. Do you use an abstraction layer like GTK+? You'll also need a way to store and persist five bits of data (Window Top/Left/Height/Width, and Window State [Restored/Minimized/Maximized], at least that's how MS Windows handles this information), and I don't know if you have a storage library you've written that can read/write this data within the context of the launcher or not. Ideally it would be stored with other configuration data in a file somewhere since this needs to be cross-platform (Linux doesn't have a "Registry" like Windows does, so that won't work, for example).
Basically what it boils down to, in a platform-agnostic functional way, is:
Again, with more information I could be more specific.
First, I would think the launcher window and the lwjgl game window should "act" like they are the same window, even if they aren't, meaning they both share window positions and sizes. For example, if you open the launcher and resize the window to where you want it to be on your desktop, then you launch the game, the game window should open and be sized/positioned according to what the launcher just was a moment ago. Similarly, if the game window closes and the user has resized it or moved it, it should save that state to a data file so that when the launcher opens, it will be able to position/size itself accordingly.
So maybe this is a feature that needs to exist both in the launcher, and in the actual game instance, too.
I do agree with you that you probably shouldn't mess with the bootstrapper - the smaller and more lightweight a bootstrapper is, the better (generally speaking).
I'm not sure if you could somehow hook into the window after it's instantiated but before it's actually shown that way you'd be able to set its position/size without the user seeing the window snap/move around when it's first opened.
It's been awhile since I've worked with Java, but if what you said is true and these are just lwjgl Display windows, then I would think the methods contained here would be able to control the window's position and size:
http://lwjgl.org/javadoc/org/lwjgl/opengl/Display.html
Specifically, setDisplayMode()/getDisplayMode() and setLocation()/getLocation().
Similarly, if they are JFrames from Swing, you would use getLocation()/setLocation() and getSize()/setSize().
http://docs.oracle.com/javase/6/docs/api/javax/swing/JFrame.html
Honestly, so long as you would be able to customize the start position of the game window itself, and have it do that consistently every time, I would be happy (and would consider this bug fixed, myself). So if you guys are indeed planning on doing that, that would be awesome.