> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote: > > src/platforms/osx/kwindowsystem_macobjc.mm, line 89 > > <https://git.reviewboard.kde.org/r/126291/diff/2/?file=444312#file444312line89> > > > > Why is the define needed? Doesn't it make more sense to just not build > > the OSX backend if COCOA is disabled? > > René J.V. Bertin wrote: > That would require knowing the answer to that question in the CMake file; > I'd have to look into that. Is it trivial to do the equivalent of an `#ifdef > TOKEN` in a CMake file? > > Martin Gräßlin wrote: > That should be defined in the cmake config for Qt5Gui. At least where I > needed similar things in the past it was defined. > > René J.V. Bertin wrote: > I cannot find any variable/flag that indicates against what SDK Qt has > been built, sadly.
Still impossible to determine this from the information provided with Qt 5.6.1 . I think the likelihood that QT_MAC_USE_COCOA is ever not set is extremely small nowadays, so if you want I can just drop the check completely. - René J.V. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126291/#review92378 ----------------------------------------------------------- On March 4, 2016, 8:19 p.m., René J.V. Bertin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126291/ > ----------------------------------------------------------- > > (Updated March 4, 2016, 8:19 p.m.) > > > Review request for KDE Software on Mac OS X and KDE Frameworks. > > > Repository: kwindowsystem > > > Description > ------- > > KWindowSystem has been lacking a platform plugin for OS X. This RR presents a > "backport" of the modified KDE4 KWindowSystem implementation that has been > used in the MacPorts kdelibs4 port for the last 2 or 3 (or more) years. > > I have made some initial steps to remove deprecated Carbon API calls, but > this is clearly a work in progress. > > Open questions include > - is there any justification to run an event handler (or Cocoa observer) to > keep track of running applications, possibly even listing all their open > windows? > - is there any use for the Qt event listener framework (cf. the > NETEventFilter in the X11 plugin)? I haven't yet had time to try to figure > out what this "could be good for", and am very open to suggestions in this > departments. > - one application for such an event filter would be a listener that catches > the opening and closing of all windows by the running process, and keeps > track of their `WId`s. A new method could then be added (to `KWindowInfo`?) > to distinguish `WId`s created by the running application from "foreign" ones > (useful also on Wayland and MS Windows). > > `KWindowSystem::setMainWindow` should become a front for payload provided by > the plugins. I'll leave that to the regular/official maintainer(s) of this > framework. > > This code could probably do with *lots* of comments; I'll try to add them as > questions about this or that bit of code arise. > > > Diffs > ----- > > autotests/CMakeLists.txt 65ed8d4 > autotests/kwindowsystem_threadtest.cpp a142bae > src/debug_p.h 5ef8996 > src/debug_p.cpp 72abfb7 > src/kwindowsystem.cpp 407a67d > src/platforms/osx/CMakeLists.txt 4fc3347 > src/platforms/osx/cocoa.json PRE-CREATION > src/platforms/osx/kkeyserver.cpp 3ddb921 > src/platforms/osx/kwindowinfo.cpp e8555bb > src/platforms/osx/kwindowinfo.mm PRE-CREATION > src/platforms/osx/kwindowinfo_mac_p.h c8f307e > src/platforms/osx/kwindowinfo_p_cocoa.h PRE-CREATION > src/platforms/osx/kwindowsystem.cpp 1758829 > src/platforms/osx/kwindowsystem_mac_p.h PRE-CREATION > src/platforms/osx/kwindowsystem_macobjc.mm PRE-CREATION > src/platforms/osx/kwindowsystem_p_cocoa.h PRE-CREATION > src/platforms/osx/plugin.h PRE-CREATION > src/platforms/osx/plugin.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/126291/diff/ > > > Testing > ------- > > On OS X 10.9.5 with Qt 5.5.1 and frameworks 5.16.0 . > > > Thanks, > > René J.V. Bertin > >
