This avoids showing paths like /tmp/somefile as "500 GiB Internal
Hard Drive/tmp/somefile", or "Root/tmp/somefile".
It's more sensible to show the actual path in this case.
It still look far too alien comparing to a native PlasmaDialog style due
to the positioning, fractional scaling sizing issues and background
differences. This commit brings them somehow closer to each other.
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
Press-and-hold is fairly common on touch UIs, but click-and-hold is a
very rare interaction. As a result, the user is much more likely to
enter Edit Mode accidentally while trying to drag something on the
desktop than they are to know that click-and-hold works here and do
it intentionally.
Let's disable click-and-hold and only enter Edit Mode with a
press-and-hold using a touch device. For pointing device users, there
are already multiple context menus items that will let them enter Edit
Mode.
BUG: 457979
FIXED-IN: 5.26
This adds `m_blockRestorePreviousWindow` to avoid restoring focus to the
panel, and replace QHash with QMap to save panel orders.
CCBUG: 453166
CCBUG: 352476
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
Now users can modify LC_ADDRESS, LC_IDENTIFICATION, LC_NAME and LC_TELEPHONE from region settings.
See LC_IDENTIFICATION example here: https://lh.2xlibre.net/locale/fi_FI/
BUG: 204525
BUG: 430801
Instead use KRuntimePlatform::runtimePlatform from KCoreAddons.
The defunct code to set the runtime platform was removed. This value gets set using ENV variables.
Task: https://phabricator.kde.org/T15492
Currently, the progress indicator is normally displayed only if the DPI is a
multiple of 100; at other DPI values it's almost invisible or not visible at
all. This commit fixes that issue.
BUG: 435004
FIXED-IN: 5.24.7
On Wayland, the primary screen notification and
QGuiApplication::screenAdded signals are desync. The primary output
watcher addresses that by emitting its primaryOutputNameChanged() signal
when the corresponding QGuiApplication::screenAdded() signal is emitted.
However, since the primary output watcher processes the screenAdded
signal before ScreenPool, it can emit the
ScreenPool::primaryScreenChanged signal before ScreenPool::screenAdded
signal that can confuse the ShellCorona.
It makes sense for ToolBar button in CompactRepresentation, because
background depends on it, but it is useless for custom AbstractButton
which has no special code handling this value.
Not sure what exactly didn't work back than, not currently on Qt 5.15
everything seems fine.
Binding.RestoreNone is not the most recommended[1] value, but it
replicates the behavior of one-time assignment which was happening in
Component.onCompleted handler.
[1]: https://www.mail-archive.com/interest@qt-project.org/msg36486.html
MenuDelegate is a QQC2.Control's subclass, which is perfectly capable of
handling hover and press events on its own. Besides, few extra
properties and a custom signal make it feel like a dedicated component
which it really is.
Not sure how much (if at all) this makes sense performance-wise, but at
least the code looks cleaner and there are no duplicating components
anymore.
State enum is mutually exclusive as it is, so there's no way there could
have been more than one FrameSvgItem on screen at a time.
Fushan Wen
Nicolas Fella
Kai Uwe Broulik
Nate Graham
l10n daemon script
Volker Krause
ivan tkachenko
Laurent Montel
David Edmundson
Devin Lin
Akseli Lahtinen
Marco Martin
Alexander Lohnau
Eugene Popov
Vlad Zahorodnii
Fabian Vogt