Bug Description

I add a java-based app SmartSVN's icon onto docky, When I click the icon to open it, a nother icon appeared, I think it should turn the icon I added light and shouldn't create any icon? see screenshot below.

This is not a dupe. bug 480867 deals with wine applications and this bug deals with Java applications. Both bugs are a failure of the matcher, but with potentially different solutions (or potentially the same, but until we fix one we wont know!).

When this happens it's a failure of our window matcher. To fix this, we need to know the full command line of the program as shown from ps -ef (the last column shown is the command line). It's also helpful to know the command line for the parent processes as well.

For example, using ps -ef | grep docky gives a few entries, but the one that's important is this:
chris 5089 14092 0 14:52 pts/1 00:00:19 mono --debug /usr/local/lib/docky/Docky.exe -d

When looking at the ppid, I see this:
chris 14092 24103 0 Dec08 pts/1 00:00:00 bash

Which makes sense because the script that launches docky uses exec to launch the mono process.

Most other programs (particularly java programs) do not do this, so if you follow the PID -> PPID tree all the way up you can see the java program, then the script that launched that program etc etc.

Docky does something similar when trying to associate a window with a .desktop file.

The point is, some programs do things that we don't account for, and we need to know what the commandlines look like.

First, the ppid is 1 so we get nothing useful there. Second, the path is the java command-line (which makes sense) however the launcher for JabRef is 'wrapped' in a launcher script. So we cant easily figure out that that command-line matches that launcher! Thus there is no match and I get 2 icons (the launcher, and a 'default' window icon).

> I forgot to mention, can you also look at the .desktop file for the
> respective apps that are failing and paste the "exec=....." line?
>
> --
> dual-icon when run java-based app
> https://bugs.launchpad.net/bugs/484610
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Docky: Confirmed
>
> Bug description:
> I add a java-based app SmartSVN's icon onto docky, When I click the icon to
> open it, a nother icon appeared, I think it should turn the icon I added
> light and shouldn't create any icon? see screenshot below.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/docky/+bug/484610/+subscribe
>

Can't we at least fallback to get the icon from the window manager (as it used to be in gnome-do (?))? Also if started from docky it should be possible to keep a reference to the application started - not ideal but a workaround.

@Marcus, The code to use the low resolution icon provided by the window manager is already there. It's turned off right now because docky is _alpha_ software and disabling this highlights problems with our window matcher, thus encouraging people to file bug reports, which is why we're all here right now :)

As far as reference counting goes, that wouldn't work very well. It may work for apps launched through docky, but what about windows that created through no user input, or apps launched elsewhere that docky can't keep track of.

The dock bar in Mac OS X have also face a similar issue. Maybe we should look into how they solve the problem with Java based application. If I remember well they uses a generic icon (a cup of coffee) to represent most java applications, but it's been a while I used Mac OS X ...

VLC has this same problem. My guess is that Docky 'loses track' of it because VLC changes it's title bar to match whatever it's playing, e.g. I have a shortcut that directly loads my favorite Internet-radio station via an .M3U file and VLC immediately shows the current song name.

Eclipse works fine. Other than Eclipse and netbeans (which by the way, are only 'important' to Java developers which are a very small portion of the user base!), there are not many extremely popular Java apps and thus it is low.

Eclipse does not work fine at my desktop. Please see attached screenshot. I have tried Lotus Notes 8.5, Eclipse 3.5 and WebSphere Integration Developer 7 as launcher and none of them is correctly embedded to the launcher. I do not have any statistics about how popular is Eclipse, but I know it is not only for Java developers. As Lotus Notes is often used enterprise mail client, it is a very important app as well. If those users did not use docky just because of this issue, then it would be certainly a small portion of the user base.

In Cairo-Dock's docs, they use app class to solve the java apps problem:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
To find the class for an application, make sure it's open, and then go to a terminal and type
xprop | grep WM_CLASS

This will bring up a little pointer, which you use to click on the relevant window. You'll get something like this in the terminal :
WM_CLASS(STRING) = "nautilus", "Nautilus"
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Could this be a solution for Docky as well?

We already match on class, and Java does not set the class for a lot of apps anyway.

Even for the ones it does set it, it is often useless because it will be something like 'net-sf-jabref-JabRefMain' which we have no way to match against any of the .desktop files, without manually maintaining some sort of mapping (which we may do in the future but only as a last resort).

