search

cryptomator / cryptomator-linux

Cryptomator .AppImage for Linux
GNU General Public License v3.0
14 stars 7 forks source link

StartupWMClass #10

Closed DougBeney closed 5 years ago

DougBeney commented 5 years ago

This prevents an additional icon to be opened in your Linux taskbar. Please note that this change should also be applied to the Ubuntu PPA and other Linux packages you maintain.

Before

before

After

after

Notice how in 'After' there is only one icon rather than two.

CLAassistant commented 5 years ago

CLA assistant check
All committers have signed the CLA.

overheadhunter commented 5 years ago

Thanks for the PR! Can you provide any documentation of the StartupWMClass? Is there anything we should know about this like potential side effects on different desktop environments?

DougBeney commented 5 years ago

How does Linux know what desktop applications are available on a user's computer? The answer is .desktop files placed in certain locations such as /usr/share/applications/. As you know, a .desktop file describes various meta information about an application as well as the command to launch it.

But what happens when you launch it and your application decides to create a window? How can Linux know whether that newly launched window actually belongs to that .desktop file? In the case of Java, it doesn't, so it just creates a new icon in your dock (or taskbar) for the window.

You can get the wm class (Window manager class) of Cryptomator by running xprop WM_CLASS and clicking on an open Cryptomator window.

Here is the returned data from that command:

WM_CLASS(STRING) = "org.cryptomator.launcher.MainApplication", "org.cryptomator.launcher.MainApplication"

You can see that there are two comma-separated values. They look like they are both the same. You can use any of the values that xprop WM_CLASS returns.

This answer does a pretty good job explaining it as well.

As far as side effects? I don't believe there are any. I also believe that all desktop environments and 'dock' replacements utilize WM_CLASS.

overheadhunter commented 5 years ago

During the JavaFX application launch the following invocations happen:

  1. Application.launch() triggers PlatformImpl.setApplicationName(appClass)
  2. This calls setName(appClass.getName()) on com.sun.glass.ui.Application
  3. Which is eventually used in glass_window.cpp to invoke gtk_window_set_wmclass

I.e. the vm_class property is always the java class of the application launcher and can not be changed using public API. Therefore the proposed fix will work unless we change the class or package name of the launcher.

This also explains why the class name instead of the application name is shown in Gnome menus btw.