MCL-41Windows launcher does not remember window position on close
Description:
The standalone Windows launcher does not remember its window position on close/reopen.
Recreate steps:
- Open Minecraft Windows Desktop app
- Resize window on desktop to something other than the default (but do not maximize it).
- Close Minecraft.
- Open Minecraft.
- Minecraft window does not open in the same position/size as was previously set.
Additional notes:
It's been this way since the beginning, it never remembered window position. 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.
Environment
Windows 8 Pro x64
Attachments1
Created Issue:
Minecraft Desktop Windows does not remember position on close
Description:
The standalone Windows launcher does not remember its window position on close/reopen.
Recreate steps:
- Open Minecraft Windows Desktop app
- Resize window on desktop to something other than the default (but do not maximize it).
- Close Minecraft.
- Open Minecraft.
- Minecraft window does not open in the same position/size as was previously set.
Additional notes:
It's been this way since the beginning, it never remembered window position. 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.
Environment
Windows 8 Pro x64
MC-5423
Changed Summary:
Minecraft Desktop Windowsdoes not remember position on closeWindows launcher does not remember window position on close
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
Added Assignee: ![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png)
[Mojang] Nathan Adams
[Mojang] Nathan Adams![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
Added Attachments:
7733.jpg
Removed Attachments:
Added Attachments:
Added Fixed Versions: 2.0.774 (Windows)
Added Linked Issues:
relates to
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
Removed Linked Issues:
relates to
Confirmed.
Edited title for clarity.
A bit of a feature request, but I agree. Also, it does not really relate to the game itself.
Updated affected versions.
@Jake: The Launcher is not updated with the snapshots, you'll have to download it by yourself (but I doubt that there is a newer version...)
@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.
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.
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.
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?
It's still open, so yes. It's just a matter of priorities. This isn't critical, and and development on the game itself tends to take priority over the launcher.
Confirmed for launcher v1.6.19
Confirmed for launcher v1.6.48.
Completely ignored arguments: [--nativeLauncherVersion, 301]
[20:03:20] [Client thread/INFO]: Setting user: Raynorx5
[20:03:23] [Client thread/INFO]: LWJGL Version: 2.9.4
[20:03:24] [Client thread/INFO]: Reloading ResourceManager: Default
[20:03:26] [Sound Library Loader/INFO]: Starting up SoundSystem...
[20:03:27] [Thread-5/INFO]: Initializing LWJGL OpenAL
[20:03:27] [Thread-5/INFO]: (The LWJGL binding of OpenAL. For more information, see http://www.lwjgl.org)
[20:03:30] [Client thread/INFO]: Created: 1024x512 textures-atlas
#
#
#
#
#
#
#
AL lib: (EE) alc_cleanup: 1 device not closed
Java HotSpot(TM) 64-Bit Server VM warning: Using incremental CMS is deprecated and will likely be removed in a future release
raynor: Your issue is completely unrelated to this ticket but a duplicate of
MC-32606