Because of my locked-resolution, multi-monitor desktop, the only way to get a proper fullscreen Minecraft on my system is to let the Window manager do the fullscreening. (Basically, it sets up a mixture of "maximize", "always on top", and "hide window borders")
For most applications, I can set the Window Manager to do that automatically but, for Minecraft, I have to manually fullscreen it every time I start the game because Minecraft doesn't set any of the identifying properties it should.
My Window manager (Openbox) provides some convenience properties showing the values it matches against, even if they're changed after it's done its check. Here's what the xprop command reports for the Minecraft game window:
_OB_APP_TYPE(UTF8_STRING) = "normal"
_OB_APP_TITLE(UTF8_STRING) = "Unnamed Window"
_OB_APP_CLASS(UTF8_STRING) =
_OB_APP_NAME(UTF8_STRING) =
_OB_APP_ROLE(UTF8_STRING) =
That _OB_APP_TITLE value is especially interesting because, as I understand it, it means that you create the window with the title "Unnamed Window" and then rename after Openbox checks but before I see it.
(Though they're all interesting because they imply that LWJGL has no concept of setting sane defaults for X11 window properties. All the PyGTK apps I've written just use the application's filename to fill those values if I don't set them myself.)
Here's how they're supposed to look in the only valid case for using the term unnamed/untitled:
_OB_APP_TYPE(UTF8_STRING) = "normal"
_OB_APP_TITLE(UTF8_STRING) = "(Untitled)"
_OB_APP_CLASS(UTF8_STRING) = "Leafpad"
_OB_APP_NAME(UTF8_STRING) = "leafpad"
_OB_APP_ROLE(UTF8_STRING) =
Could you please at least set ONE of the class, name, and title properties properly on window creation so I can have my window manager auto-fullscreen Minecraft on a single monitor without shutting off the other one?
As is, it's impossible to match only the game window and trying to force the launcher windows to start fullscreen'd causes things to break.
Comments 17
LWJGL has just added support for setting the WM_CLASS hint, and it will be available in LWJGL 2.9.1. In the meantime, I've made this to set up one of the LWJGL nightlies in the launcher.
Is this still a concern in the current Minecraft version 1.7.2 / Launcher version 1.3.4 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
LWJGL 2.9.1, which supports setting the WM_CLASS hint as I mentioned above, was released on Monday. LWJGL now sets the WM_CLASS hint to the window's title automatically, but it does allow WM_CLASS to be set to something else via the LWJGL_WM_CLASS System property. Since Minecraft now sets the window title to "Minecraft <version>" (which is useful for users who use more than one game version), WM_CLASS should be set to just "Minecraft" so that people don't have to update their .desktop launchers or window manager settings with every release. This needs to be done before Display.create() is called:
System.setProperty(System.getProperty("LWJGL_WM_CLASS", "Minecraft"));This will use the existing value of LWJGL_WM_CLASS if there is one (e.g. if the user wants to use a different WM_CLASS; maybe they have different .desktop files that use different working directories or something).
Also, the launcher should use "Minecraft" as its WM_CLASS. Since the launcher is using AWT, the only way I know of to do this is this trick that uses reflection. For me, GNOME Shell recognizes the launcher because its process ID is the same as the process GNOME spawned when picking the launcher icon, but since the game runs in a separate process, it doesn't recognize it unless its WM_CLASS is set properly. Still, the launcher's WM_CLASS should be set properly because I imagine it could be a problem for users of other desktop environments. (I imagine that if the launcher is launched with -DLWJGL_WM_CLASS=..., then that should be used for the launcher and also passed to the game before the user flags (allowing it to be overridden just for the game).)
Is this still a concern in the latest Minecraft version 14w03b? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Ahh. I mistook your form letter for a bot message because, when [Mod] Synchunk sent it, I asked if he was a bot and never got a response.
As for fixing the problem, Scott Zeid went into quite a bit of detail on how simple it is.
I suspected as such, but I'll take any opportunity I can get to draw attention to how, were I a developer already versed in the project, Scott Zeid provided enough information that I could probably apply and test the fix in 5 minutes.
Maybe someday it'll actually trickle through to the devs.
Is this still an issue in the most recent versions (currently that is 1.10.2, or 16w42a) of Minecraft? If so, please update the affected versions and help us keeping this ticket updated from time to time.
I can confirm this on Linux with Minecraft 1.6.4. I need the window class for my application launcher. It basically monitors the window class to show in the icon whether the application is running or not, and also once I click the icon if it should bring it to the front or launch new instance. As it is when minecraft has no window class I can't set it to monitor anything at all.