Summary:
So far we were following a bit unique and rare doxygen comment style:
/**
* Contents of the comment.
**/
Doxygen comments with this style look balanced and neat, but many people
that contribute to KWin don't follow this style. Instead, they prefer
more traditional doxygen comment style, i.e.
/**
* Contents of the comment.
*/
Reviewing such changes has been a bit frustrating for me (so selfish!)
and for other contributors.
This change switches doxygen comment style in KWin to a more traditional
style. The main reason for doing this is to make code review process easier
for new contributors as well us.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22812
Summary:
We have a mix of different doxygen comment styles, e.g.
/*!
Foo bar.
*/
/**
* Foo bar.
*/
/** Foo bar.
*/
/**
* Foo bar.
*/
/**
* Foo bar.
**/
To make the code more consistent, this change updates the style of all
doxygen comments to the last one.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18683
Summary:
KWin used to do a quirky trick to send key events to the topmost QQuickItem
rather than things going to the activeFocus item.
Sending it to the window previously would have failed as the window
didn't think it was active.
Since 66986d4afd we can just let the
window process the events in a normal QtQuick manner.
BUG: 370185
Fixed-in: 5.15.0
It will require tabboxes to set focus correctly.
The ones I tested did.
Most analysis for this patch was done by Chris Holland.
Test Plan:
Held+alt tab with the "Text" tabbox switcher
pressed up and down
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin, Zren
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16693
Summary:
Without pretendingn to activate the Window, Qt will not send
the right signals for accessibility, thus screen readers not working.
Reviewers: kwin, davidedmundson
Reviewed By: davidedmundson
Subscribers: graesslin, davidedmundson
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16664
Summary:
The switch statements iterated over all possible enum values.
When a new enum value is added, it will generate a compiler warning this way.
Reviewers: davidedmundson
Reviewed By: davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16480
Summary:
There is a special mode in TabBox which is the noModifierGrab mode. This
is Alt+Tab active without a modifier being hold. This mode is entered
when being activated through screen edges (either pointer or touch). So
far this was not exposed to QtQuick and thus one could not end the mode
using pointer or touch. It is possible to select another window, but not
to activate it. That required the press of a keyboard key.
This setup is rather unfortunate. By exposing the mode to QtQuick we can
react from QtQuick side to it and invoke already exposed functionality to
select and item and directly activate it - existing left-over from the
Plasma Active window switcher.
Test Plan:
Tested on X11 and Wayland with an adjusted lnf package. It kind
of works, but there are additional issues on both X11 and Wayland.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5414
In case we need to set the SwitcherItem model in
`TabBoxHandlerPrivate::show()`, remember the current index row,
otherwise it gets reset to the first item.
Reviewers: #kwin, graesslin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D4162
BUG: 333511
Summary:
The TabBox performs the scrolling of the items by itself in order to
support wheel events even if the mouse is not on the TabBox. For that
KWin grabs pointer events on X11 (on Wayland an input filter is used)
and forwards them to the TabBox.
Qt uses Xinput2 for scrolling on the QQuickWindow. Due to that KWin
does not get any xcb core button press/release events when scrolling
inside the QQuickWindow and thus scrolling doesn't work.
There are three possible approaches to fix this:
1. Implement scrolling support in each of the QML switchers
2. Add an xinput2 filter to TabBox
3. Intercept the QWheelEvents on the QQuickWindow
The first approach has the disadvantage that all themes need
adjustment and that there might be behaviorial difference whether one
scrolls on the TabBox window or outside the window.
The second approach would be most in line with the other filters, but
is difficult due to the nature of xinput2 (no xcb bindings, etc).
Thus the third approach might be the best solution. Wheel events are
only delivered to the QQuickWindow if the native events were not already
intercepted, thus we know it won't have side effects for the case that
Wayland is used or xinput2 is not supported.
The implementation installs an event filter on the QQuickWindow which
gets created when showing the TabBox and inside the filter waits till
there is an angleDelta of +/-120 and scrolls by one per every 120 angle
delta as described in the QWheelEvent documentation.
BUG: 369661
FIXED-IN: 5.8.2
Test Plan: Scrolled with touchpad and mouse wheel.
Reviewers: #kwin, #plasma, broulik
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2953
Summary:
So far TabBox used highlight windows by passing window ids around through
an X property. This doesn't work on Wayland where we don't have window
ids for our TabBox and the Wayland windows.
This change introduces a new Effect::Feature for HighlightWindows which
the HighlightWindowsEffect provides. The EffectsHandlerImpl has a new
method to highlightWindows which it delegates to that effect if it is
loaded by invoking a new performFeature method.
The TabBoxHandler now passes the highlighting to the effects system
instead of updating the x11 property. Thus this works on Wayland and
at the same time improves the X11 side by no longer having to go through
the property protocol.
Test Plan: Verified that Alt+Tab highlights the windows on Wayland correctly.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2630
By using QWindow we can also find the TabBox window on Wayland where
the winId is not really helpful.
This also changes the elevation from Unamanged to Toplevel, so that
it is no longer X11 specific.
Result: TabBox stays on top of all windows also on Wayland.
-use qstringliteral only when necessary (i.e. not in concat or comparison)
-use qbytearray instead of qstring when dealing with latin1 input and output (glplatform)
-use qstringref to extract numbers from strings (glplatform)
-define qt_use_qstringbuilder to optimize all string concatenations
-anidata: use ctor init lists, add windowType member initialization
REVIEW: 125933
Only needed for ScopedCPointer which can be defined in both utils and
xcbutils.h.
Not having utils.h in xcbutils.h makes it easier to have unit tests use
xcbutils.h as it removes the dependencies.
Like with WindowSwitcher the configured value might be for the
look and feel package and thus we should first try to locate it
from the look and feel package.
We assume the configured layout name is a look and feel package. Thus
the Switcher is located at contents/windowswitcher/WindowSwitcher.qml
of that package.
REVIEW: 120849
We need to send the event to a QQuickItem which accepts focus. Just
sending it to the Window or to the contentItem doesn't work as there is
no activeFocusItem (might be related to having the keyboard grabbed).
We try to send the event to all children of the Window's content item.
There should hopefully be one item which accepts the event and properly
reacts on cursor keys.
REVIEW: 118471
Both were only added for the use case of Plasma Active. In the next
iteration we won't need the embedded any more as Plasma is able to draw
thumbnails by itself. So there is neither need for the embedded
functionality nor for the D-Bus interface.
REVIEW: 118464
Instead of having it's own QQmlEngine TabBox just uses the newly
exposed engine from Scripting and creates a new context for it's
own usage.
REVIEW: 116565
By not using a QQuickView it becomes possible to just use a
PlasmaCore.Dialog or a Quick.Window in the TabBox qml and thus it's
possible to simplify the qml code.
To support this a new SwitcherItem is introduced and exported to QML.
It's a simple QObject providing all the properties which used to be
exported to the root context. A declarative TabBox is expected to
use one of these items. The C++ side finds the Switcher and for that
supports the case that the SwitcherItem is the rootItem or a child
item.
A declarative TabBox has also to create a QQuickWindow, e.g. a
PlasmaCore.Dialog. The visibility of that window should be controlled
through the visible property on the SwitcherItem. The underlying C++
implementation assumes that a TabBox only uses one window (it needs to
get destroyed once it's hidden and included in highlight windows).
Thanks to this change it's no longer needed to reload the TabBox
whenever it gets shown or the alternative TabBox gets shown. Instead
the same QML script can get reused. Other created switchers are ignored
as the visible property won't be changed to true.
Not the best solution, but at least TabBox works each time it's invoked.
It doesn't make much of a difference as the QML is reparsed anyway at
each show.
Straight forward port. Note: this is currently crashing deep down in
QtQuick. To circumvent the crashes it helps to disable the property
highlightFollowsCurrentItem in the listviews. This solves the problem
that QtQuick crashes on first loading. Unfortunately it still crashes
if one tries to invoke TabBox for the second time.
This happens because some distros ship broken installations
of KWin and KWinActive, but could also appear to QML hacking users
BUG: 322830
FIXED-IN: 4.11
REVIEW: 111732
It's an option doing pretty much the same as the highlight of selected
window option. But it is known to conflict especially with some Plasma
themes.
BUG: 310935
FIXED-IN: 4.11
REVIEW: 110140
Use xcb to create and manage the X11 backend of Outline. In addition the
used background pixmaps are rendered with XRender instead of using a
QPainter on a QPixmap. This is done because QPixmap is no longer bound to
an X Pixmap.
To create the XRender Picture the available functionality from
kwinxrenderutils is used. To be able to use it in KWin core the compile
option to build without XRender is removed for kwinxrenderutils, but
still supported for effects.
Obviously the port to XCB is not complete as xremderutils itself is still
on XLib.
REVIEW: 108642
