[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: closest equivalent to KApplicationPrivate::init() ?
From:       David Faure <faure () kde ! org>
Date:       2016-01-02 16:14:07
Message-ID: 51858741.3vlaEbT8JZ () asterix
[Download RAW message or body]

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@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


[prev in list] [next in list] [prev in thread] [next in thread]