After leaving "Do not disturb" mode, a flood of on-screen notifications
ensues, causing the right-hand side of the screen to be full of rapidly
scrolling and disappearing notifications for the next minute.
The user doesn't need to see any notification popup that is suppressed
by DnD mode, because the notification can be viewed from the drawer anyway.
BUG: 440837
FIXED-IN: 5.25
Qt6 insists on that. We can do this either by including the moc files,
or by including the corresponding headers in the header defining the
properties, the former seems cleaner.
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.
Kai Uwe Broulik
Devin Lin
Xaver Hugl
Fushan Wen
Laurent Montel
Volker Krause
Nicolas Fella
ivan tkachenko
David Edmundson
Aleix Pol
Alexander Lohnau
Carl Schwan
Adrien Faveraux
Bhushan Shah
Nate Graham
Oleksandr Popel
Ahmad Samir