micheleg / dash-to-dock

A dock for the Gnome Shell. This extension moves the dash out of the overview transforming it in a dock for an easier launching of applications and a faster switching between windows and desktops.
https://micheleg.github.io/dash-to-dock/
GNU General Public License v2.0
3.88k stars 460 forks source link

Local .desktop files aren't honored #416

Closed rastersoft closed 7 years ago

rastersoft commented 7 years ago

I have two local .desktop files (at ~/.local/share/applications): MPLab, and Android Studio. They are shown in the dock, and I can switch to them, but I can't add them to the dock in order to be able to launch them from it.

franglais125 commented 7 years ago

@rastersoft Does the same thing happen without the extension? i.e. can you make a "local" application favourite on the default gnome-shell dock?

rastersoft commented 7 years ago

Yes, it also happens on the default dock, so it is probably a bug in gnome shell itself... Filling a bug report in 5, 4, 3...

zapashcanon commented 7 years ago

@rastersoft, could you show your .desktop ?

A few weeks ago I managed to add a "local application" (atom) as a favourite at my university with this atom.desktop file - located in /home/tp-home008/landres/.local/share/applications:

[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=Atom
Comment=Atom
Icon=/usr/share/picmi/levels/default/baby_panda.xpm
Exec=/home/tp-home008/landres/.local/usr/bin/atom
Terminal=false
Categories=Editor;Atom
rastersoft commented 7 years ago

I've been doing some extra ttests, and it seems that the problem is more binary-related. If I try to use this .desktop file:

[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Categories=Development;
Name=xclock
Exec=xclock
Icon=fbzx

It can't be added as a favorite. But changing the Exec to fbzx (and nothing else) allows it to work. So I suspect the problem could be in some XDG attributes that some apps set in the main window, but others do not.

franglais125 commented 7 years ago

Interesting... Do you have a link to the bug report for GNOME? (If you did file it :) )

rastersoft commented 7 years ago

I still didn't fill it. I'm doing more tests. The other apps that fail are java-based, and I'm using the oracle JVM. I'll change to OpenJDK and test again, and with all that info I'll fill it.

rastersoft commented 7 years ago

Ok, it fails with both OpenJDK:

raster@rasterhost:/opt/google/android-studio/jre/bin$ ./java -version
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
openjdk version "1.8.0_76-release"
OpenJDK Runtime Environment (build 1.8.0_76-release-b03)
OpenJDK 64-Bit Server VM (build 25.76-b03, mixed mode)

and what I think is Oracle Java:

raster@rasterhost:/opt/microchip/mplabx/v3.40/sys/java/jre1.8.0_91/bin$ ./java -version
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)

I'll fill the bug report now.

rastersoft commented 7 years ago

It seems is something already reported. This is the original bug report:

https://bugzilla.gnome.org/show_bug.cgi?id=774353

I added a comment at the end with the solution for my specific case, which is to use "xprop" to read the X properties in the program's window, and add a "StartupWMClass" line to the .desktop file. For Android Studio, it is:

StartupWMClass=jetbrains-studio

and for MPLabX it is:

StartupWMClass=MPLAB X IDE v3.40

franglais125 commented 7 years ago

@rastersoft I'm not 100% sure, but I think using xprop would mean that this fails in a Wayland session (unless the window is under xwayland).

rastersoft commented 7 years ago

Unless the java swing library has a backend for wayland, it will use xwayland for sure.