On Monday 12 March 2012 20:06:22 marius.storm-ol...@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, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development