The item's implicit size is supposed to be the size of its contents.
Fixes a regression from ScrollView port and restores line count
limit behavior (8 lines on popups, no limit in history).
Instead of relying on the thumbnail strip size, which can temporarily
change during (re)layouting and/or be incorrect when we initially fetch
the thumbnail.
The potential change in image fidelity in notification history is
imho justifiable over the improved speed and reliability of thumbnail
generation when we don't needlessly create a pixmap we don't use.
Especially for longer downloads where a user is more likely to minimize
the job popup, it is useful to be able to see basic job information
(title, i.e. "Downloads", percentage) without having to open the
notification history.
Moreover, it can be hard to judge completion percentage from the tiny circle.
Rather than relying on `Plasmoid` from deep down in `NotificationItem` code,
which is not possible when run inside the popup.
In `Globals` we have access to our own `plasmoid` property directly.
`Globals` (popup handling) is a singleton and as such has no access
to context properties like `plasmoid`. To remain "API-compatible"
there is a `plasmoid` property in `Globals.qml`.
However, this broke with the port to a singleton type and is
admittedly bad layering.
Move drag handling into a proper singleton type to avoid
cross-referencing `plasmoid` from ten layers deep down the code.
It was nuked years ago, so the id does not exist any longer, and
generated a runtime error like this:
file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/CompactRepresentation.qml:132:
ReferenceError: jobProgressItem is not defined
Amends da86d1e40a
This commit re-implements the critical notification to be inside the
notification popup, not the notification item. This yields several
benefits:
- It's the semantically correct place to implement it since critical
notifications don't appear in the history, so there's no reason to
implement it in a component that's re-used for the history view
- The line extends down to the bottom for critical notifications that
have buttons, job progress, text input fields, files, or screenshots
- Simpler code overall
This reverts commit be7efa5ec2.
This reverts commit 93355636de.
This was not the best way to implement the feature, as it failed to take
into account the fact that critical notifications can have more content
than just text. A better place to implement it would be in the popup
itself.
Prevent `TextArea` in SelectableLabel from accepting wheel
events when the notification item is in FullRepresentation,
and pass wheel events to `ListView` in FullRepresentation when the
cursor is over the `TextArea`.
BUG: 443840
FIXED-IN: 5.24
We get intermittent user complaints and bug reports about notifications
not being visible enough, especially on large or cluttered screens.
This commit attempts to remedy the situation by tinting the header for
on the left side for critical notifications using the color scheme's
"warning" color. Only critical notifications receive this treatment
since they're the only ones that the user really does need to see.
BUG: 420541
FIXED-IN: 5.24
The app name in the header has poor text contrast because it is 40%
transparent and sits on a gray background. It is also using a
semantically incorrect UI component (DescriptiveLabel) which was meant
for de-emphasized subtitles, not titles. The correct component for that
is a Heading, so let's use that.
Because this means that we will hve two identically-sized headings in
close proximity, we need to distinguish the text for the notification
title without making it huge, which is overkill for a notification. To
accomplish this, this MR uses the Heading's "Primary" type which was
made for this purpose.
In most cases the port is trivial and can even simplify the code like in
the case of the system tray applet. In the case of notifications applet,
this is causing a bigger refactor and it's now also using a TextArea
that provides the automatic scrolling when selecting behavior.
CCBUG: 437155
On wayland we need focus to copy to the clipboard.
As we don't want the notification to take focus indiscriminately,
it listens to mouse events of its children and only accepts focus
if it sees a button press. When the cursor leaves the popup again,
everything is reset.
BUG:434675
BUG:408507
These properties were not set correctly and produced a flood of console
spam instead of the desired effect. However the desired effect (header
that touched the edges of the popup) was already achieved anyway through
other means, so they are not needed at all. This commit removes the
offending properties.
This property applies to FrameSVGItem, but notifications were ported to
use PlasmoidHeading directly in dcc448f72f.
Let's remove the now-unused properly so it doesn't cause an error and
spam the log.
There's a custom PlasmoidHeading implementation in notifications now.
This patch ports it to use the generic component. If some changes get made to the component, they will now be reflected in notifications.
There's no API to set `linkColor` on `TextEdit` and it would use the
system link color potentially clashing with the Plasma theme.
BUG: 438366
FIXED-IN: 5.22.3
Allows us to run executables, e.g. downloaded installers.
Also moves some of the logic to the C++ side.
It also indicates "openwith" Kiosk restriction in the UI now by hiding
the button.
It's wrong to check the status of the plasmoid before closing it,
since the status is just the internal state of the plasmoid and
it's changed by actions from the plasmoid itself. So, the Passive
status doesn't indicate that the plasmoid is hidden in the system
tray, because the user can configure to always show this plasmoid.
The notification applet's config window is blank, and only shows the
auto-generated Shortcuts and About pages. This makes it not very useful,
as typically the user will want to get to the KCM instead. Other
applets with blank config windows (such as the Bluetooth and Networks
applets) make the configure button open the KCM instead and nobody has
complained about it, so let's do the same for the Notifications applet.
This has two advantages:
1. Greater consistency among applets
2. The "Clear all" action always appears visibly in the header without
getting pushed into a hamburger menu
3. A cleaner UI than the one merged in
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/837
BUG: 433140
FIXED-IN: 5.22
Kai Uwe Broulik
Aleix Pol
Nate Graham
Carl Schwan
ivan tkachenko
Felipe Kinoshita
Laurent Montel
Fushan Wen
David Redondo
Alexander Lohnau
adrien faveraux
Filip Fila
Devin Lin
Nicolas Fella
Eugene Popov