closest equivalent to KApplicationPrivate::init() ?

[René J.V. Bertin]

On Saturday January 02 2016 17:14:07 David Faure wrote:

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

OK, hard *empirical* data (though that 2nd sentence reads like a very qualitative and subjective version ;) )

Anyway, I'll be gathering that kind of data from now on.

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

My recent experience allows me to be pretty damn sure that it indeed lets the application stay in the background.

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

You saw I said "wait for QProcess to be improved", right? I don't expect a patch for QProcess to be incorporated before 5.7.x ...

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

Ah, right. I missed that indeed.

> to start apps (anywhere QProcess is used) to work correctly anyway. So why not use QProcess everywhere?

Ok, so what about the requirements on QProcess? Anything beyond what's possible with QProcess::startDetached and possibly launch confirmation? Should QProcess figure out transparently (or rather, opaquely :)) whether to use LaunchServices or not, or should the developer be given a way to override it, or even switch to switch to LaunchServices rather than using standard Posix APIs?

R