[Development] Qt Playground - Command Line Parser experiment

[marius.storm-olsen at nokia.com]

On 15/03/2012 04:53, ext David Faure wrote:
> On Monday 12 March 2012 20:06:22 marius.storm-olsen at nokia.com wrote:
>> 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'm sorry if it discouraged Laszlo from trying to embark on this 
project. Nowhere in my email did I say that it couldn't or shouldn't be 
done, nor that it wouldn't be accepted in Qt.

My arguments underlined why this task/project is _special_, and why I 
believe that it would fit better as a separate AddOn repo, than a 
feature branch to qtbase.

I think development and adoption would happen more quickly if the 
project has its own AddOn.

Also, with an AddOn it doesn't matter much what other people say. If you 
don't want it/agree with it etc, then you simply don't include it.


> 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

I'm not saying that it cannot be provided for Qt. I'm saying there are 
many opinions on how an argument parser should work, so do it in an 
Addon first. Then it doesn't matter so much if not everyone agrees. It 
might be harder if you don't get broad agreement when working on a 
feature branch of QtBase (say if Lars or Thiago say no), then you cannot 
merge and the work is in limbo.

And nothing says we cannot pull it from the Addon into QtBase at a later 
point in time.


> 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?

The applications I mentioned are "bastards" when it comes to 
commands/actions/options, and I mentioned them on purpose to facilitate 
discussion. They don't represent valid use-cases, but rather indicate 
the extremes. It's a balancing act though, to figure out which features 
to support, and which ones to ignore to capture the 90% without getting 
too complex.

For example:
* Do short options only accept single letter, or can they have more?
     -E for preprocessing in GCC, /E or /EP with MSVC
     -reverse for Qt apps

* Will 'single dash' long options be allowed?
     -traditional-cpp in gcc
     -style=foo for Qt apps

* Will short option clustering be allowed? What if short options support 
more than one letter?

* What if the clustering of some short options match another single 
short option, or a long option if single dash long options are allowed?

* Do you allow for turning on/off boolean values with preceeding +/-?
     MSVC uses trailing '-' to turn off options, like /GR- to
     turn off RTTI

* Do you use space, '=', ':' or nothing as a option/value separator?
     -o<filename>
     -output <filename>
     -output:<filename>
     -output=<filename>

There's lots of nuances to evaluate. You could say lets just support 
getopt, but then you're likely falling into the unix-world-only trap. 
But I guess, "so what"? ;)

-- 
.marius

PS. To sum up, "do it as an addon, not as a feature branch", and _not_ 
"don't do it".