> 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
