On Thursday 15 March 2012 09:23:27 marius.storm-ol...@nokia.com wrote: > On 15/03/2012 04:53, ext David Faure wrote: > > On Monday 12 March 2012 20:06:22 marius.storm-ol...@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#ac3064e6ec33f92a4a6d17eb8f > > f766034 > > 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.
Answering according to what I implemented 2 months ago and is on github: > 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 You must have a clear definition of what is a short option then, if you mean options that doesn't require a value, ok, it's supported. sorry if I didn't get what you meant. > * Will 'single dash' long options be allowed? > -traditional-cpp in gcc > -style=foo for Qt apps Yes, it is. > * Will short option clustering be allowed? What if short options support > more than one letter? Option clustering is allowed. If the short option has more than one letter it isn't short. > * What if the clustering of some short options match another single > short option, or a long option if single dash long options are allowed? IMHO it's a programmer failure to support: -a, -b and -ab IIRC in my implementation the class tell the user used all options. > * Do you allow for turning on/off boolean values with preceeding +/-? > MSVC uses trailing '-' to turn off options, like /GR- to > turn off RTTI Isn't implemented, but it easy to do, anyway I don't know other application besides cl.exe that users this pattern. > * Do you use space, '=', ':' or nothing as a option/value separator? > -o<filename> > -output <filename> > -output:<filename> > -output=<filename> The current implementation accepts space or "=" as separator, add support for other separators should not be a hard task. > 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"? ;) Yes, there are, IMO we just need good defaults and some flexibility without complicating the API for ultra-corner cases. -- Hugo Parente Lima INdT - Instituto Nokia de Tecnologia
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development