Summary:
QAbstractProxyModel forwards hasChildren() to the source model, which
will return a wrong value for our tree-restructuring model. Current
views/proxies don't call hasChildren(), which is how this oversight
happened, but implementing it improves model hygiene - could blow up
in the future otherwise.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1799
Summary: new library features new ABI
Reviewers: hein, jriddell
Reviewed By: jriddell
Subscribers: jriddell, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1785
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
Summary:
When no match can be made from classClass, attempt a fallback where we
match any DesktopEntryName that contains classClass and drop all that
do not end with '.$classClass' (i.e. ones that certainly are not using
reverse-domain-name notation. classClass is usually the appname, but
without RDN.
So, when a RDN using application cannot be matched directly (i.e. its
classClass is different from its binary name) we'd end up with an
unsuccessful mapping and use the binary-path as launcherUrl. To improve
on this when that case occurs we now attempt to loosely find a single
matching RDN desktop file and prefer that over the binary fallback match.
Illustrative example:
- org.kde.dragonplayer.desktop
- binary is 'dragon'
- qapp appname and thus classClass is 'dragonplayer'
- classClass cannot directly match the desktop file because of RDN
- classClass also cannot match the binary because of name mismatch
- now *.classClass can match org.kde.dragonplayer though
Reviewers: hein
Reviewed By: hein
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1447
When new task is added to GroupManager, it will be ungrouped
if the task demands attention. Group it back again once it loses
demands attention state.
Differential Revision: https://phabricator.kde.org/D1267
Utilility windows are typically omitted from the task tree, unless they
are in demands-attention state. SVN r901886 (cf. bug 178509 from 2008)
introduced a bug by preventing tasks included in this fashion from
reaching active state, causing the demands-attention state not to ever
be cleared. Additionally, a separate bug prevented utility windows
losing demands-attention state from being removed from the task tree
thereafter. This patch fixes both.
This cropped up with recent versions of The Gimp, which curiously
sets its utility windows to demand attention when opened from within
the app. Since windows demanding attention are also implicitly exemped
from grouping, this appeared to users as a failure of the grouping
logic.
BUG:352477
CCBUG:178509
Libtaskmanager so far only has compile time checks for windowing
systems resulting in the X11 specific code to be executed on platform
wayland which of course causes crashers.
This is a workaround by at least ensuring that we only call X11 specific
code on platform X11.
REVIEW: 125445
This is a follow-up to fbd4a876, which introduced an option to
have running tasks always use the same icon that would be used
for a launcher item. The Task Manager applets subsequently were
updated to default this option to on, addressing frequent user
complaints that Task Manager launchers don't respect their
theming choices (due to window icons overriding the icon theme,
or custom configured icons) or that the icon changes when a
launcher item is replaced by a running task item.
However, for windows that can't be mapped back to an application
known to the menu system, this meant falling back to the MIME
type of the executable, making applications that aren't properly
installed usually end up with application-x-executable or some-
thing else.
This commit changes behavior so that if the launcher URL pro-
duced for a window isn't a valid KService storage id, the window
icon is used again. In turn, since the behavior is now no longer
a trivial yes or no, the option has been dropped from the
library again, making the menu-icon-takes-precedence approach
always-on. In turn, if a launcher item is generated while a
window is around, the icon is taken from the window and stored
persistently. If a launcher is added programmatically using an
URL that can't be mapped to the menu, the icon will be updated
from the window icon at runtime.
BUG:351624
CCMAIL:jkt@kde.org
With the option disabled, task items use the window icon whenever
possible. With the option enabled, the launcher icon is used
instead. This prevents a jarring icon change when applications use
a different icon theme from Plasma Desktop, at the cost of losing
realtime window icon updates being reflected in the Task Manager.
Defaults to on. The Task Manager applets are getting a checkbox
for it.
This is a rock-and-a-hard-place decision. Users are regularly
upset about what they perceive as their theming choice not being
respected, and pleading for app fixes appears to be fairly fruit-
less. It also looks like Wayland will nix runtime window icon
changes. Nonetheless this will likely produce complaints about
edge cases (e.g. Gimp miniature window previews).
CCMAIL:348050
This fixes launchers without .desktop files to not have icons in some
cases. The patch makes sure the icon that is read from the config file
is actually used for the launcher.
Reviewed-by: Eike Hein
Pinak Ahuja
Allen Winter
Eike Hein
Harald Sitter
Kai Uwe Broulik
David Rosca
Ivan Čukić
Aleix Pol
Montel Laurent
Martin Gräßlin
Marco Martin
Martin Klapetek
Elias Probst
Lukáš Tinkl
Jonathan Riddell