[Request] Docky should support WM_CLASS for more accurate window detection.

Bug #518828 reported by Jason Stapels
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Docky
Fix Released
Wishlist
Robert Dyer

Bug Description

I have a few applications that I run that are all based on the eclipse framework (eg. Eclipse, Sametime, & Lotus Notes). No matter what I tried I was unable to get Docky to properly keep these windows separate from one another. After digging around in the source code I saw that Docky distinguishes unique application based on their executable name (w/ exception to a few hard coded workarounds, such as Open Office). In my case, I have three different applications that launch with an exec name of 'eclipse'.

I suggest that Docky add a new feature where it will distinguish applications based on the WM_CLASS property, and then fall back to the exec name in the event that it cannot find a match to StartupWMCLass in an existing .desktop file. I feel this would provide a better way to distinguish applications from one another and probably solve some of the hard-coded workarounds in the code today.

I would be willing to test or help develop a patch for this (although I've never programmed in C# before). Please let me know if there's any other information that I should provide.

Related branches

Revision history for this message
Robert Dyer (psybers) wrote :

Good thinking, but not the right solution.

The problem is that Docky needs to be able to automatically take a running application and figure out which .desktop file launched it. This is *hard* to do. Using WM_CLASS makes it almost impossible, as the class is usually not the same string as the launcher. Our current method works for most non-Java programs. Eclipse is a Java program and thus falls into this current deficiency.

Changed in docky:
importance: Undecided → Wishlist
assignee: nobody → Jason Smith (jassmith)
Revision history for this message
Chris S. (cszikszoy) wrote :

Patches are always welcome. Take a look at how we attempt to match windows in WidnowMatcher.cs. If you can come up with a better way let us know! If you need any help understanding how the window matcher works ask me (cszikszoy) on #docky irc.freenode.net

Revision history for this message
Jason Stapels (jstapels) wrote :

Actually, I think I will try to come up with a patch. I've dug through the code and have a basic understanding of how you are currently matching up processes to desktop files. The only thing holding me back is my lack of C# skills and installing the mono development libraries.

My approach would be to first attempt to match the applications current WM_CLASS property to an existing StartupWMClass property from .desktop. If that fails, then it would use the existing algorithm to match /proc/<pid>/cmd to the exec name.

Revision history for this message
Chris S. (cszikszoy) wrote :

That sounds reasonable to me. iirc, we do check WM_CLASS, but currently only do something special when the WM_CLASS matches open office.

Revision history for this message
Robert Dyer (psybers) wrote :

Here ya go, this does what you suggest.

FYI I tested it on a Java app (JabRef) by adding a StartupWMClass attribute to its .desktop file and it now suddenly matches! :-)

Everyone feel free to test this out, if we think it makes sense we can add it in.

The one downside I see is that it appears most launchers do not have this attribute (firefox and chrome are the only ones that do, for me). The upside is people can edit them and now effectively work around things that are failing to match. They can also request patches to launchers upstream.

Revision history for this message
Robert Dyer (psybers) wrote :

Linked a branch - lp:~psybers/docky/bug518828 with that patch applied

Robert Dyer (psybers)
tags: removed: docky feature
Revision history for this message
Adam Duracz (adam-duracz) wrote :

When will this be merged into the code that is available through http://ppa.launchpad.net/docky-core/ppa/ubuntu?

Revision history for this message
Jason Stapels (jstapels) wrote :

I tried to compile the private branch but it failed while running the autogen script. I thought it might suggest what deb I was missing, but unfortunately it didn't and I couldn't figure out what problem it was running into. Is there a document anywhere that might mention all the needed dev packages?

Revision history for this message
Robert Dyer (psybers) wrote :

This is the error that tells you what is missing:

configure.ac:56: warning: macro `AM_GCONF_SOURCE_2' not found in library

Compile instructions here:

http://wiki.go-docky.com/index.php?title=Install#Ubuntu.2C_Debian.2C_or_derived_system

Specifically you seem to be missing 'libgconf2-dev', I believe.

Revision history for this message
Jason Stapels (jstapels) wrote :

Thanks for the help. Following the wiki I was able to configure/compile/install it. Unfortunately I'm running into the following problem:

Exception in Gtk# callback delegate
  Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object
  at Docky.Windowing.WindowMatcher+<FindDesktopFileForWindowOrDefault>c__Iterator5.MoveNext () [0x00086] in /home/jstapels/tmp/bug518828/Docky.Windowing/Windowing/WindowMatcher.cs:330
  at System.Collections.Generic.List`1[System.String].AddEnumerable (IEnumerable`1 enumerable) [0x00000]
  at System.Collections.Generic.List`1[System.String]..ctor (IEnumerable`1 collection) [0x00000]
  at System.Linq.Enumerable.ToList[String] (IEnumerable`1 source) [0x00000]
...
(Attached the full trace)

I tried to debug it, but didn't see anything obvious.

Revision history for this message
Robert Dyer (psybers) wrote :

Ya that was poorly coded. Basically delete this file: ~/.local/share/docky/ExecStrings

Then it shouldnt crash (I think).

Revision history for this message
Robert Dyer (psybers) wrote :

Also update that branch, I pushed a couple changes that would also hopefully avoid that crash.

Revision history for this message
Jason Stapels (jstapels) wrote :

After pulling down the latest and reinstalling, everything works great! All my various eclipse (java) based apps are being detected properly :). Thanks a ton!

So what's the process to get this merged back into trunk?

Revision history for this message
Robert Dyer (psybers) wrote :

I'll be merging it in at some point. I just want more people to use it to make sure it doesnt break anything. :-)

I think this is the best we can do for Java apps. So whenever I push this I'll also mark that Java not matching bug as fixed.

The only problem is most people wont know they need to edit their .desktop files! We need to get several (major) upstream applications to add that StartupWMClass line to their launchers, so people dont need to edit them.

Revision history for this message
idokibovito (idokibovito) wrote :

Nice! Works for me too with TVbrowser (java) and xbmc (python). No regressions so far. Merge to trunk please :)

Revision history for this message
idokibovito (idokibovito) wrote :

Fixes all my window matching problems.

Revision history for this message
Robert Dyer (psybers) wrote :

Pushed in rev 1217.

Changed in docky:
status: New → Fix Committed
assignee: Jason Smith (jassmith) → Robert Dyer (psybers)
Revision history for this message
Lionel Dricot (ploum-deactivatedaccount) wrote :

Just tried the rev 1220 (Lucid PPA) today. Unfortunatly, this bug is not fixed for Lotus Notes 8.5.

Revision history for this message
Jason Stapels (jstapels) wrote :

Not sure if this helps or not, but I did verify Notes worked for me on the private branch for this bug. Below is my desktop entry:

[Desktop Entry]
Encoding=UTF-8
Name=Lotus Notes 8.5
Type=Application
Exec=/usr/bin/ibm-notes85
Icon=/opt/ibm/ibm-lotus-notes-compat/notes.ico
Terminal=false
Categories=Application;Office;
StartupWMClass=Lotus Notes

Changed in docky:
status: Fix Committed → Fix Released
Changed in docky:
milestone: none → 2.0.2
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.