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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
