dual-icon when run java-based app

[Garbin Huang]

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.

[Robert Dyer (psybers)]

Docky does not currently match (most) Java apps, because Java apps dont set the Pid on the windows they create.

[Chris S. (cszikszoy)]

This is actually a dupe of https://bugs.edge.launchpad.net/docky/+bug/480867

[Robert Dyer (psybers)]

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!).

[Chris S. (cszikszoy)]

bug 480867 is not about wine apps, it's about tucan. Makes no difference to me if they're separate bugs, the problem is the same and the solution is the same so I'll just close both when I fix it.

[idokibovito (idokibovito)]

I see the same problem with tvbrowser which is java too.
Strangely, XBMC shows the same symptoms with it's newest version. I wouldn't know it being java based though.

[Chris S. (cszikszoy)]

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.

[Robert Dyer (psybers)]

Just to comment on why we cant match Java apps, take a look at this one (JabRef):

rdyer 31165 1 23 23:33 pts/0 00:00:04 /usr/lib/jvm/java-6-openjdk/bin/java -classpath :/usr/share/java/jabref.jar:/usr/share/java/antlr.jar:/usr/share/java/antlr3.jar:/usr/share/java/looks.jar:/usr/share/java/forms.jar:/usr/share/java/spin.jar:/usr/share/java/glazedlists.jar:/usr/share/java/microba.jar:/usr/share/java/pdfbox.jar:/usr/share/java/jempbox.jar net.sf.jabref.JabRefMain

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).

[idokibovito (idokibovito)]

xbmc: /usr/share/xbmc/xbmc.bin

tvbrowser (full stack because it is so ugly it might even help):
4888 1 0 09:04 ? 00:00:00 /bin/sh /usr/sbin/tvbrowser
4889 4888 0 09:04 ? 00:00:00 /bin/bash ./tvbrowser.sh
4914 4889 34 09:04 ? 00:00:08 java -Xms16m -Xmx128m -Djava.library.path=/usr/share/tvbrowser -Dpropertiesfile=linux.properties -jar tvbrowser.jar

[Chris S. (cszikszoy)]

I forgot to mention, can you also look at the .desktop file for the respective apps that are failing and paste the "exec=....." line?

[Garbin Huang (garbinhuang)]

This is my "ps -ef" result.

garbin 10917 1 0 22:44 ? 00:00:00 /bin/bash
> /home/garbin/.mysoft/smartsvn/bin/smartsvn.sh
> garbin 10923 10917 53 22:44 ? 00:00:13 java
> -Dsun.io.useCanonCaches=false -Dsmartsvn.uifont=Sans -Xmx256m
> -Dsmartsvn.vm-xmx=256m -jar /home/garbin/.mysoft/smartsvn/lib/smartsvn.jar
> garbin 10986 10937 0 22:45 pts/2 00:00:00 grep --color=auto smartsvn
>

This is the exec line in my .desktop file of my SmartSVN.

Exec=/home/garbin/.mysoft/smartsvn/bin/smartsvn.sh
>

Hope they will be helpful.

On Thu, Dec 10, 2009 at 6:31 PM, Chris S. <email address hidden> wrote:

> 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
>

[idokibovito (idokibovito)]

Exec=tvbrowser
Exec=xbmc

[Marcus Carlson (0-launchpad-mejlamej-nu)]

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.

[Chris S. (cszikszoy)]

@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.

[Marcus Carlson (0-launchpad-mejlamej-nu)]

@Chris S, ah, thanks for clearing things out.

Is there a plan for getting the java apps working or will we have to patch the individual applications to provide "better ps output"?

For example I got my custom made application that creates the following "ps au"
marcus 13190 0.0 0.0 10948 1656 pts/0 S+ 07:43 0:00 /bin/bash /usr/bin/send-sms
marcus 13191 1.2 1.1 2648668 94052 pts/0 Sl+ 07:43 0:02 java -Dsettingpath=/home/marcus/.send-sms/ -jar /usr/lib/send-sms/SMS.jar

and the .desktop file; (removed some info)
[Desktop Entry]
Name=Send SMS
Exec=send-sms
Terminal=false
Type=Application
StartupNotify=false
Icon=send-sms
Categories=GNOME;GTK;Utility

