When running Wolfram Mathematica, I found newly opened windows would never be matched to their launcher on the icon-only task manager widget. By debugging a bit, I found out that X11 always reports NULL on the field res_class for Mathematica windows. I don't know how anomalous is this, but the very first check libtaskmanager does when attempting to find a matching launcher url is to check if classclass isn't null (line 543 of taskitem.cpp). By looking at the code, little can be done to find a suitable launcher if this test fails. I suppose this test could be changed to check if *both* classClass and className are NULL. I haven't found any FOSS that creates windows with NULL res_class, so it may very well be Mathematica's fault. Reproducible: Always Steps to Reproduce: 1. Open Wolfram Mathematica (or any program that creates windows with NULL X11 res_class) 2. Right-click on the window's icon on icon-only task manager plasmoid and select "Show A launcher when not running" 3. Close the window 4. Reopen the program Actual Results: Newly opened window icon is placed on the "unknown launcher" place on icon-only task manager, after the known launchers. Expected Results: Newly opened window icon should be placed over the previously created launcher. Well, I have taken the liberty to create a tiny patch that attempts to solve the problem by relaxing the non-empty classClass condition on line 543 of taskitem.cpp. So far this seems to work just fine, and Mathematica windows are correctly matched to its launcher without any vissible side effects. I admit though, I have next-to-zero knowledge on the inner workings of libtaskmanager, so I suggest some care with this patch. --- From 364403a0b0032046da80e2aafb57e2cb8625de21 Mon Sep 17 00:00:00 2001 From: Thiago Martins <tcmartins@gmail.com> Date: Wed, 21 Nov 2012 20:47:41 -0200 Subject: [PATCH] Try to use className for a window with null classClass --- libs/taskmanager/taskitem.cpp | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/libs/taskmanager/taskitem.cpp b/libs/taskmanager/taskitem.cpp index e9933c8..5a7a79c 100644 --- a/libs/taskmanager/taskitem.cpp +++ b/libs/taskmanager/taskitem.cpp @@ -540,7 +540,7 @@ KUrl TaskItem::launcherUrl() const // we will keep on failing so the isEmpty() check above is not enough. d->checkedForLauncher = true; - if (d->task && !d->task.data()->classClass().isEmpty()) { + if (d->task && !(d->task.data()->classClass().isEmpty() && d->task.data()->className().isEmpty())) { // For KCModules, if we matchd on window class, etc, we would end up matching to kcmshell4 - but we are more than likely // interested in the actual control module. Thereffore we obtain this via the commandline. This commandline may contain @@ -558,8 +558,13 @@ KUrl TaskItem::launcherUrl() const KConfigGroup set(&cfg, "Settings"); // Some apps have different laucnhers depending upon commandline... - QStringList matchCommandLineFirst = set.readEntry("MatchCommandLineFirst", QStringList()); - if (matchCommandLineFirst.contains(d->task.data()->classClass())) { + QStringList matchCommandLineFirst = set.readEntry("MatchCommandLineFirst", QStringList()); + if (!d->task.data()->classClass().isEmpty() && matchCommandLineFirst.contains(d->task.data()->classClass())) { + triedPid = true; + services = getServicesViaPid(d->task.data()->pid()); + } + // Try to match using className also + if (!d->task.data()->className().isEmpty() && matchCommandLineFirst.contains("::"+d->task.data()->className())) { triedPid = true; services = getServicesViaPid(d->task.data()->pid()); } @@ -585,7 +590,7 @@ KUrl TaskItem::launcherUrl() const // So, Settings/ManualOnly lists window classes where the user will always ahve to manual set the launcher... QStringList manualOnly = set.readEntry("ManualOnly", QStringList()); - if (manualOnly.contains(d->task.data()->classClass())) { + if (!d->task.data()->classClass().isEmpty() && manualOnly.contains(d->task.data()->classClass())) { return d->launcherUrl; } -- 1.7.10.4
Created attachment 75408 [details] Patch that modifies libtaskmanager so it will attempt to find a launcher for a window with null classclass This is the same patch included in the first report. Sorry, I just now realized the bugtracker has support for attachments.
Git commit daa0b5fb8def3e501477391f8445c9d86db28511 by Craig Drummond. Committed on 24/11/2012 at 10:28. Pushed by craig into branch 'KDE/4.9'. Attempt to find launchers for windows with empty WM_CLASS M +47 -40 libs/taskmanager/taskitem.cpp http://commits.kde.org/kde-workspace/daa0b5fb8def3e501477391f8445c9d86db28511
Git commit 413eec02d0b9d4d6e7644ad5813cdd60ef8d3de9 by Craig Drummond. Committed on 24/11/2012 at 10:24. Pushed by craig into branch 'master'. Attempt to find launchers for windows with empty WM_CLASS M +47 -40 libs/taskmanager/taskitem.cpp http://commits.kde.org/kde-workspace/413eec02d0b9d4d6e7644ad5813cdd60ef8d3de9