search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
91.46k stars 21.27k forks source link

Option to set Linux WM Class on export #18510

Closed Nolkaloid closed 5 years ago

Nolkaloid commented 6 years ago

Godot version: All versions

OS/device including version: Ubuntu etc...

On Linux based systems the application indicator is identified by something called a WM Class, it's used to group linked windows to the same launcher icon. When exporting a project to Linux the exported projects keeps the same WM classes : WM_CLASS(STRING) = "Godot_Engine", "Godot"

What would be great is the possibility to set a custom WM_CLASS on export, this would make it easier to create .desktop files for the exported projects and would prevent the exported project to be grouped with the actual engine editor.

How it is now: image

Proposition: image image

LikeLakers2 commented 6 years ago

Just throwing my two cents here, perhaps we should have a more friendly name than WM_CLASS for this. Perhaps "Window Manager Identifier"? Combine that with a good hover-over note and it won't seem so advanced to newbies.

Two-Tone commented 6 years ago

Why not just "Window Class" or "Window Group"? It'll make the purpose of the variable more obvious to developers who are not use to Linux, which is very important in my opinion as that is likely most game developers.

On Sat, May 5, 2018, 8:35 AM LikeLakers2 notifications@github.com wrote:

Just throwing my two cents here, perhaps we should have a more friendly name than WM_CLASS for this. Perhaps "Window Manager Identifier"? Combine that with a good hover-over note and it won't seem so advanced to newbies.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/18510#issuecomment-386806156, or mute the thread https://github.com/notifications/unsubscribe-auth/AEJES21xBsCJQc5qKrqqtkmkkrYh5EtGks5tvaq5gaJpZM4TrzeG .

LikeLakers2 commented 6 years ago

I'm cool with "Window Group". I'm just concerned using the "Class" terminology might be confusing, potentially making some developers (especially new people or those coming from GMS) think it has to do with how the engine itself works, when it very clearly doesn't affect the engine besides making it separate on the taskbar.

guilhermefelipecgs commented 6 years ago

How about use application/config/name for the WM_CLASS automatically, just replacing spaces with underscore (because I don't know if WM_CLASS allow spaces)?

ninao-xyz commented 6 years ago

@LikeLakers2 @Two-Tone , Using other name than "WM_CLASS", would be confusing for me. I think stuff like this should be named with their real names instead of something else.

LikeLakers2 commented 6 years ago

@ni-code I mean, sure, but I personally don't think "WM_CLASS" is really a friendly name to people new at developing for Linux/X11. I'm not saying we can't refer to it as "WM_CLASS" in something like the hover-over tooltip, just that we should consider that new developers (especially those who know next to nothing about Linux development) might misinterpret what "CLASS" means in this context.

bojidar-bg commented 6 years ago

What about just writing "Window Manager Class"?

neikeq commented 6 years ago

I agree with @ni-code. I can't think of any name that would be detailed enough to remove the need for user to do a search in order to understand the concept. When it comes to searching, a different name like (for example) "Window Managet Class" will add a lot of undesired search results, while "_WMCLASS" will give you just what you are looking for.

I'm not against "Window Managet Class", but include "_WMCLASS" in the name, e.g.: "_Window Managet Class (WMCLASS)".

akien-mga commented 6 years ago

How about use application/config/name for the WM_CLASS automatically, just replacing spaces with underscore (because I don't know if WM_CLASS allow spaces)?

Definitely, this should be the default setting if empty, as we can assume 98% of devs will miss this setting and would otherwise have all games grouped together if the default was e.g. "GodotGame".

This would need to be double checked against the X11 spec, but something similar to the way we generate the user:// path when no custom one is given could do the trick: https://github.com/godotengine/godot/blob/c45f44d85635a1d16a93c00cd8cb17f60dfa6336/drivers/unix/os_unix.cpp#L440

cassidyjames commented 6 years ago

I just ran into this when packaging a game up for the @elementary AppCenter. It would be great to be able to associate the game with its own icon instead of the Godot icon!

sturnclaw commented 6 years ago

For information, the WM_CLASS is set here: https://github.com/godotengine/godot/blob/23b4b7d53a8dabf822cf07074c3b72de43cf649c/platform/x11/context_gl_x11.cpp#L87-L98

Which is called here: https://github.com/godotengine/godot/blob/23b4b7d53a8dabf822cf07074c3b72de43cf649c/platform/x11/context_gl_x11.cpp#L186-L188

The issue is two-part; first, OS_X11::set_context needs to be updated to unmap the window before setting the class (and remap it after), ContextGL_X11::initialize needs to call that function instead, and then a project setting can be added to set the class hint.