But the icon is still missing. Any tip of getting it to work?

[Ikus-Soft (ikus-soft)]

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 ...

[Tony T (tonytovar)]

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.

[idokibovito (idokibovito)]

That might cause the problem for my apps too.

Ttitle of
* running XBMC is "Untitled window"
* running tvbrowser is: <app name> + version + current date and time

[idokibovito (idokibovito)]

Is there a workaround for this? It would be great, I never find my apps...
Thanks in advance!

[Fran Diéguez (frandieguez)]

This bug is happening indeed with Shreder (Thunderbird 3) with Ubuntu Karmic too.

Please solve this...

[chars (chars-develop)]

This bug affects almost all java based apps. Some important tools like Eclipse are quite popular. So I think the importance should be higher than "Low".

[Robert Dyer (psybers)]

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.

[chars (chars-develop)]

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.

[chars (chars-develop)]

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?

[Robert Dyer (psybers)]

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).

[Ryan J (ryan+launchpad)]

Is there anything I can add to wrapper scripts or .desktop files that would help Docky get the mapping right?

For any bash wrapper scripts, would it be possible to launch the script in debug mode (bash -x) and parse out the the real java command so you can match it later?

[Marcos Roriz (marcosrorizinf)]

Until this bug is corrected I'll be using gnome-do docky only because it works there :]

Bye bye docky until this is corrected.

[corristo (corrmage)]

Hmm updated to Lucid, now when I launch Eclipse lights fires under it's launcher on dock and no dual-icons.

[Robert Dyer (psybers)]

@marcosroriz: whatever, enjoy it while you can. The next release of Do removes Docky.

[Marcos Roriz (marcosrorizinf)]

@Robert Dyer: thats why I liked docky more before it was on gnome-do. It's was better. Now I need two programs, with one that doesnt do things correctly :/.

I think the integration was the keypoint to docky and gnome-do.

[adamgmetzler (adamgmetzler)]

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.

[sergioadh (sergio-adh)]

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.

[Robert Dyer (psybers)]

@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!

[idokibovito (idokibovito)]

Can we vote for features/fixes? :)

[Robert Dyer (psybers)]

Sure. As long as dev votes count as 500 each. :-)

[Egon Geerardyn (egon-geerardyn-gmail)]

@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.

[Robert Dyer (psybers)]

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.

[Ikus-Soft (ikus-soft)]

@Robert

Whats is the current way to match windows with .desktop file in Docky ?

In my oppinion, using pid and command line should work.

With the windows you retrieve PID
with PID you find the command line
the command line match the .desktop

I guess there is something I miss, because for me it's seams simple to solved.

[Robert Dyer (psybers)]

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.

[Ikus-Soft (ikus-soft)]

@Robert

Correct me if I'm wrong. looking at eclise, LotusNotes, SmarrSVN it's all the same thing.

As an example, I have eclipse.
I run xprop -frame to get it's pid
> _NET_WM_PID(CARDINAL) = 11074

ps -ef | grep 11074 to find the command line
> dufresne 11074 11073 2 14:23 ? 00:00:02 /home/dufresne/.eclipse/eclipse-modeling/eclipse.orig

It doesn't match so I check it's parent with pid 11073
> dufresne 11073 1 0 14:23 ? 00:00:00 /bin/sh /home/dufresne/.eclipse/eclipse-modeling/eclipse

So the command line here matches my .desktop.
So the only thing to implement to get java application match the .desktop file is to actually run the matching recursively on parent process.

[Robert Dyer (psybers)]

No. This only works on Eclipse (and perhaps a handful of other Java apps). FYI, Eclipse matches just fine.

Eclipse is a special case because they dont just run 'java eclipse', instead they have a native executable that launches it.

[Ikus-Soft (ikus-soft)]

Well, eclipse, Notes, and SmartSVN doesn't match properly. Eclipse windows doesn't matches with the launcher. Worst, most java app goes under the same icon.

[Robert Dyer (psybers)]

Eclipse works fine. Your eclipse install is broken.

[Tony T (tonytovar)]

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"

[Robert Dyer (psybers)]

No do not edit the title. This bug is about Java based apps only. Problems with other apps get their own bug.

