[Development] QCommandLineParser

[David Faure]

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.

-- 
David Faure | david.faure at kdab.com | Managing Director KDAB France
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions