Window activation is tracked to implement a new front-
end feature to activate the most recently active window (or fall
through to stacking order otherwise) subsequently.
CCBUG:370258
The KWin setting for whether or not to wrap around was not respected, so
wrap was always true even if the user has turned it off. This commit
fixes that.
BUG: 425787
The test depends on the applications being installed and the path being
correctly set. To make it more robust the path is set inside of the test
and the files the test used are shipped with it.
This isn't always static, espcially in GTK apps where the xproperty is
set later by gmenuproxyodel.
The Appmenu applet already watches for this role changing, but it wasn't
hooked up.
The wayland implementation does not have the same bug.
BUG: 422786
We do this sometimes, but not consistenly.
The benefit is twofold.
First it improves the diff when adding new values since no existing line needs to be touched.
Second it prevents clang-format from collapsing the definition into a single line, which is undesired for large enums.
The LauncherTasksModel tried to avoid a model reset by making certain
assumptions to save a few cycles. Ultimately this was misguided, in-
correctly not evicting the internal app data cache as well as causing
a lot more work in the view trying to compute layout deltas and some-
times causing a few frames of ugly animations.
There likely _is_ some optimization potential here, but it needs to
be done smarter later on.
When computing the delta between the visible and the last saved launcher
order state, following the reordering of launchers, the code was incorrectly
comparing resolved and unresolved (i.e., for config storage) launcher URLs.
This lead to an incorrect result and therefore pinned tasks jumping around
in the Task Manager applet.
BUG:426880
the source model is set asyncronously so onComponentcomplete count is 0, and when the proper source is set the notify is not emitted. furthermore the source canchange at runtime, so count needs to be reevaluated every time this happens
the source model is set asyncronously so onComponentcomplete count is 0, and when the proper source is set the notify is not emitted. furthermore the source canchange at runtime, so count needs to be reevaluated every time this happens
While at it, also remove some unused related includes that are likely remnant from before
this was all done centrally in TaskTools
Differential Revision: https://phabricator.kde.org/D28906
Summary:
launchersOrder and the actual url data can be different:
in case of preferred:/ urls launcherorder will have that for
(for serialization) and the actual appdata url will be decoded as for
instance Applications:firefox.desktop.
this url is the one that needs to be compared to know the actual
launcher order
BUG:418483
Test Plan: firefox stays in first position when pinned as preferred://browser
Reviewers: #plasma, ngraham
Reviewed By: ngraham
Subscribers: ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D28632
Summary:
launchersOrder and the actual url data can be different:
in case of preferred:/ urls launcherorder will have that for
(for serialization) and the actual appdata url will be decoded as for
instance Applications:firefox.desktop.
this url is the one that needs to be compared to know the actual
launcher order
BUG:418483
Test Plan: firefox stays in first position when pinned as preferred://browser
Reviewers: #plasma, ngraham
Reviewed By: ngraham
Subscribers: ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D28632
Rather than relying on KWin to have reconfigured, which isn't the case when merely changing the number of rows.
BUG: 408783
FIXED-IN: 5.18.4
Differential Revision: https://phabricator.kde.org/D28216
Fixes issues that flew under the radar in D27959, namely:
- Missing KWindowInfo flags
- Returning service name instead of object path
Reviewed-By: kbroulik
Summary:
The tasks model now exposes a window's application menu object path and service name.
No update signals set up for XOrg; not sure what to listen for.
Test Plan:
See that the model has more roles and see that they're wired to the application
menu obiect path and service name on Wayland and XOrg.
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: broulik, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D27959
Summary:
VirtualDesktopInfo::Private is ref counted and shared between N
VirtualDesktopInfo's.
We were passing the first VirtualDesktopInfo as a parent to
VirtualDesktopInfo::Private which didn't manage the lifespan or do
anything useful.
The wayland backend incorrectly used this 'q' object and spanned
mulitple internal objects and connections to the first object that
created the shared private instance, leaving us with dangly objects
inside.
BUG: 415200
(and possibly several other bugs of wayland task manager not updating
correctly)
Test Plan:
Compiles
Plasma still loads
Reviewers: #plasma, zzag
Reviewed By: #plasma, zzag
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D27266
The code tried hard to ignore garbage URLs, as Qt is quite lenient, e.g. QUrl("Garbage Url") is still valid.
There is no way to change the strictness of a QUrl after creation,
so the code would enforce it by doing QUrl strictUrl(inputUrl.toString(), QUrl::StrictMode).
However, toString() defaults to PrettyDecoded which avoids percent-encoding and keeps spaces
in tact which is not a valid thing to have in a strict URL.
Effectively, we want to ensure a URL is either a valid path to a local file,
or one of the special applications (for menu ids), or preferred for preferred applications, like web browser,
BUG: 385727
FIXED-IN: 5.18.0
Differential Revision: https://phabricator.kde.org/D26941
AppData contains a QIcon with pixmap data gathered from KWindowSystem::icon which we can just use.
Only if, for some reason, the icon is really null, try getting it from KWindowSystem on demand.
Differential Revision: https://phabricator.kde.org/D26086
The previous QIcon::name() check wasn't sufficient as it only works with theme icon names (e.g. kate)
but not icons created from an absolute path, e.g. /some/special/icon/location/kate.png.
The latter is usually the case for containerized apps which have a proper application desktop file
installed but their icon in some path within the application image or some container daemon location.
Since we already store the information for whether we had to fall back to using the actual window pixmap,
check for this before trying to serialize icon pixmap data.
Differential Revision: https://phabricator.kde.org/D25762
Usarin Heininga
Nate Graham
Niccolò Venerandi
Alexander Lohnau
Nicolas Fella
David Edmundson
Aleix Pol
Henri Chain
Mikel Johnson
Laurent Montel
Eike Hein
Jonathan Riddell
Bhushan Shah
David Redondo
Shubham Shubham
Marco Martin
Benjamin Port
Kai Uwe Broulik
Carson Black