On Saturday January 02 2016 14:14:19 David Faure wrote: >Sounds to me like you're saying "better bring all apps to front than none".
Yes, but also that I think that practice should be more subtle than that if we manage to use LaunchServices consistently where it's appropriate. Disregarding of course the fact that the QCocoaIntegration ctor calls the same AppKit function that my KWindowSystem helper function uses, if QT_MAC_DISABLE_FOREGROUND_APPLICATION_TRANSFORM isn't set, Which may or may not be enough, I do not yet have sufficient data on that. But not that if that bit of code does what it seems to be doing, Qt5 applications are indeed always opened in front, and the cases I'm seeing where this isn't the case correspond in fact to GUIs posted by applications that were already running. >Maybe, maybe not, but what we need to continue this discussion is hard data. >1) what does QProcess on Mac do (always in front, always in background, >depends on whether the user is typing) You're probably better aware (or able to understand) than I exactly what QProcess does behind the scenes. I can affirm that it is basically common knowledge that native GUI applications that are started via a call from the exec() family or through system() will open in the layer behind the one occupied by the parent process. I don't think the data will get any harder than that, unless we get our hands on the sources of the relevant SDKs. >2) can QProcess be improved It should be possible, as long as there are no hard feature requirements that are incompatible with the use of LaunchServices. >3) can we use QProcess from KF5 instead of kdeinit (because, again, kdeinit's >only purpose is fork+exec >which is apparently not a good solution on Mac). I'm pretty sure the answer to >this one is yes. Yes, but I'm not sure there is an advantage to using QProcess if you only use it to "detach" a new application with which you're not keeping any ties. I don't think QProcess allows much more than that, other than stopping and killing the spawned application (but I should check again). If that's all true, I don't see why we would wait for a hypothetical QProcess improvement, instead of using a native API directly, at least for GUI applications that live in app bundles. IOW, if a launch request comes in for "foo.app" or "/path/to/foo.app" or "/path/to/foo.app/Contents/MacOS/foo-bundle-exec", use the LaunchServices SDK to start "foo.app" with whatever arguments have to be passed in. Otherwise, use QProcess (indeed, why not). The biggest hurdle to using native SDKs (coding in ObjC) has already been taken, after all. >E.g. if you set bool useKToolInvocation to false in krun.cpp:724, you'll get >into the code path that uses QProcess. >(which btw shows another reason to ensure QProcess works: kdeinit isn't even >always used, even on Linux, >see the conditional for useKToolInvocation). Yeah, klaunch does that too (or something similar), I noticed. OTOH, if we streamline kinit_mac.mm so that its launch() function does something like what I outlined above, why would we stick with useKToolInvocation=false. At the least we could put the native code in a common code file that's included by kdeinit and klaunch and family, if we want to avoid the overhead of relaying a launch request via kdeinit. In fact, someone else already asked if there's any point in maintaining kdeinit on a platform where it's main function (caching shared libraries) is moot. Is there? R. > > _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
