Summary:
GIMP 2.10 is still being a bad desktop citizen and requires a workaround
of this sort as well.
A nicer fix to do at a later time would be a regex-based rewriting rule
that won't need version updates.
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D21954
Summary:
GIMP 2.10 is still being a bad desktop citizen and requires a workaround
of this sort as well.
A nicer fix to do at a later time would be a regex-based rewriting rule
that won't need version updates.
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D21954
Summary:
Some apps initially show their window with bogus/useless window
metadata and then update to useful metadata during early startup.
For example, LibreOffice sets WM_CLASS to soffice/Soffice and
then updates to libreoffice-writer/libreoffice. This leads to
a poor user experience on particular the Icons-only Task Manager,
but also the regular Task Manager depending on settings.
Depending on its configuration (and Icons-only Task Manager is
a particular set of configuration options, as far as the model
is concerned), TasksModel will try to sort a new window task
adjacent to its launcher task. The appearance of a new window
task also causes matching (in terms of identification) launcher
or startup tasks to be filtered out. To the user, this forms a
lifecycle of the launcher being replaced by the window in-place
(and a startup state inbetween, optionally but by default).
Prior to this patch, this sorting decision was only done once,
when a new window enters the source model stack. This meant the
LibreOffice window would initially be sorted into the "wrong"
spot (the bogus metadata doesn't allow us to relate it to its
launcher) and then, following the metadata change, stick to the
wrong position.
Simply changing the code to sort things again on any metadata
change would not have been good enough: Metadata changes can
occur at any time, and things should not just move around on
the user - this sort mode is called "Manual" for a reason. Also,
the visual result would still be poor: The window would initially
appear at the wrong position, then move to the right one a bit
later.
This patch takes the following approach:
* It adds a new config key to taskmanagerrulesrc for listing
ids of matching tasks to completely hide, and of course the
code needed to implement this.
* It adds LibreOffice' bogus initial metadata to this key, so
the tasks is initially hidden.
* The sort code skips over hidden window tasks in the sort
insert queue instead of moving them. The queue is marked as
stale then, and cleared on unrelated windowing system changes.
* It resorts when tasks are unhidden (i.e. once the metadata
update has occured and the task no longer matches the above
config key).
The visual result is that the startup notification on the
launcher spins a little bit longer than before, even though the
window has already appeared (although LO lags in filling in its
contents anyway), and then morphs into the window task
representation once the client has completed the window metadata
change. This happens in such a short order as to be more or less
imperceptible.
If startup notifications are turned off it's broadly the same,
minus the spinning.
BUG:396871
Reviewers: davidedmundson, broulik, ngraham
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D15410
Summary:
After we improved our StartupWMClass handling we worked with Wine
in https://bugs.winehq.org/show_bug.cgi?id=32699 to get them to add
StartupWMClass=foo.exe keys to the .desktop files they generate,
since they have foo.exe in WM_CLASS.
This old rule short-circuits the StartupWMClass handling prevented
this from actually working on our side.
BUG:393787
Reviewers: broulik, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D13058
Summary:
This introduces a TryIgnoreRuntimes key in taskmanagerrulesrc's Settings
group that can be used to list known runtime executables that can be
ignored when trying to identify the application owning a window by the
command line of the associated process.
A concrete example is the Frozen Bubble application. Frozen Bubble
installs a frozen-bubble.desktop with Exec=frozen-bubble, yet its
WM_CLASS is ("perl", "perl") and its command line is as follows:
/usr/bin/perl /usr/bin/frozen-bubble
The existing servicesFromPid() (now split into servicesFromPid() and
servicesFromCmdLine()) does not find the frozen-bubble service because
it works with the leading executable in the command line.
In this patch, TryIgnoreRuntimes is introduced with a default of
"perl". In the new code, after the initial command line matching pass
fails, TryIgnoreRuntimes is checked for whether the leading command
line executable is on the list, and if so, a second command line
matching pass is run with the remainder of the process' command line,
now succeeding.
Note that the approach of "try one more thing" rather than checking
against TryIgnoreRuntimes first is deliberate: The Exec= key in many
.desktop files contains a complete command line prefixed with the
runtime executable. In those cases we don't want to ignore the runtime
executable, or matching would fail.
To complement this, the "perl" WM_CLASS is added to the
MatchCommandLineFirst rc key. Due to the shoddy metadata Frozen
Bubble already ended up in servicesFromPid() regardless, but this
saves some busywork for this WM_CLASS, which can reliably be presumed
bad.
The patch also fixes a small logic error in the match-command-line-
without-arguments block, where the result of a KServiceTypeTrader
query was ignored and immediately overridden by another.
Reviewers: #plasma, davidedmundson, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5522
Summary:
WM_CLASS instance and general classes are checked against StartupWMClass
prior to most rewrite and mapping rules, and prior to the DesktopEntryName
and Name checks.
This matches the fd.o spec more closely and makes Chrome Apps and
LibreOffice work without special mapping rules, which is also a speed
win.
Reviewers: #plasma, davidedmundson, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4706
We only matched for the "Default" suffix which is the default profile but this breaks
when having apps installed in different profiles where they get e.g. "Profile_1" suffix.
BUG: 376695
FIXED-IN: 5.9.3
Differential Revision: https://phabricator.kde.org/D4680
Summary:
Versions of VirtualBox packaged on Neon and Fedora now have
a proper WM_CLASS:
Fedora: WM_CLASS(STRING) = "VirtualBox", "VirtualBox"
Neon: WM_CLASS(STRING) = "Qt-subapplication", "VirtualBox"
And install a matching virtualbox.desktop.
We can therefore drop this rule.
BUG:350468
Side note: The rule should actually still have worked, but
for some reason KServiceTypeTrader refuses to match a .desktop
with 'Exec=VirtualBox %U' when we query for 'VirtualBox', as
extracted from cmdline. I'm talking to dfaure about it.
Reviewers: #plasma, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4346
Depending on the distribution, Chromium identifies itself as "chromium" or "chromium-browser". Account for this.
CHANGELOG: Chromium WebApp windows are no longer treated as Chromium browser windows in task manager
Differential Revision: https://phabricator.kde.org/D3450
Google Chrome needlessly changed its window class class to Google-chrome
(was google-chrome previously) breaking our launcher mapping.
BUG: 372211
FIXED-IN: 5.8.4
Differential Revision: https://phabricator.kde.org/D3308
This allows more complicated rules, useful for matching Chrome webapps to their
respective desktop file where we need to change crx_foo to chrome-foo-default.
BUG: 358277
CCBUG: 356609
FIXED-IN: 5.7.0
Differential Revision: https://phabricator.kde.org/D1673
Summary:
Also ports in-module users of the library.
Translation domain and pot file name remain unchanged, as the new lib
contains no strings.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1721
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
techbase wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://community.kde.org/Frameworks/GitOldHistory
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo kde-workspace, frameworks branch, at commit
049113e719dd2fc4446d054fa1a3aada330094f0
Eike Hein
Kai Uwe Broulik
David Rosca
Pinak Ahuja
Aleix Pol