Summary:
There are two proposed justifications for this addition:
- In general, VDG would like to move towards consistently using the Meta key for global shortcuts
- Switching macOS users will be able to activate KRunner with the exact same keyboard shortcut they used to activate Spotlight
Reviewers: #vdg, #plasma, ndavis, GB_2
Reviewed By: #vdg, ndavis, GB_2
Subscribers: GB_2, romangg, ndavis, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D24033
Summary: kcrash must be used else it will not be linked and crashes will crash instead of kcrashing
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D23487
Summary:
Requests several KWin-specific interfaces to be used on KRunner and
Plasma Shell.
Test Plan: See D22571
Reviewers: #plasma, #kwin, davidedmundson
Reviewed By: #plasma, #kwin, davidedmundson
Subscribers: davidedmundson, zzag, mvourlakos, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D22589
* Don't autostart KRunner, use actions in the desktop file to
define global shortcuts and actions
* install its desktop file in share/kglobalaccel to make shortcuts default
* expand commandline options to permit more control via commandline
Differential Revision: https://phabricator.kde.org/D9037
Summary:
We are currentlly very inconsistent how we refer to KRunner, impairing comprehensibility
among both expert users (who know it as "KRunner") and novice users (for whom "Run
Command" has a literal and somewhat scary meaning).
This patch is a part of {T10966} and standardizes on "Show KRunner", helping to turn
KRunner into a user-visible brand name like Apple's Spotlight.
Test Plan:
{F6842497}
{F6842498}
Reviewers: #vdg, #plasma, ndavis
Reviewed By: #vdg, ndavis
Subscribers: ndavis, plasma-devel
Tags: #plasma
Maniphest Tasks: T10966
Differential Revision: https://phabricator.kde.org/D21341
Summary:
It is not uncommon to run the same command repeatedly. In this case,
the history is actually unchanged - the item is removed from the first
position, and prepended again.
Test Plan:
run the same command twice, config file is not rewritten
run a new command, config is updated
Reviewers: #plasma, broulik, apol
Reviewed By: #plasma, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D20383
Summary:
As discussed the env variables are no longer exported. Thus Qt
applications follow the default qpa platform they are compiled with and
thus still function if they are packaged with a Qt without QtWayland.
Plasma's internal processes pick the qpa platform depending on the
session type as well as our flatpak apps.
KRunner and Plasmashell are adjusted to not leak the env variable they
set for themselves.
Test Plan:
Started a wayland session, verified with KWin's debug console
that plasmashell and krunner are wayland. Launched kwrite from both plasma
and krunner and verified that it's xcb
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D11447
Summary:
This is a preparation step to unset QT_QPA_PLATFORM from the wayland
startup session script. Setting QT_QPA_PLATFORM breaks 3rd-party Qt
software which does not bundle QtWayland. Most prominent example is
the Qt installer itself (see
https://bugreports.qt.io/browse/QTBUG-60222).
On the other hand our Plasma workspace applications need to be forced to
Wayland on a Wayland system. So we have a conflict between we want to
set QT_QPA_PLATFORM and we don't want to set QT_QPA_PLATFORM.
This change adds new API to KWorkspace to address this problem. The new
method adjusts the QT_QPA_PLATFORM based on the XDG_SESSION_TYPE
enviornment variable. It is completely opt-in. Meaning applications need
to explicitly add the call prior to creating the QGuiApplication and if
the user specifies either QT_QPA_PLATFORM env variable or any of the
-platform command line argument variants, the platform detection is
skipped.
The change also adjusts all plasma-workspace applications which should
use Wayland on Wayland to use the new API. The startup script on the
other hand still sets QT_QPA_PLATFORM. We also have applications outside
of plasma-workspace which needs this detection. Examples are:
* powerdevil
* systemsettings
* kinfocenter
Once this change is merged those applications can be adjusted by linking
against PW::KWorkspace and afterwards QT_QPA_PLATFORM can be unset from
startplasmacompositor.
Test Plan: See added autotest
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10816
Summary:
Consistent usage of install variables avoids mismatches for people who
make use of custom settings of install paths.
Reviewers: #plasma, apol
Reviewed By: apol
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10400
Summary:
Consistent usage of install variables avoids mismatches for people who
make use of custom settings of install paths.
Reviewers: #plasma, apol
Reviewed By: apol
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10400
Summary:
Don't go through the workaround introduced for X11 that makes it go mental.
BUG: 385693
Test Plan: Have been a happy krunner user since
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: ngraham, davidedmundson, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10197
Summary: QUrl::fromLocalFile can't be used when packages are qrc
Test Plan: plasashell loads correctly with packages from qrc
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9176