1. `undefined` is an invalid value for `Layout.Preferred[something]`; instead
use -1 which is the correct thing.
2. `Layout.maximumLineCount` doesn't exist; use `Layout.maximumWidth` which was
probably the intention.
The value of previousItemInFocusChain is appletContainer when the applet
is on desktop, but we don't want to establish hidden tab focus relation
between appletContainer and the last battery item, so use `Keys.onTabPressed`
instead.
1. Add arrow key navigation support
2. Imrpove a11y description for battery items, so messages like "Your
battery is unhealthy" can be read by a screen reader.
The virtual keyboard can appear with a touch input, not just when
you're in Touch Mode. However b1888b5e9e
made the button only appear when in Touch Mode, giving the user no
clear way to close the virtual keyboard when it was invoked outside of
Touch Mode.
This commit fixes that by always showing the close button when the
keyboard is visible due to being activated with a touch event outside of
Touch mode. There is no change for the "disable virtual
keyboard" button.
The date can be changed using scrolling or the buttons provided. It does not animate the view though. With this MR I have tried to implement this. Though the goal here is not just animating the view. The user can now flick the view as well to change date. There is already https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1843 this MR that does all of this and more. But there was many controversial changes and the code was a mess. The way animation was being handled could be improved. This is a much more smaller version of that MR. I have tried to make as less changes as possible to the MonthView since it is already very messy. All I have done is creating a new component and wrapped the views in that component. The code changes not as much in the MonthView as it seems in the diff. Here's what I am talking about:
This will feel weird and random to the user, especially if they or one
of their apps deliberately uses that icon and then it unexpectedly isn't
displayed. This check feels too magical and unpredictable; let's remove
it to simplify things.
BUG: 458843
FIXED-IN: 5.26
Adds support to the new information offered by KWin. Now it can tell us
that the current client doesn't support Wayland input methods.
Therefore, it sets the plasmoid in a new "unsupported" state that will
offer to force an activation when triggered. KWin will then be able to
emulate a keyboard and it all should work to some extent.
Depends on https://invent.kde.org/plasma/kwin/-/merge_requests/2907
BUG: 439911
The current code gathers AppStream IDs by looking at the app's desktop
name and then adding ".desktop" onto the end of this, reflecting a
now-deprecated convention that every AppStream ID ought to end in
".desktop". This hasn't been true for a while and isn't correct today;
let's use a more modern API that returns more correct results.
BUG: 458812
FIXED-IN: 5.24.7
ba44b69abf added logic to handle apps that
use an absolute path in their .desktop file to define their icon, which
works. However in the process it introduced a subtle bug: if the icon is
not an absolute path and it's just a normal icon name, when
QFileInfo::exists() checks for the existence of that string, it will
treat it as a relative file path and therefore look for it in the
current working directory, which is typically the user's homedir. If it
finds something, it will go down the wrong code path and end up
returning a blank QIcon. This can be verified by adding a folder with
the name of an app icon into ~ and restarting plasmashell; that app in
Kickoff will have a blank icon.
To fix this, the icon loading code now first checks whether the icon
returned by m_service->icon() is actually an absolute path. If not, it
skips the logic to look for it on disk and goes straight to the
codepath that looks for an icon with that name in the icon theme.
To minimize disk reads, it checks for absolute-file-path-ness by
inspecting the string returned by m_service->icon() rather than using
QFileInfo::isAbsolute(), because this is a hot code path and most icons
will not have relative paths, so checking the disk for every one of
them would be a waste of resources.
BUG: 457965
FIXED-IN: 5.24.7
Those files may be executable and the user wants them to execute. For
example:
- Shell scripts the user has written to perform commonly-used actions
- Windows executables opened with WINE
For this reason, we should stop explicitly blocking running executable
files when accessed with KRunner runners or Kicker/Kickoff/Application
Dashboard, and instead show the typical "open or execute?" dialog that
respects the user's setting for what to do in this case.
BUG: 455924
FIXED-IN: 5.26
Otherwise clicking it would show an "invalid URL" error and
trying to open the properties dialog would trigger an assert.
This can normally not happen but you can get here with e.g. plasmoidviewer
BUG: 455433
ivan tkachenko
Kai Uwe Broulik
Nate Graham
Fushan Wen
Tanbir Jishan
Aleix Pol Gonzalez
Volker Krause
Alexander Lohnau
l10n daemon script
Flo Edelmann
Heiko Becker