<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/120931/">https://git.reviewboard.kde.org/r/120931/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On November 15th, 2014, 3:43 p.m. CET, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
<thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
<a href="https://git.reviewboard.kde.org/r/120931/diff/2/?file=328516#file328516line556" style="color: black; font-weight: bold; text-decoration: underline;">kdeui/windowmanagement/kwindowsystem_mac.cpp</a>
<span style="font-weight: normal;">
(Diff revision 2)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">void KWindowSystem::setIcons( WId win, const QPixmap& icon, const QPixmap& miniIcon )</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">502</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "> <span class="n">w</span><span class="o">-></span><span class="n">raise</span><span class="p">();</span></pre></td>
</tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Does this <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">really</em> cut it on OSX?
The function is not supposed to be an extra superfluous wrapper around QWidget, but typically used to control windows IN ANOTHER PROCESS.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">This raises the question whether that's possible on OSX at all.
If not, testing for an in-process window (search toplevels only?) is ok, but the failure should cause a big fat warning to the developer that this code isn't portable.</p></pre>
</blockquote>
<p>On November 15th, 2014, 4:37 p.m. CET, <b>René J.V. Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">It works for in-process windows, obviously, but no it won't work for windows from another process. I highly doubt that one could meddle with those, and as I must have written in the comments somewhere, you cannot convert the WId to a pointer to an actual window object if it's not owned by ourselves.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">What exactly are you proposing concerning that big fat warning?
Do you know of code that uses this kind of functionality cross-process, apart from kwin and maybe a couple of goodies that aren't relevent outside of a Plasma workspace?</p></pre>
</blockquote>
<p>On November 15th, 2014, 9:41 p.m. CET, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Well, how does the OSX docker etc. raise/activate a window?
Does this imply that activating won't work either for other PID windows? (The comments actually seem to suggest so)
In case: why mess with the cocoa API itfp? You could just as well wrap around Qt (w/ a //TODO or similar)</p>
<blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">What exactly are you proposing concerning that big fat warning?
qWarning("BlahFooBar does not work on OSX, please fix your stuff");
if (m_DebugClient)
abort();</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">m_DebugClient could be set in a header inline, depending on whether QT_DEBUG is defined (or QT_NO_DEBUG is not defined)</p></pre>
</blockquote>
<p>On November 15th, 2014, 9:53 p.m. CET, <b>René J.V. Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">The OS X Dock is a case apart. It's system software, and probably interacts with the window manager.
But I should rephrase, maybe: "it won't work" means there's no documented way to achieve raising and the like across process boundaries. As long as you don't want to or cannot use AppleScript, and in this case we cannot because we cannot use the WId.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I do think that the Cocoa API gives a bit more functionality than wrapping Qt calls would, but I can have another look at that.</p></pre>
</blockquote>
<p>On November 15th, 2014, 11:38 p.m. CET, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Are you or another OS_X hacker maybe in touch with more regular Cocoa API devs (forum, mailing list personal contact)?
I find it hard to believe that there's no access to windows on Cocoa (but on apple script) - wouldn't eg growl allow you to activate the sender window?</p></pre>
</blockquote>
<p>On November 16th, 2014, 12:30 a.m. CET, <b>René J.V. Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Growl is a notification framework, and indeed it doesn't seem it can do anything else but sending messages and displaying them.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">But I've spoken a little bit too soon. There <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">is</em> actually a potential way to tell another application to raise a specific window. In ObjC, invoking a class instance's member function is called sending a message to that instance ... and those messages <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">can</em> be used for IPC. See http://stackoverflow.com/questions/7448068/in-cocoa-or-generally-in-objective-c-is-there-a-way-to-send-a-message-to-objec . It's a feature I've never used so I tend to forget about it, and the question remains if we can actually use this without a substantial rewrite. And the big question remains: how to glean the required information from a WId. The documentation suggests that a WId is actually an <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">NSWindow*</code> on OS X, but from what I've seen this is no (no longer) correct.</p></pre>
</blockquote>
<p>On November 16th, 2014, 10:32 a.m. CET, <b>René J.V. Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I've had a look at using distributed objects in ObjC. That could be the solution we're looking for, given certain conditions:</p>
<ul style="padding: 0;text-rendering: inherit;margin: 0 0 0 1em;line-height: inherit;white-space: normal;">
<li style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">WId values must be unique across processes during a session and not potentially identical in multiple processes at the same time like they could be if they are pointers (like the documentation suggests). </li>
<li style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">Because the KWindowSystem API only provides a WId to work on, we can only check the system for published distributed objects registered under, for instance, the hex. representation of that WId (which is why they must be unique)</li>
<li style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">As a consequence, each time a window is opened we must create a dedicated NSConnection object registered with the WId's representation, so KDE's windowing layer must be adapted to do that. I don't know yet whether this is actually possible, nor how large an overhead this would introduce.</li>
</ul>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">A more elegant (?) solution would create a single NSConnection object for some kind of application interface that can respond to queries like [give me the NSWindow* for this WId] and register that through kded. And of course kded would need to have a reverse interface to a dictionary mapping WIds to registered applications because of point 2 above.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Sounds like a fun little project to get right, but somehow I doubt it stands much chance to be accepted for KDE4.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">And my main question remains: just how many applications try to do things with windows that are not their own?</p></pre>
</blockquote>
<p>On November 16th, 2014, 10:55 a.m. CET, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">And my main question remains: just how many applications try to do things with windows that are not their own?</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">That is the main purpose of KWindowSystem. For doing things with your own window one wouldn't need KWindowSystem, but could just QWidget/QWindow.</p></pre>
</blockquote>
<p>On November 16th, 2014, 12:01 p.m. CET, <b>Ian Wadham</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">@René: Do the results of http://lxr.kde.org/ident?_i=KWindowSystem&_remember=1 mean anything to you?</p></pre>
</blockquote>
<p>On November 16th, 2014, 12:36 p.m. CET, <b>René J.V. Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Hi Ian,</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Interesting, I wasn't aware of that site. Yes, the result mean something to me - you have probably heard of digiKam too for instance. What this doesn't answer without going over all those hits is to what extent the KWindowSystem calls are actually used to control windows from other applications. I'm pretty sure digiKam doesn't, for instance.
I think it's relatively safe to say that we'd have noticed where window level control was missing - we sure did for DrKonqi and KWalletd ...</p></pre>
</blockquote>
<p>On November 16th, 2014, 1:22 p.m. CET, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Looking across some files:
largely virtual desktop assignment, setting window types not (been) supported by Qt, forcing to be the active window, obtain KWindowInfo on oneself.
Amarok at least once checks whether it is the active window (winId() != KWindowSystem::activeWindow())</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Indeed there's a lot of "abuse" here, where kwindowsystem is invoked w/o any need.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">@Martin, do you think it would make sense to add an (preproc controlled) mechanism where one does "export AM_I_ABUSING_KWINDOWSYSTEM=1" what would lead to an abort if one operates on a local window and to control sth. that QWindow just provides as well?</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Could be a macro:
WARN_ON_ABUSE("Use QWindow::requestActivate() or QWidget::activateWindow() instead")</p></pre>
</blockquote>
<p>On November 17th, 2014, 1:33 a.m. CET, <b>Ian Wadham</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I see too that KMessageBox and KFileDialog have "*WId" variants of their main methods --- with warnings to use them only when "necessary". FWIW KMessageBox implements its "normal" methods (based on parent-widgets) by finding the parent's WId and then calling the *WId variant "to avoid code duplication" (see line 444 of kmessagebox.cpp).</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Also there is a strong warning in http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKWindowSystem.html#a7a04fd62d97ed3104e02bfa3ffa19ad5, "Detailed Description" section, about using this class on OS X. Otherwise I am baffled by all this low-level access to the window system. Even KWordQuiz in KDE Edu has an instance of it.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Maybe René should just ban "applications doing things with windows that are not their own" on OS X and see if anything breaks...</p></pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I missed that doc bit about the WIds returned by KWindowSystem. I'm not sure why that asymmetry would be there, and wonder when the warning was written. It could be true though: where Qt's documentation states that a WId is just a cast <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">NSWindow*</code>, in reality it's either a <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">QCocoaWindow*</code> (which inherits NSWindow) or a <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">QCocoaView*</code> (which inherits NSView, a superclass containing an NSWindow member). Obviously it won't work to give Qt a "NSWindow WId" for a widget that uses a "NSView WId".
Something to look into for sure.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">In any case, this limitation applies to all windows (or should I say, widgets...), including those owned by the application.</p></pre>
<br />
<p>- René J.V.</p>
<br />
<p>On November 15th, 2014, 12:04 a.m. CET, René J.V. Bertin wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: 1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
<div>Review request for KDE Software on Mac OS X and kdelibs.</div>
<div>By René J.V. Bertin.</div>
<p style="color: grey;"><i>Updated Nov. 15, 2014, 12:04 a.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kdelibs
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">This is an attempt to improve the Mac-specific implementation of the <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">KWindowSystem</code> class.
For convenience and future-proofness (and also because I like the language) I converted <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">kwindowsystem_mac.cpp</code> to ObjC++, i.e. <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">kwindowsystem_mac.mm</code>, and added the AppKit framework in the CMakeFile.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Much of the code in this file is hardly better than gentle hacking, but that probably concerns the functions that are of least interest on a platform where KDE doesn't do session management.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I should probably update the "not yet implemented" debug statements (to "unsupported"), and I might have another look at kwindowinfo_mac.cpp too.</p></pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">On OS X 10.6.8, mostly with the updated kwindowtest utility (which calls KWindowSystem functions when clicking the Open button in its toolbar).
Also tested on Mac OS X 10.9.4 rebuilding kdelibs from scratch.</p></pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>kdeui/CMakeLists.txt <span style="color: grey">(1454790)</span></li>
<li>kdeui/tests/kwindowtest.cpp <span style="color: grey">(b4012d7)</span></li>
<li>kdeui/windowmanagement/kwindowsystem_mac.cpp <span style="color: grey">(4200237)</span></li>
<li>kdeui/windowmanagement/kwindowsystem_mac_p.h <span style="color: grey">(PRE-CREATION)</span></li>
<li>kdeui/windowmanagement/kwindowsystem_macobjc.mm <span style="color: grey">(PRE-CREATION)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/120931/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>