Have you tried to match the WM_CLASS and WM_NAME xprops for java apps? For, example, 'xprop -frame | grep WM_CLASS' on a java app will always be 'WM_CLASS(STRING) = "sun-awt-X11-XFramePeer", "java-lang-Thread"' The first prop being the native window class and the second (different for each java app i.e. unreliable) being the name of the main java thread given during the application's development. The out put for 'xprop -frame | grep WM_NAME' will have the frame title like 'WM_NAME(STRING) = "NetBeans IDE 6.8"' This could be a fix if you combine the two properties together, the first property from WM_CLASS to know it is a java app and the second WM_NAME being the window title. While this is a fix for java apps that do not change the title or apps that append information to the application name in the title, it will not solve the situation if the application name is not in the title.

Can't there be made something like in AWN where you can right click the app and select an icon and it will always remember it? They both pull up the default window icon which is pixelated, but AWN can use a custom icon for that application.

@adamgmetzler: no, that will not help us match against a .desktop file. We already know they are Java apps. The string such as 'netbeans ide 6.8' is nice and all but cant be automatically matched against a .desktop file so it is useless.

@sergioadh: no, I do not like that solution. We will figure out a way to do a proper match!

@Robert Dyer:
surely a dev isn't worth 500 votes. While I agree you guys do great work, I suggest the following voting system: each working implementation is worth a vote. That might get this bug solved.

The reason I say our votes count as 500 is that we must be motivated to fix the bug. There are generally 3 ways that happens:

1) the bug is a crasher that affects the majority of users
2) the bug affects us devs and annoys us until we fix it (which isnt happening with this bug)
3) the bug affects a large portion of the userbase (I dont see that as the case here)

If it isnt in any of those categories, then we generally fix bugs that we find the most interesting. This might seem odd to a normal user, but it is just how things work. As long as the program is 'working' for the majority of users, we will pick and choose bugs first based on input from the community and then second our own preferences. This is, after all, a hobby project for us devs. :-)

Also while I agree that Docky failing to match (any program) is annoying, it generally does not limit the functionality of the program. You are still able to launch and manage the program -- so it is very low priority.

That is the general approach. However in cases such as Java that usually fails. Most Java apps have a frontend script that calls 'java MainClass' and sets up classpath etc. So the .desktop file contains exec=somescript while when you lookup the cmdline you see 'java MainClass'. There is no way to match that directly.

This problem exists for most 'scripting' or 'managed' languages (python, perl, etc). The slight difference here is that often times with python/perl/etc the script name and the frontend launcher are named consistently enough that we get a direct match by simply ignoring the 'perl ' in front of 'perl foo.pl' and can strip off the file extension. With Java this almost never works (most Java main classes are like 'org.blah.foo.MainBar' for an app with a launcher named 'bar'. This is inconsistent enough that we cant really do simple hacks and get most of them.

Can the title be updated to indicate that it affects more than just Java-based applications? For instance, for my situation with VLC, it appears that Docky incorrectly displays duplicate icons anytime the app has a different window-title?

I originally thought the problem was because my link was to a document (with associated app) rather than to the app itself. But that's not the case here, I'm linking to the app but with an extra command-line option -- here's my VLC-Radio shortcut,
> vlc "/home/tony/Desktop/Radio Paradise MP3.m3u"

The branch at lp:~psybers/docky/bug518828 has the ability to fix this bug as well. You have to manually add a StartupWMClass=<foo> attribute to your launchers, but once you do it should match. The value of that attribute should be the WM_CLASS of the window.

To get the value, run "xprop | grep WM_CLASS" and click on the window. It should dump something like this:

WM_CLASS(STRING) = "Navigator", "Firefox"

You then copy/paste the 2nd quoted string. So for this example I would add:

StartupWMClass=Firefox

to the launcher firefox.desktop and it should match based on the class (note that firefox actually already has this attribute in their launcher).

Ok.. I dragged the launcher to docky and now it works correctly.
Before I was just starting Eclipse from gnome panel's launcher but Docky didn't recognize I was running Eclipse for some reason (not showing the correct icon).

Hey Robert, It's a binary jar but the sources are included inside (just unzip the jar) it's basically a single file. The other files in there are a repackaged asm library (to avoid classloading conflicts) I used jarjar to repackage the core asm library

I don't think i included a license in the header but you can consider it apache v2 licensed and if you want to include it in docky's distribution. by all means! that would be awesome

@Jelmer: awesome. I won't distribute it with Docky (as using it requires modifying every shell script that starts a Java app) but I will put a link to it onto our wiki with instructions on how to use it!