Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

Fri Feb 26 16:23:28 UTC 2016

> On Feb. 25, 2016, 8:26 a.m., Martin Gräßlin wrote:
> > I don't like the introduction of the SCRAPBOOK. The repository is not the place for dead and old code. That's what git already supports with keeping the whole history.
> > 
> > We have some autotests for kwindowsystem. Could you try whether the tests work also on OSX?
> 
> René J.V. Bertin wrote:
>     I agree to a certain extent. Git's history feature isn't exactly comparable to a history book in which you can go look around to see if at some point maybe someone contributed some code that was never finished. At the very least you'd need to leave comments in the code that "here used to be some junk DNA that maybe could have led to a whole better world" (and in that case, why not just leave in the code #ifdeffed-out ...)
>     
>     As to the autotests: they're built only when `X11_FOUND`. Are you in fact asking me to port them?
> 
> Martin Gräßlin wrote:
>     > At the very least you'd need to leave comments in the code that "here used to be some junk DNA that maybe could have led to a whole better world" (and in that case, why not just leave in the code #ifdeffed-out ...)
>     
>     eh no, we are not StarOffice. We have a version control system. No need to reference old code.
>     
>     > they're built only when X11_FOUND. Are you in fact asking me to port them?
>     
>     No, of course not. There are some which might not be X11 specific. E.g. kwindowsystem_threadtest.cpp. It would be good to know which ones can work on OSX
> 
> René J.V. Bertin wrote:
>     I'll see for the autotests.
>     
>     My point is that you cannot expect that a future developer will study the old commit diffs to check if maybe they contained latent/experimental code that implemented an idea s/he was planning to test.
>     The experimental code I've moved is exactly of that nature; it aimed to implement a mechanism by which a table would be maintained of all windows belonging to all running applications. You pointed out correctly that it wouldn't compile and on my end I am not sure whether such a feature would actually be useful (never got feedback on the question I asked about that). So yeah, when the idea of cleaning out inactive code came up and you didn't seem adverse to the idea of keeping code snippets in another place for future reference I came up with the SCRAPBOOK idea.
>     Apparently I should have left in the code until I got the green light, and then remove it in an additional commit that does only that, with a sufficiently detailed commit message that the revision history could actually be of some real help here. I can't say I feel like moving all that code back to where it came from, so if you don't want the SCRAPBOOK file I guess it'll just do down the drain.

Re: kwindowsystem_threadtest : that's the only one that doesn't require rewriting outside of the autotests CMake file. And it confirms a fear I had: there currently is no such thing as an internal list of owned windows, despite some efforts to maintain internal structures that allow to return something useful in certain situations (that I'll really need to look into again).
Maintaining such a list of windows feels a bit like a chicken-and-egg problem; can I rely on a Qt signal or do I need to use a lower-level API. The fact that most Qt/KDE applications do not have a Window menu like most Cocoa applications do (https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/WinPanel/Tasks/UsingWindowsMenu.html) may be an indication that Qt does something peculiar.

Anyway, supposing I'm going to sit down and try to come up with a mechanism to maintain a list of the running app's open windows (`WId`s). Can I presume that the list will be created (= plugin loaded) when there are no windows yet, meaning I only have to listen to window creation events? Or will I need to fetch the current list, add that, and then listen for window open events? I know how to go from a `WId` to the underlying Cocoa instance, but the other way round may be quite a bit more tricky.

- René J.V.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126291/#review92753
-----------------------------------------------------------

On Feb. 23, 2016, 10:54 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 Feb. 23, 2016, 10:54 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
> -----
> 
>   src/debug_p.h 5ef8996 
>   src/debug_p.cpp 72abfb7 
>   src/kwindowsystem.cpp 407a67d 
>   src/platforms/osx/CMakeLists.txt 4fc3347 
>   src/platforms/osx/SCRAPBOOK PRE-CREATION 
>   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
> 
>

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