This is for jobs, such as "Loading archive" or "Examining..."
which are purely informational and provide no meaningful
action once finished. When this property is set, a job will
not show a "Finished" notification when finished successfully.
Normally you wouldn't see this because a copy job has a `destUrl`
(which is why I didn't notice) but when removing the filename to "go up"
we need to strip the trailing slash, too.
This ensures that the first `update()` call with the summary will be shown
atomically to the user rather than show an empty job popup briefly.
Also handle the delay on a per-job basis, previously there was a common
timer, which made no sense.
There is no conceivable use case for turning this off, and the UI is
being removed in https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/447.
So let's remove the backend code too, or else anyone who for some reason
had turned it off would be left without a GUI method of turning it back
on again.
Also keep `created()` with the original notification.
As per spec a notification must be replaced atomically with no visual cues.
Transfer over properties that might cause this, such as unread showing the bell again.
xdg-desktop-portal forwards appId only for sandboxed apps it can trust,
essentially blocking us from posting an inhibition from xdg-desktop-portal
as we wouldn't have an app.
This allows a client to mark a notification as "resident" which means it will
not be closed by the sever when expired or an action is invoked, thus transferring
full control over notification life time to the client.
A notification popup still times out as normal (unless persistent, of course)
but the notification remains alive until the client revokes it or a user
explicitly closes it.
It is opt-in so that a client can expect the notification lifetime to be
indefinite and explicitly close it when an action is invoked on its end.
It's dest*url* after all. Makes it easier to debug why it's not displaying correctly.
According to Qt `/foo/bar` is a child of `stfp://foo`, which completely throws
off `KFilePlacesModel`...
Ensures that a file or destination named `<h1>foo.txt` doesn't break the layout.
It still goes through the normal HTML text filter, so remote file access isn't
possible, merely screwing up the layout.
This ensures that an error message the app might have sent in response to the
cancel request is still shown.
Also, while at it deduplicate code by calling into `terminate` from the
service watcher.
This got removed in d82513ce88 as I thought a user would
always have a "Root" entry, leading to "Root/foo" paths.
However, if you hide a place, it will naturally not be considered for `closestItem`
resulting in the final `QUrl::toDisplayString` being hit, giving us a not so
nice `file:///` URL.
While this was in principle a good idea to keep active jobs at the top of the
history, it can cause unwanted dialog shifts and dialog recreation when there
are two jobs and the first one finishes and then the second one finishes.
When removing a notification, it is removed from the model, which will cause the
view to update and move up an older notification, if any. If you now delete a bunch
of notifications in quick succession we will create a dialog every time which then
gets deleted again, causing another notification to move up, etc causing high CPU
spikes and plasma freezes.
This patch compresses removing notifications and tries to announce consecuetive
ranges of notifications to be removed in one go.
BUG: 423594
FIXED-IN: 5.21.0
Laurent Montel
Kai Uwe Broulik
Alexander Lohnau
Nicolas Fella
David Edmundson
Carl Schwan
Adrien Faveraux
Aleix Pol
Bhushan Shah
Nate Graham
Oleksandr Popel
Ahmad Samir