closest equivalent to KApplicationPrivate::init() ?

[David Faure]

On Saturday 02 January 2016 15:59:04 René J.V. Bertin wrote:
> On Saturday January 02 2016 14:14:19 David Faure wrote:
> >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.

While I like the general approach of reading source code, what I meant here was *testing*.
If it behaves like you want it to behave, that's perfect, no need to understand every line of its code to assess that.

> >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). 

Sounds right, for QProcess::startDetached()  (no stdin/stdout/stderr). But the question is, how does it behave in terms
of bringing the new app to the background or foreground.

> 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.

I very much disagree with this approach. Qt is opensource, if there's something to be fixed in QProcess, make a patch,
then it won't be hypothetical. I don't see "starting a GUI application" as a KF5-specific need at 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.

You missed my point. Whatever you do to kdeinit, when KRun uses the "useKToolInvocation==false" code path,
then QProcess will be used anyway, so you have an interest in making that work correctly.

As the boolean condition says, this is the case when tempFiles==true (the app is responsible for deleting the file after use)
or when runService is called with a "fake" KService (created by code, not in ksycoca)
or when suggestedFileName is set (comes from HTTP content-disposition).

But QProcess is used in many other places too (e.g. dropjob when dropping a file onto an exe in a filemanager).

> 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?

For starting apps, no, there isn't, that's what I keep telling you

The other use of kdeinit, starting kioslaves in a way that they can be passed from a process to another,
still remains. Therefore my recommendation is: don't kill kdeinit, keep it for kioslaves, but you don't need
it to start apps. Hence my suggestion of useKToolInvocation=false in krun.cpp, and the few other places that
use ktoolinvocation (to talk to klauncher, to talk to kdeinit).

The alternative is indeed to implement app launching in klauncher itself, but you still need the other ways
to start apps (anywhere QProcess is used) to work correctly anyway. So why not use QProcess everywhere?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5