[Development] Qt Playground - Command Line Parser experiment

[David Faure]

On Monday 12 March 2012 20:06:22 marius.storm-olsen at nokia.com wrote:
> a) The parser is too trivial and doesn't handle the normal levels of 
> complexity of command line arguments out there. (tar, find, zip, and 
> standard Qt (built-in) arguments anyone?)

Who needs to reimplement tar, zip, or find in Qt? These programs have a weird 
notion of command-line argument handling, but I don't see the need for Qt to 
provide this. If it had something much more standard, it would already be 
useful for 99%, no, 100%, of the Qt applications out there.

> b) The parser is too complex, where it doesn't live up to the simplicity 
> expected from Qt API and usage.

It's not such an insurmountable task. After all, libc has getopt, Qt has many 
complex things, surely Qt can implement some sort of getopt without resulting 
in "too complex" code.

> c) The parser only focuses on the "standard" for a single platform. 
> (Linux users will not go for Windows style /? options, and Windows users 
> won't accept --help Linux options, etc)

Right, that one is true of KDE's KCmdLineArgs (which I want to see disappear 
due to bad API and not great implementation). It knows -s and --long.
But surely supporting /s on Windows where -s would work on Linux is trivial.

> The problems with writing a parser like this is to make it general 
> enough to support most of the Qt users, to justify it being part of the 
> core set of modules. If it doesn't, it probably shouldn't be in QtBase, 
> and as such should be a separate Addon, IMO.

I don't agree. We've had something in KDE for 10 years, and "not general 
enough" (for any app-specific needs) has not really been an issue. The issue is 
the API (static array full of QT_TR_NOOP equivalents) and the implementation 
(much more C than C++).

> Anyways, something to keep in mind when working on your implementation. 
> It's a can of worms with a lot of bikeshedding ;)

Yes, this has been said a few times already. However I don't think this is 
enough of an argument for not doing anything about this in Qt (I know for a 
fact that your email discouraged Laszlo of even trying).

If the message, upfront, is "you won't be able to get this into Qt", then a 
natural reaction is to just say "OK, then I give up, we'll do something KDE-
specific instead". But this goes against my main goal of removing the 
distinction between a KDE app and a Qt app as much as possible.

I see no reason why command-line argument parsing can't be provided by Qt.
It's not as complex as you say, all kde apps do fine with the features listed 
at http://api.kde.org/4.x-api/kdelibs-
apidocs/kdecore/html/classKCmdLineOptions.html#ac3064e6ec33f92a4a6d17eb8ff766034

You're right, tar couldn't use this. But then again, tar is not a Qt 
application, and will probably never be. And for a new program, there's always 
the option of *choosing* a set of command-line options that is actually doable 
with the existing Qt class, rather than going for something as funky as "tar 
xvf". Look at GNU getopt: same issue, it can't be used by tar. So what?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5