> On Nov. 15, 2014, 2:43 p.m., Thomas Lübking wrote: > > kdeui/windowmanagement/kwindowsystem_mac.cpp, line 556 > > <https://git.reviewboard.kde.org/r/120931/diff/2/?file=328516#file328516line556> > > > > Does this *really* 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. > > > > 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. > > René J.V. Bertin wrote: > 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. > > 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? > > Thomas Lübking wrote: > 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) > > > 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(); > > m_DebugClient could be set in a header inline, depending on whether > QT_DEBUG is defined (or QT_NO_DEBUG is not defined) > > René J.V. Bertin wrote: > 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. > > 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. > > Thomas Lübking wrote: > 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? > > René J.V. Bertin wrote: > Growl is a notification framework, and indeed it doesn't seem it can do > anything else but sending messages and displaying them. > > But I've spoken a little bit too soon. There *is* 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 *can* 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 `NSWindow*` on OS > X, but from what I've seen this is no (no longer) correct. > > René J.V. Bertin wrote: > I've had a look at using distributed objects in ObjC. That could be the > solution we're looking for, given certain conditions: > > - 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). > - 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) > - 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. > > 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. > > Sounds like a fun little project to get right, but somehow I doubt it > stands much chance to be accepted for KDE4. > > And my main question remains: just how many applications try to do things > with windows that are not their own? > > Martin Gräßlin wrote: > > And my main question remains: just how many applications try to do > things with windows that are not their own? > > That is the main purpose of KWindowSystem. For doing things with your own > window one wouldn't need KWindowSystem, but could just QWidget/QWindow.
@René: Do the results of http://lxr.kde.org/ident?_i=KWindowSystem&_remember=1 mean anything to you? - Ian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120931/#review70399 ----------------------------------------------------------- On Nov. 14, 2014, 11:04 p.m., René J.V. Bertin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120931/ > ----------------------------------------------------------- > > (Updated Nov. 14, 2014, 11:04 p.m.) > > > Review request for KDE Software on Mac OS X and kdelibs. > > > Repository: kdelibs > > > Description > ------- > > This is an attempt to improve the Mac-specific implementation of the > `KWindowSystem` class. > For convenience and future-proofness (and also because I like the language) I > converted `kwindowsystem_mac.cpp` to ObjC++, i.e. `kwindowsystem_mac.mm`, and > added the AppKit framework in the CMakeFile. > > 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. > > I should probably update the "not yet implemented" debug statements (to > "unsupported"), and I might have another look at kwindowinfo_mac.cpp too. > > > Diffs > ----- > > kdeui/CMakeLists.txt 1454790 > kdeui/tests/kwindowtest.cpp b4012d7 > kdeui/windowmanagement/kwindowsystem_mac.cpp 4200237 > kdeui/windowmanagement/kwindowsystem_mac_p.h PRE-CREATION > kdeui/windowmanagement/kwindowsystem_macobjc.mm PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/120931/diff/ > > > Testing > ------- > > 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. > > > Thanks, > > René J.V. Bertin > >
