Windows launcher does not remember window position on close

@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... 🙂

Confirmed, and can also be duplicated by the following steps:

On Windows 7 (and probably 8) you can move your windows by holding the Windows key (also known as the Start key) and using the arrows to move windows. If you move the window to the far left or far right. And then Alt-Tab away from the launcher, and then Alt-Tab to get back - Window location and size is reset.

This does not happen when maximizing it as stated in Item 2 above.

It's really just a few simple lines of C++/Java (whatever the launcher's written in) so it's kind of puzzling why this was never implemented.

Because we never actually were able to update the darned thing until this version.

Also please give some links to documentation that describes how to handle this issues (in an ideally crossplatform way).

Affects the current launcher as well as the new, upcoming one.

Please do not mark unreleased versions as affected. You do not have access to this yet.

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.

The Launcher consists of two separate parts:
1) Bootstrap (the thing you run, packed natively for your OS, stays up < 3 seconds while it tries to find a new version of the launcher.
2) Launcher itself, the thing you see right after, this one we can easily change and should have access to profile data later.

and last the Launcher starts a new window for minecraft to run in, this is an os-native window controlled by lwjgl.

The bootstrap is supposed to be really small and have as little overhead as possible, we intend to never change it. The launcher is far more flexible, we can change it whenever we want. The bootstrap creates the initial window and then hands it fully to the downloaded launcher. Both the launcher and bootstrap are just Java AWT/Swing frames. (well they share 1 frame ;D)

Any of these changes should/could only apply from within the launcher (so we have the ability to change/fix/update/modify/whatever it)

This will however leave us in a 'strange state', where you see a window 'spawn' in the middle and after it loads the launcher-code pop to the 'proper location'.

I see only two ways of 'fixing this' but both are not really optimal.
1) Still put the code in the Bootstrap but this means we cannot finetune it, its annoying/painful for people to update it.
2) Changing the looks of the Bootstrap to more of a 'splash'-type, the real issue there is that when it fails, giving feedback is stupidly hard (and it fails a lot for people with broken java's etc).

We should have size/positional control over the spawned lwjgl window, but i'm not sure if it has any os-specific capabilities (like snapping to a side on windows orso).

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

We plan to give profile-based options so you can decide where to 'start the game' and 'which size'.

I think I might consider making the bootstrap window significantly smaller, it doesn't contain a lot of usable info and we could even grow it in size on error.

Whenever it loads the launcher it can just go to the 'last place remembered'.

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. 🙂

Was this still being looked into?