[Development] QCommandLineParser

[Saether Jan-Arve]

Hi.
Although this is not necessary for 5.2, I have two feature requests:


1. Have support for "response files", (or @option-file as the moc patch calls it).

People shouldn't have to implement that for every tool that needs it, and all Qt based apps that needs response files should use_the_same_syntax.



2. Standardize value lists so that they work across shells
   
I.e. this doesn't work in all shells:

./init-repository --module-subset=qtbase,qtsvg

Problem is that comma is an argument separator in MS Powershell, the result is that Powershell will effectively call the process with two arguments:
   
./init-repository --module-subset=qtbase qtsvg

It would be great if QCommandLineParser could help people not to shoot themselves in the foot if they want to accept a list of values.


Jan-Arve

> -----Original Message-----
> From: development-bounces+jan-arve.saether=digia.com at qt-project.org
> [mailto:development-bounces+jan-arve.saether=digia.com at qt-project.org]
> On Behalf Of David Faure
> Sent: 29. juli 2013 20:39
> To: development at qt-project.org
> Subject: [Development] QCommandLineParser
> QCommandLineParser, which I intend to get into Qt 5.2, could use some
> more reviewing, and especially a +2 at some point :-)
> 
> https://codereview.qt-project.org/58979 is the all-in-one commit for
> easier review.
> 
> It includes https://codereview.qt-project.org/61746 which is
> specifically about the 3 parsing modes for "-abc" (option collapsing,
> implicitly long, or compiler mode). Discussion ongoing about Windows,
> maybe we don't need "/a"
> support at all, just "-"/"--" everywhere?
> 
> On top of this, I ported some tools to it :
> 
> https://codereview.qt-project.org/61079 ports uic.
> 
> https://codereview.qt-project.org/61660 ports moc (which was the cause
> for the "compiler mode" in 61746).
> 
> I also ported all of KDE Frameworks 5's executables.
> 
>> From my point of view it's all ready to go in, as soon as the
>> discussion in
> 61746 is resolved.
> 
> There's one issue though, which Oswald raised: what if we want to use
> the parser for the internal parsing in qapp (which means
> QCoreApplication+QGuiApplication+QApplication)? This was initially my
> idea, but I discarded it because translations are not typically set up
> when entering the qapp constructors, apps typically do this later, and
> QCommandLineParser::addOption requires translated strings (I'm very much
> opposed to using QT_TRANSLATE_NOOP everywhere for this, after the
> KCmdLineArgs experience).
> 
> So my idea was simply to have a --help-qt option which would delegate to
> qapp the adding of options for documentation purposes only, and not
> touching the builtin parsing at all. Now Oswald suggests that apps
> *could* set up QLocale and QTranslator before instanciating qapp, and
> therefore qapp could create a QCommandLineParser instance and feed its
> options into it, and use it for parsing. Not sure how much this can
> really work, Thiago always says Qt APIs shouldn't be used before the
> QCoreApp ctor (e.g. no local8Bit etc.). So it sounds a bit too
> experimental to me. This would also need some way to not pollute the
> main -- help output though, i.e. marking these options as belonging to
> --help-qt. Overall I'm afraid that this makes things more complex and
> more intrusive. API wise we'd have to reintroduce some
> QCoreApplication::commandLineParser() accessor so that the application
> adds its own options to the same parser. Which means it can't be done
> later, because it would mean porting every main() function from creating
> its own parser to reusing the one from qcoreapp.
> 
> So after more thinking, here's my suggestion:
> * we keep the idea that every main() creates a parser on the stack.
> The current change request can go in (after more reviewing).
> * later if we want to use QCommandLineParser for the builtin qapp
> options, qcoreapp would create its own *separate* instance, and
> register it internally in qcoreapp (not public, unlike the previous
> idea). And the magic is that every parser instance would have a
> --help- qt option, which delegates to the qcoreapp-owned instance to
> print out the builtin options.
> So, this needs no new API either to mark these options as the ones for
> --help- qt, they are already separated in a different internal-only
> parser, not mixed with the application options.
> 
> By the time we want to create a command-line parser internally in
> QCoreApp, we can sort out the translation setup -- possibly like in
> KDE where the translators got automatically loaded from standard
> paths, which means tr() can be used inside the qapp constructors.
>