Review Request 112443: Native event filter porting for KModifierKeyInfoProvider

[Martin Gräßlin]

> On Sept. 23, 2013, 12:07 p.m., Kevin Ottens wrote:
> > Tested the patch in my tree, works for caps lock too.
> > 
> > Now it highlights a dependency problem... We don't want a dependency on QX11Extras from KGuiAddons. So maybe we should move KModifierKeyInfo to your proposed KX11Extras?
> 
> Martin Gräßlin wrote:
>     Then I would suggest to move this class to KWindowSystem for the moment. For the module KX11Extras I still need some code changes first (for some reason netwm is using KWindowSystem - it's wrong IMHO and needs fixing)
> 
> Kevin Ottens wrote:
>     Well, if you remember it was my first choice to put KModifierKeyInfo in KWindowSystem, but you pushed back. :-)
>     
>     I'm ok if you move it there then, looking forward to the patches. ;-)
> 
> David Faure wrote:
>     You know, if the dependency on QX11Extras is only for QX11Info::display(), that's really easy to write "by hand" in kmodifierkeyinfo_x11.cpp
>     (see the 5 lines in QX11Info::display).
>     Although I suspect after porting to XCB it would rather be about QX11Info::connection(), same thing though (accessible via QPlatformNativeInterface).
>     QX11Info mostly exists for Qt4 source compat and for convenience, it's not mandatory to go through it.
>     
>     I'm not convinced about this going to KWindowSystem.
>     
>     An application developer who would want to display a "Caps Lock" indicator in the statusbar of his wordprocessor (say kile, which does exactly this) would first look at Qt, then notice you can't query it for the status of CapsLock, and would then look at kguiaddons and find it. But why would they look into KWindowSystem for this? This has nothing to do with window management. It's a key handling feature, complementing what's in QtGui.
>     I certainly expect it to be implemented on Windows and/or Mac at some point in the future, it definitely makes sense there too (unlike, say, NETWM).

Ok, I can see how to get away from QX11Extras, but Kevin also complained about XLib and XCB. And I do not see how I can interact with X11 without using either of those two. So either I'm allowed to use X-specific code in this module or the code cannot go into this module.


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112443/#review40510
-----------------------------------------------------------


On Sept. 4, 2013, 8:37 a.m., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112443/
> -----------------------------------------------------------
> 
> (Updated Sept. 4, 2013, 8:37 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> -------
> 
> Ported to native event filter and to xcb-xkb by reimplementing the events. Most parts are kept on xlib though as we don't have xkb.h to get proper defines.
> 
> 
> Diffs
> -----
> 
>   tier1/kguiaddons/CMakeLists.txt 3124c4d 
>   tier1/kguiaddons/src/lib/CMakeLists.txt dc6aafa 
>   tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_dummy.cpp 7913d29 
>   tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_p.h ee8e82e 
>   tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_x11.cpp 2f28d41 
> 
> Diff: http://git.reviewboard.kde.org/r/112443/diff/
> 
> 
> Testing
> -------
> 
> used kmodifierkeyinfotest application. Would appreciate if someone else could run it as I don't have a caps lock.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130930/69bc5d06/attachment.html>