[Differential] [Commented On] D3863: Introduce an InputEventSpy for processing input events

[graesslin (Martin Gräßlin)]

graesslin added inline comments.

INLINE COMMENTS

> sebas wrote in input.cpp:1394
> Wouldn't removeAll() be a bit safer here, or is there a good reason to have spies enqueued twice? (In that case, duplicates should probably be checked before insertion.
> 
> In any case, it should be consistent with the filters' behaviour, so just something to think about.

Yep agree. Having multiple filters/spies installed doesn't make sense. Due to that I chose remove one here. But the filters should be adjusted.

Not sure about checking proof to inserting. It's internal API, so I don't see a real benefit in adding the runtime cost. An asset could be a possibility, though.

> sebas wrote in input.h:192
> Code example would be nice here. Not critical, since it's not public API anyway, but would help *me* personally to understand a bit better how to use it.

Yeah I'm aware that std::bind is something we hardly see in kde code yet (Ivan excluded). The example ae in this change. Giving an explicit code example here - difficult. Too much template magic and I do hope that there are booked and online resources which can explain it better than I could;-)

My suggestion would be to read the code example and check with the c++ documentation what it is doing

REPOSITORY
  R108 KWin

BRANCH
  input-event-spy

REVISION DETAIL
  https://phabricator.kde.org/D3863

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma, sebas
Cc: sebas, plasma-devel, kwin, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20161229/5e696293/attachment.html>