[Development] QCommandLineParser

[Andreas Aardal Hanssen]

I can't help getting the feeling that the community is about to make the
same mistake again regarding command line parsing in Qt.

My $0.02 is to make something that's ridiculously simple, or cancel the
whole project. We already have other options for complex cases. Qt apps
traditionally don't take complex arguments and they really shouldn't.
Simple -foo blah is enough, and it works the same way on all platforms.
Please don't overengineer this parser. Don't make platform specifics like
'/' on Windows and '--foo=blah' on Unix. Remember that most folks just make
a for loop to check arguments, i.e., if (arguments.at(i) == "-fullscreen")
{ fullScreen = true; }. The Qt API must be simpler than this, and it's
really hard to get there if this class is to support all kinds of crap.

Gad'dam.. ;-)

Andreas...



2013/7/30 Saether Jan-Arve <Jan-Arve.Saether at digia.com>

> 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.
> >
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
Andreas Aardal Hanssen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130730/eabb52bf/attachment.html>