[idokibovito (idokibovito)]

Oh? Hmm should I report the thing with XBMC which is Python IIRC somewhere else?

[Robert Dyer (psybers)]

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).

[patspam (pat-patspam)]

Nice one Robert - can't wait till this gets merged in.

[Robert Dyer (psybers)]

Rev 1217 pushed that proposed branch. I consider this a solution to this bug. Users of Java apps will have to modify (or get those apps to modify upstream) the launchers as described my last comment.

[Kurtins (kurtins)]

Awesome, can't wait to see it in docky's ppa :P

[Robert Dyer (psybers)]

There is information on the wiki regarding how to edit your launchers so they will work with this new code.

http://wiki.go-docky.com/index.php?title=How_to_Customize_Window_Matching

[idokibovito (idokibovito)]

Thanks for the fix!

[Ryan J (ryan+launchpad)]

I still have trouble with IntelliJ IDEA. I get the following from xprop:

ryan@ryan-laptop:~$ xprop | grep WM_CLASS
WM_CLASS(STRING) = "sun-awt-X11-XFramePeer", "java-lang-Thread"

The only consistent info I can see from xprop is a WM_NAME that includes IntelliJ IDEA somewhere:

WM_NAME(STRING) = "IntelliJ IDEA (Maia) IU-94.539"
or
WM_NAME(STRING) = "[verbose project description here] - IntelliJ IDEA (Maia) IU-94.539"

I don't think that helps anything though, since it wouldn't be distinguishable enough. For example, if I visit the download page for IDEA (http://www.jetbrains.com/idea/download/index.html) I get:

WM_NAME(STRING) = "IntelliJ IDEA :: Download Latest Version of IntelliJ IDEA - Mozilla Firefox"

Any suggestions?

[Robert Dyer (psybers)]

No, you are out of luck.

[luizfar (luizfar-gmail)]

Can somebody confirm if this fix is already in the ppa?
Thanks!

[idokibovito (idokibovito)]

luzifar: yes it is, works for me via PPA.
Use the description above, that works well.
Cheers

[luizfar (luizfar-gmail)]

Thank you, idokibovito.
It doesn't work for me though.. :(
I have a launcher on my gnome-panel for the executable /opt/eclipse/eclipse
I added to the launcher the line:

StartupWMClass=Eclipse

"Eclipse" is the String returned by xprop when I click on the window.
Docky still doesn't match the application..

Does anybody have any idea what I am doing wrong?
Thanks :)

[luizfar (luizfar-gmail)]

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).

It seems to work now :)
Thank you!

[idokibovito (idokibovito)]

Yeah I had problems with the launcher too. Pin to dock would probably not work aswell. However with a little luck and a bit of effort now it is possible to get it right. Thanks to Robert :) Thanks!

[helder.silva (skandals)]

It's happening again in Ubuntu 10.10 and netbeans 6.9 (aptitude installed)

Do you need a log file?

[Robert Dyer (psybers)]

This bug is fixed. netbeans just doesn't work because they don't set anything we can match against. There is another bug for netbeans somewhere, but it is probably marked Invalid in Docky.

[Jelmer Kuperus (jelmer-jteam)]

I created a java agent that changes the default string that the jdk assigns to WM_CLASS

Just download this jar http://jelmer.s3.amazonaws.com/agent.jar (source included in the jar)

And start your java program with the argument

-javaagent:agent.jar=WHATEVER_YOUR_WM_CLASS_SHOULD_BE

Then add StartupWMClass=WHATEVER_YOUR_WM_CLASS_SHOULD_BE

To your .desktop file

I blogged about this here : http://blog.jteam.nl/2011/01/09/make-intellij-idea-behave-properly-in-linux-docks/

[Robert Dyer (psybers)]

That is ABSOLUTELY AWESOME! Why didn't I think of that?! With all the JVM work I've done that should have popped into my head.

One question: Since this is provided in binary jar form, what is the license on it? Can I include it in Docky's distribution?

[Jelmer Kuperus (jelmer-jteam)]

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 Kuperus (jelmer-jteam)]

FYI I added the license and moved the code over to github

https://github.com/jelmerk/window-matching-agent

[Robert Dyer (psybers)]

@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!