Review Request 113830: Allow unique apps to access command-line arguments of later invocations

[David Faure]

On Friday 22 November 2013 11:05:16 Alex Merry wrote:
> On 22/11/13 10:32, David Faure wrote:
> > On Wednesday 13 November 2013 17:34:45 Alex Merry wrote:
> >> Of course, if we wanted to support Ryan's use cases (like text editor use
> >> by git), thing's get a little more complicated.
> >> 
> >> He basically suggests the route of standardising application arguments,
> >> AFAICS, but even without that, I think he's right about wanting to pass
> >> the
> >> current working directory, and possibly also the environment.
> > 
> > Yes please add the working directory, that one is very much needed.
> 
> I can't do anything until next week, so I'm inclined to leave this until
> Kevin has done the splitting.  But it's easy enough to add an extra
> argument.

Sure, no rush.

> > Which reminds me that we don't have a replacement for KCmdLineArgs::url(i)
> > instead, i.e. a method that resolves "an absolute filename, a relative
> > filename (given a CWD), or a URL" into a QUrl, for nvenience. Many (kio-
> > based) apps need that. It doesn't have to be part of QCommandLineParser
> > though... maybe a QUrl::fromUserInput(string, cwd), but the need to call
> > QFile::exists() in there sounds like a bad location for it... I'm open to
> > suggestions :)
> > 
> > For apps that don't support URLs, something like QDir(cwd).filePath(str)
> > is
> > enough.
> 
> If it's going to go in Qt, a static method on QProcess or
> QProcessEnvironment might be logical?  Since it's dealing with relative
> paths.

This sounds strange to me. QProcess is for starting other apps, while I'm 
talking about the main()   (and the slotActivated(), which is the only 
relation to this review request)   parsing command-line arguments in the app 
being started/activated.

QDir also deals with relative paths.
It's just that neither one deals with URLs.

I guess I'll get Thiago's opinion on this.
 
> > To come back to the "text editor should exit once done editing", that
> > sounds like a use case for DBus transactions, on the "receiving" side.
> > i.e. calling setExitValue() would be mandatory, and would terminate the
> > dbus call, and it wouldn't have to be called synchronously.
> > OTOH I don't see this as a huge priority; one can just use kwrite instead
> > of kate as the text editor, in practice :)
> 
> There's some complexity in this one.  While it's easy enough to add a
> flag to enable this behaviour, there needs to be some "transaction id"
> passed to the slot, to cope with multiple overlapping instances - just
> which duplicate instance are you intending to terminate?  And adding
> arguments to signals breaks BC.

Ah, sorry I used the wrong terminology. DCOP had transactions (yeah I'm old), 
QDBus has "delayed replies", cf QDBusMessage::setDelayedReply(true) + 
createReply.

You're right, it means the signal would need to contain the QDBusMessage 
argument.

Well, that could make things even more flexible: the app itself could choose 
to call setDelayedReply or not.

> OTOH, maybe those few apps that would find this useful should be cooking
> their own solution.

Sure, but KDBusService needs to provide them with the hooks for that (we don't 
want a complete fork of it).

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