Summary: This then invokes the relevant KCM when clicked
Test Plan:
Forced software rendering, saw SNI
restarted, saw SNI
set "never show again". It hid itself
Restarted. It remained hidden
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: alexeymin, broulik, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D12679
Summary:
If we cannot create a GL context, instead of showing an error and
quitting, switch to using the QtQuick software renderer and restart.
If software mode is already set, then show the error as before. This
could happen in the case of the software renderer not being installed.
Test Plan:
After doing some driver changing, I ended up with the annoying "plasma can't start"
message.
Without the entry in kdeglobals I now start plasma and it seamlessly comes up
working.
Reviewers: #plasma
Subscribers: mart, broulik, graesslin, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D11722
Summary:
DesktopView contains a property candidateContainments which are all containments with the same screen for all activities.
Plasma mobile can use it to do activity switching with a swipe gesture
replaces D11333
Test Plan:
tested with gesture based activity switching in plasma mobile including creating and deleting
of activities
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D12351
Summary:
with new corona containment query functions in D11361 the data
copy done in m_desktopContainments is no more necessary: this should
make things a bit more simple and robust
Test Plan: launched plasmashell, tried to add/remove activities and screens, all keeps working
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: davidedmundson, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D11801
Summary:
Calls the existing quit signal on a running plasma then tries to start
in the normal way.
It's meant partly to make my own development workflow a bit easier, but
also to make it one less line on bugzilla when I want people to give me
debug output.
Test Plan:
Ran with existing plasma running
Ran without an existing plasma running
Reviewers: #plasma, apol
Reviewed By: apol
Subscribers: apol, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D12092
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:
Original decision didn't really have a rationale:
https://git.reviewboard.kde.org/r/125648/
It's causing bugs in people doing somewhat sensible things.
BUG: 380347
If widgets are locked, the script will still fail when it tries to do
something it can't.
Reviewers: #plasma, broulik
Subscribers: mart, broulik, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D11375
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:
Wallpaper plugins were storing their configurations in the same config
group, overwriting each other's values.
Test Plan:
0. Apply revision D11194 (plasma-desktop).
1. Right-click the desktop and click Configure Desktop.
2. Select Wallpaper Type -> Plain Color. Click the chooser button
and select green. Hit Apply.
3. Select Wallpaper Type -> Picture of the Day. Click Background
Color button and select red. Hit Apply.
4. Select Plain Color type again. The color should still be green.
Reviewers: #plasma, mart, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: davidedmundson, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D11195
I noticed in GammaRay there were two QQmlEngine instances in a Plasma session and found this.
Differential Revision: https://phabricator.kde.org/D10774
Summary:
CCBUG: 358231
CCBUG: 342056
Even the icon with the number of tasks pending moves from time to time.
To reduce the frozen time, a similar patch must be applied also to
frameworks/kwindowsystem src/platforms/xcb/kxmessages.cpp
frameworks/plasma-framework src/plasma/private/effectwatcher.cpp
According to the documentation (and a look to the source code)
http://doc.qt.io/qt-5/qabstractnativeeventfilter.html
The type of event eventType is specific to the platform plugin chosen
at run-time, and can be used to cast message to the right type.
On X11, eventType is set to "xcb_generic_event_t", and the message can
be casted to a xcb_generic_event_t pointer.
The other eventType are "windows_generic_MSG" and "mac_generic_NSEvent".
No other eventType starts with an 'x'.
Test Plan:
Cut & paste 2000 small files.
Before, a freeze (plasmashell not responding) of minutes
After, a freeze of seconds
Reviewers: #frameworks, #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: broulik, davidedmundson, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10627
Summary: BUG: 390499
Test Plan:
See callgrind in bug report
Added debug in the relevant section, unplugged a monitor. Saw my output
Reviewers: #plasma, broulik
Subscribers: jtamate, mart, broulik, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10538
Summary: All things we need exists in the top level CMakeLists
Test Plan: Compiles
Reviewers: #plasma, bshah
Reviewed By: #plasma, bshah
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10544
ECM, when requiring ECM >=5.38, sets CMAKE_*_OUTPUT_DIRECTORY, so the
tests executables are no longer generated in the current binary dir.
Calling add_test() with the signature
add_test(<name> <command> [...])
will not result in any further processing of the <command> argument,
it will be executed as is. Using instead
add_test(NAME <name> COMMAND <command> [...])
will result in <command> getting some handling, cmp. CMake docs:
"If <command> specifies an executable target (created by add_executable())
it will automatically be replaced by the location of the executable
created at build time."
Which is what is needed now here (and also used in ecm_add_test).
Summary:
To test if the panel is under the cursor we used:
if (geometry().contains(QCursor::pos(screenToFollow()))) {
Unsurprisingly in wayland we don't know the cursor position once it's
left our window. Behaviour seems to be undefined.
We were already using enter and leave events to start the autohide
timer, so we may as well rely on that for tracking state too.
BUG: 377838
Test Plan:
Tested mouse in, mouse out
Tested mouse in and waiting and panel stayed open
Tested opening wifi applet and closing it
That will trigger the restoreAutoHide method as an applet status changed
The panel stayed open because the mouse was on it.
Reviewers: #plasma, mart
Reviewed By: #plasma, mart
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D10101