This is needed due to QTextStream::setCodec being gone without replacement
in Qt6. Instead just read the one line we need here via the QFile API. The
input to this file is a raw const char*, so we can read this without
applying any text codec. There's a subtle difference to keep in mind
though, QFile::readLine includes the line break, QTextStream does not.
Let the user configure if the keyboard is enabled with the virtual
keyboard button. Otherwise it feels unpredictable.
This mimicks the UX in plasmashell itself.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2058468
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.
We already force focus to the password field after showing or hiding the
virtual keyboard, since otherwise it's annoying and you have to manually
re-focus it. Let's do the same for the session and keyboard layout
choosers to save the user a click and some annoyance.
BUG: 451361
FIXED-IN: 5.25
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.
As noted before, the way data engines deal with localized texts seems
dubious, but that hopefully gets fixed by moving away from data engines.
Either way, this doesn't make things better or worse.
The I18N_NOOP use here looks questionable, as we hand out untranslated
strings to somebody else who might use a different domain for translating
them, but probably not worth reworking with data engines on the way out
anyway. This change doesn't make this any better or worse.
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.
That's in a plugin we don't link against here, we only see its header.
This happens to work with Qt5, but Qt6 wants fully defined types for
properties. Use a QAbstractItemModel pointer instead, we only access that
API anyway, and for QML the difference doesn't matter.