On Tuesday January 05 2016 12:55:57 David Faure wrote: >No worries, we're both evolving our thoughts as the discussion progresses.
Slowly but (I think) surely :) Feedback on the Qt ML thread is inclining me to design an initial proof of concept implementation extending KProcess, probably even via a new KProcess::launchGUIApplication() rather than using a (optional) flag to an existing method. Here's a relevant tidbit from SO: http://stackoverflow.com/questions/27303359/lsopenapplication-deprecated Considering the remarks about arguments passing, I think we may want to provide two argument lists to this new method: documents to be opened, and other commandline arguments. As argued in the SO post, commandline arguments only make sense when starting an application instance, while a list of documents to be opened is something that can also be sent to an already running application. Splitting up these argument types has another benefit: rather than handing all arguments off at once we can wait for the "app is ready" event to send the request. This doesn't make a difference for "native" applications, but I have some experience with Qt's way of relaying these requests (as QFileOpenEvents) to KF5 applications that suggests that it might be better to provoke these events only once the app is up and running. This would also suggest a potential use for a (non static) ::openFile()/openFiles() method to target a specific instance. Is there a standard DBus request to ask an application to open a file (as opposed to each application provides its own, without worrying about a common call interface)? If there is, a flag could be provided to prefer the DBus interface over the native mechanism. Feedback welcome! R. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
