wilderjds/kwin - kwin - gitea-jacopods

15305 Commits

36 Branches

0 Tags

96 MiB

Tag: Branch: Tree: 8e237862fe

Commit Graph

Author	SHA1	Message	Date
Martin Gräßlin	a9ac70f007	It makes sense to actually also build the new input_event_spy.cpp Sometimes C++ surprises me. How could that compile without being in the build set?	9 years ago
Martin Gräßlin	84e3308149	Introduce an InputEventSpy for processing input events Summary: So far KWin's input event processing is mostly based on InputEventFilters. A filter can - as the name suggest - filter out an input event from further processing. Our code shows that this is not sufficient for all input event processing. We have several areas inside KWin where we need to have access to all input events, where the processing needs to happen on all events and filtering is not allowed. This results in sub-optimal code which has classes which know too much and do too much. Examples: * key-repeat handling done in KeyboardInputRedirection * Layout change OSD in Xkb * modifier only shortcuts in Xkb * emitting signals for Cursor class in KeyboardInputRedirection Also there are misuses of the InputEventFilters and internal API * DebugConsole keyboard state (uses wrong information) * DebugConsole input events tab (uses Filter, should be a spy) This change introduces the API needed to fix these problems. It introduces an InputEventSpy which is modelled after the InputEventFilter with the difference that it has only void messages and uses the KWin introduced event classes. The spies are always processed prior to the filters, thus we know it can have all events. Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D3863	9 years ago

Author

SHA1

Message

Date

Martin Gräßlin

a9ac70f007

It makes sense to actually also build the new input_event_spy.cpp

Sometimes C++ surprises me. How could that compile without being in
the build set?

9 years ago

Martin Gräßlin

84e3308149

Introduce an InputEventSpy for processing input events

Summary:
So far KWin's input event processing is mostly based on
InputEventFilters. A filter can - as the name suggest - filter out an
input event from further processing. Our code shows that this is not
sufficient for all input event processing.

We have several areas inside KWin where we need to have access to all
input events, where the processing needs to happen on all events and
filtering is not allowed. This results in sub-optimal code which has
classes which know too much and do too much.

Examples:
 * key-repeat handling done in KeyboardInputRedirection
 * Layout change OSD in Xkb
 * modifier only shortcuts in Xkb
 * emitting signals for Cursor class in KeyboardInputRedirection

Also there are misuses of the InputEventFilters and internal API
 * DebugConsole keyboard state (uses wrong information)
 * DebugConsole input events tab (uses Filter, should be a spy)

This change introduces the API needed to fix these problems. It
introduces an InputEventSpy which is modelled after the InputEventFilter
with the difference that it has only void messages and uses the KWin
introduced event classes.

The spies are always processed prior to the filters, thus we know it can
have all events.

Reviewers: #kwin, #plasma

Subscribers: plasma-devel, kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D3863

9 years ago

2 Commits (8e237862fe54d84236ca2ed44ff71ebd5351f3c8)