Re: [Development] Qt Playground - Command Line Parser experiment
On quinta-feira, 15 de março de 2012 15.00.19, Hugo Parente Lima wrote: > > Also, how about support for multiple values for an option, separated by > > ','? gcc -Wl,--defsym,__stack_limit=0x7ffe' > > Probably an ultra-corner case? > > I believe this is, as you said, a ultra corner case. but it's not too hard > to implement, I just don't know if is worth to implement this. We'd probably implement this as either: -Wl= or -W And then parse the "l" as "linker flags" and then break the commas as different options. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden 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
Re: [Development] Qt Playground - Command Line Parser experiment
On Thursday 15 March 2012 15:38:39 Laszlo Papp wrote: > Hey, > > > Upon agreement with QtCore maintainer Thiago, a cli_parser branch has > > been created for QtBase, with Submit rights for Laszlo and anyone added > > to his Gerrit group "CLI Parser". > > Yeah, I will put some code in there soon from this KDE Scratch repository: > http://quickgit.kde.org/index.php?p=scratch%2Flpapp%2Fcommandlineparser.git > &a=commit&h=f76147f9bcaaaefaf25543ab30bf668183a9ecaa > > Hugo, I skimmed through your code which has similar ideas for the > option and parser. That is good. :) It would be nice to join the > forces and work together on this as you mentioned previously. I can > add you to the group, if that is okay for you ? Yes, do it, hugopl on gerrit =] > Best Regards, > Laszlo Papp > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- 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
Re: [Development] Qt Playground - Command Line Parser experiment
Hey, > Upon agreement with QtCore maintainer Thiago, a cli_parser branch has > been created for QtBase, with Submit rights for Laszlo and anyone added > to his Gerrit group "CLI Parser". Yeah, I will put some code in there soon from this KDE Scratch repository: http://quickgit.kde.org/index.php?p=scratch%2Flpapp%2Fcommandlineparser.git&a=commit&h=f76147f9bcaaaefaf25543ab30bf668183a9ecaa Hugo, I skimmed through your code which has similar ideas for the option and parser. That is good. :) It would be nice to join the forces and work together on this as you mentioned previously. I can add you to the group, if that is okay for you ? Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On 15/03/2012 08:33, ext Oswald Buddenhagen wrote: > On Thu, Mar 15, 2012 at 12:23:27PM +, Marius Storm-Olsen wrote: >> 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. >> > i'd consider making it an addon a fallback in case it gets rejected > for qtbase, not the default choice to get it started. repo management > is virtually non-existent in gerrit, so i'd prefer not to add more > noise to the project overview. FYI, since discussions happened on IRC: Upon agreement with QtCore maintainer Thiago, a cli_parser branch has been created for QtBase, with Submit rights for Laszlo and anyone added to his Gerrit group "CLI Parser". Thiago has noted that this branch will not be merged directly into master, but will be used to develop the command line parser. Upon acceptance of the finalized parser, the branch history will be cleaned up and rebased before it is merged into master. If the final parser is not accepted into QtCore, it can be put into its own playground repo at that time. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On Thursday 15 March 2012 12:17:41 marius.storm-ol...@nokia.com wrote: > On 15/03/2012 08:32, ext Hugo Parente Lima wrote: > > On Thursday 15 March 2012 09:23:27 marius.storm-ol...@nokia.com wrote: > >> 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. > > Sure, you can define /EP as a long option, but then you definitely need > to support single-dash long options (which you would need to on Windows > anyways, since no one does //EP :) > > >> * 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. > > Fair enough. > > >> * 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. > > IMO you have 3 possibilities if -ab is passed, were only 2 are acceptable: > 1) Mark all premutations as selected (-a, -b, and -ab). > This is probably not what the end user meant, alas bad. > 2) Warn the developer when he runs the application that > there are options which shadow each other, and show > which ones they are. IMO this would be acceptable only if this check could be done only on debug builds. > 3) Allow for option shadowing, so -ab is unique from passing > -a -b > or > -ba And what if the scumbag developer create the options: -a, -b, -ab and -ba? =] > >> * 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. > > (g)vim? > Ex: gvim + foobar.cpp # Jumps to EOF > gvim +10 foobar.cpp # Jumps to line 10 This "+10" would be represented as "positional arguments" like the "foobar.cpp". > I'm sure there are others. > > >> * Do you use space, '=', ':' or nothing as a option/value separator? > >> > >> -o > >> -output > >> -output: > >> -output= > > > > 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. > > Also, how about support for multiple values for an option, separated by > ','? gcc -Wl,--defsym,__stack_limit=0x7ffe' > Probably an ultra-corner case? I believe this is, as you said, a ultra corner case. but it's not too hard to implement, I just don't know if is worth to implement this. > Some other implementations to take a look at perhaps: > http://llvm.org/docs/CommandLine.html > http://www.doughellmann.com/PyMOTW/argparse/ Yes, I was inspired by the Python argparse API, although I didn't check the llvm one yet, thanks for the suggestion. > Note that due to Windows "corky" command-line handling, the parser > probably would want to integrate more low-level on Windows to ensure > that argument parsing is as close as possible on the various platforms. > > See http://blogs.msdn.com/b/oldnewthing/archive/2010/09/17/10063629.aspx > for details. > and >http://msdn.microsoft.com/en-us/library/zay8tzh6.aspx >http://msdn.microsoft.com/en-us/library/ms683156.aspx >http://msdn.microsoft.com/en-us/library/ms647232.aspx > > Yes, the worms are multiplying ;) Yes, they are, but I think most of them are mortals and can be killed =] -- Hugo Parente Lima INdT - Instituto Nokia de Tecnologia signature.asc Description: This is a digitally signed message part.
Re: [Development] Qt Playground - Command Line Parser experiment
On 03/09/2012 12:36 AM, ext Laszlo Papp wrote:
> I would like to experiment with a command line parser in Qt
> Playground. The topic and the use case were more or less discussed
> previously on the qt5-feedback mailing list around last October.
Btw, the libqxt project (http://dev.libqxt.org/libqxt/wiki/Home) also
has a command-line parser ("QxtCommandOptions"). For some reason, the
API is not documented on their website, but it's in the source tree.
Should perhaps be evaluated as well.
Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On 15/03/2012 08:32, ext Hugo Parente Lima wrote: > On Thursday 15 March 2012 09:23:27 marius.storm-ol...@nokia.com wrote: >> 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. Sure, you can define /EP as a long option, but then you definitely need to support single-dash long options (which you would need to on Windows anyways, since no one does //EP :) >> * 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. Fair enough. >> * 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. IMO you have 3 possibilities if -ab is passed, were only 2 are acceptable: 1) Mark all premutations as selected (-a, -b, and -ab). This is probably not what the end user meant, alas bad. 2) Warn the developer when he runs the application that there are options which shadow each other, and show which ones they are. 3) Allow for option shadowing, so -ab is unique from passing -a -b or -ba >> * 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. (g)vim? Ex: gvim + foobar.cpp # Jumps to EOF gvim +10 foobar.cpp # Jumps to line 10 I'm sure there are others. >> * Do you use space, '=', ':' or nothing as a option/value separator? >> -o >> -output >> -output: >> -output= > > 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. Also, how about support for multiple values for an option, separated by ','? gcc -Wl,--defsym,__stack_limit=0x7ffe' Probably an ultra-corner case? Some other implementations to take a look at perhaps: http://llvm.org/docs/CommandLine.html http://www.doughellmann.com/PyMOTW/argparse/ Note that due to Windows "corky" command-line handling, the parser probably would want to integrate more low-level on Windows to ensure that argument parsing is as close as possible on the various platforms. See http://blogs.msdn.com/b/oldnewthing/archive/2010/09/17/10063629.aspx for details. and http://msdn.microsoft.com/en-us/library/zay8tzh6.aspx http://msdn.microsoft.com/en-us/library/ms683156.aspx http://msdn.microsoft.com/en-us/library/ms647232.aspx Yes, the worms are multiplying ;) -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On Thu, Mar 15, 2012 at 12:23:27PM +, Marius Storm-Olsen wrote: > 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. > i'd consider making it an addon a fallback in case it gets rejected for qtbase, not the default choice to get it started. repo management is virtually non-existent in gerrit, so i'd prefer not to add more noise to the project overview. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
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 > -output > -output: > -output= 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 me
Re: [Development] Qt Playground - Command Line Parser experiment
On Thursday 15 March 2012 08:26:14 kai.koe...@nokia.com wrote: > > -Original Message- > > From: development-bounces+kai.koehne=nokia@qt-project.org > > [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On > > Behalf Of ext Hugo Parente Lima > > Sent: Thursday, March 15, 2012 12:16 PM > > To: development@qt-project.org > > Cc: Mark Constable > > Subject: Re: [Development] Qt Playground - Command Line Parser > > experiment > > > > On Thursday 15 March 2012 07:29:23 Mark Constable wrote: > > > Any simple standard cli args parser included with Qt would be > > > overwhelmingly better than none at all even if it's just -s shortops > > > (/s for win) and worry about --longopts and tar-like variations for > > > Qt6+. The simpler the better as long as it's universally available in > > > qtcore, if possible, sooner than later. > > > > Hmmm... ok, let's go again... should I elaborate this: > > > > https://github.com/hugopl/qcmdlineparser > > (g...@github.com:hugopl/qcmdlineparser.git) > > > > or just "git push origin :master" and forget about? > > > > Some usage examples can be found on the small unit test: > > > > https://github.com/hugopl/qcmdlineparser/blob/master/qcmdlineparsertes > > t.cpp > > I only checked the tests file, but it seems like you're going for the GNU > style where options following '-' are always one character letters.The Qt > tools itself do not follow this style, e.g. qmake -project, not qmake > --project, or qmake -p :) To use the parser also internally , it should > IMO also support a style where '-help' is one valid argument. It already accepts and there are tests for it, the default "auto-help" adds a "--help" and "-h", but can easily add a "-help" too. The translation of "-" into "/" on Windows isn't done but is easy to do. > Just my 2 cents > > Kai -- 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
Re: [Development] Qt Playground - Command Line Parser experiment
On quinta-feira, 15 de março de 2012 14.24.25, Laszlo Papp wrote: > > I only checked the tests file, but it seems like you're going for the GNU > > style where options following '-' are always one character letters.The Qt > > tools itself do not follow this style, e.g. qmake -project, not qmake > > --project, or qmake -p :) To use the parser also internally , it should > > IMO also support a style where '-help' is one valid argument. > That was my worry previously as well. Would it be possible to refactor > -foobar to --foobar for Qt5 (not using single dash for long options) ? > Otherwise, as far as I see, we lose the short options which is > something that the users would like to see. > > We are beyond the feature freeze, thus it probably needs special > acceptance in case yes. If it does not happen, I am unsure whether it > can be done before Qt6 that way. Refactoring the tools now is a complete no-go. You want to: - change how the tools accept parameters - in tools that don't have good command-line parsing infrastructure - 4 weeks after feature-freeze -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden 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
Re: [Development] Qt Playground - Command Line Parser experiment
> I only checked the tests file, but it seems like you're going for the GNU > style where > options following '-' are always one character letters.The Qt tools itself do > not follow this style, e.g. qmake -project, not qmake --project, or qmake -p > :) To use the parser also internally , it should IMO also support a style > where '-help' is one valid argument. That was my worry previously as well. Would it be possible to refactor -foobar to --foobar for Qt5 (not using single dash for long options) ? Otherwise, as far as I see, we lose the short options which is something that the users would like to see. We are beyond the feature freeze, thus it probably needs special acceptance in case yes. If it does not happen, I am unsure whether it can be done before Qt6 that way. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
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#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 -output -output: -output= 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". ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On Thu, Mar 15, 2012 at 10:53:59AM +0100, ext David Faure wrote: > On Monday 12 March 2012 20:06:22 marius.storm-ol...@nokia.com wrote: > > 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. > it's not as simple as that ... for one, -s and /s have different semantics. it's -ab, but /a/b. the only universal syntax is always separating by spaces, which is mildly annoying. of course one can go for a "neutral" syntax like the qt tools use: - no option "merging" (-a -b != -ab) - options of any length treated equally - additional second dash ignored (some qt tools do that) - on windows, accept a leading slash (no qt tools do that, actually). cannot accept that on unix, as no distinction from path names is possible. on windows, some os tools actually accept unix paths (the os functions all (?) accept them), but then the path must be explicitly quoted (note that the argv interface permits no distinction between the two (because /foo and "/foo" are parsed the same)). this does not "feel at home" for unix (where gnu getopt long option style is considered normal). windows is a mess anyway, actively promoted by ms (dos had an os function to change the switch char. it was an epic failure). i'd actually use that as an argument to simply go for gnu getopt syntax. but whatever. just saying. ;) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
I would like an argument parser in Qt, and I'd like it to be in qtbase. The reason for qtbase is so that our own tools and manual tests can use it. Manual tests outside of qtbase are normally GUI based. I think this is something that can go into a minor 5.x release. About windows: Tools that use / for arguments also accept - (except the built in shell commands) The / can be used for both short and long arguments (e.g. "nmake /nologo" vs "nmake /kc" vs "nmake /k /c") Arguments may be case insensitive The command line is pretty much only used by technical people (buried 3 levels deep in the app menu), who would probably accept unix style args. If we want to support windows style: Use Qt::CaseInsensitive to opt in to case insensitive args Print a qWarning if the arguments could be ambiguous (assuming the API declares the possible arguments up front like perl's GetOpt::Long) Allow opt out from short argument compression (i.e. "/xzf" would only be considered as a synonym for "--xzf" and not for "-x -z -f" if the opt out is applied) > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Mark Constable > Sent: 15 March 2012 10:29 > To: development@qt-project.org > Subject: Re: [Development] Qt Playground - Command Line Parser > experiment > > Any simple standard cli args parser included with Qt would be > overwhelmingly > better than none at all even if it's just -s shortops (/s for win) and > worry > about --longopts and tar-like variations for Qt6+. The simpler the > better as > long as it's universally available in qtcore, if possible, sooner than > later. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
> -Original Message- > From: development-bounces+kai.koehne=nokia@qt-project.org > [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On > Behalf Of ext Hugo Parente Lima > Sent: Thursday, March 15, 2012 12:16 PM > To: development@qt-project.org > Cc: Mark Constable > Subject: Re: [Development] Qt Playground - Command Line Parser > experiment > > On Thursday 15 March 2012 07:29:23 Mark Constable wrote: > > Any simple standard cli args parser included with Qt would be > > overwhelmingly better than none at all even if it's just -s shortops > > (/s for win) and worry about --longopts and tar-like variations for > > Qt6+. The simpler the better as long as it's universally available in > > qtcore, if possible, sooner than later. > > Hmmm... ok, let's go again... should I elaborate this: > > https://github.com/hugopl/qcmdlineparser > (g...@github.com:hugopl/qcmdlineparser.git) > > or just "git push origin :master" and forget about? > > Some usage examples can be found on the small unit test: > > https://github.com/hugopl/qcmdlineparser/blob/master/qcmdlineparsertes > t.cpp I only checked the tests file, but it seems like you're going for the GNU style where options following '-' are always one character letters.The Qt tools itself do not follow this style, e.g. qmake -project, not qmake --project, or qmake -p :) To use the parser also internally , it should IMO also support a style where '-help' is one valid argument. Just my 2 cents Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On Thursday 15 March 2012 07:29:23 Mark Constable wrote: > Any simple standard cli args parser included with Qt would be > overwhelmingly better than none at all even if it's just -s shortops (/s > for win) and worry about --longopts and tar-like variations for Qt6+. The > simpler the better as long as it's universally available in qtcore, if > possible, sooner than later. Hmmm... ok, let's go again... should I elaborate this: https://github.com/hugopl/qcmdlineparser (g...@github.com:hugopl/qcmdlineparser.git) or just "git push origin :master" and forget about? Some usage examples can be found on the small unit test: https://github.com/hugopl/qcmdlineparser/blob/master/qcmdlineparsertest.cpp Regards -- 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
Re: [Development] Qt Playground - Command Line Parser experiment
Any simple standard cli args parser included with Qt would be overwhelmingly better than none at all even if it's just -s shortops (/s for win) and worry about --longopts and tar-like variations for Qt6+. The simpler the better as long as it's universally available in qtcore, if possible, sooner than later. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On Thu, Mar 15, 2012 at 10:53 AM, David Faure wrote: > Look at GNU getopt: same issue, it can't be used by tar. So what? I think the "so what" about sums up my feelings on this too. It's possible to bikeshed to the ends of the earth on pretty much any topic, but this isn't useful to anyone, and doesn't actually get anything done. The lack of argument processing means it is something which gets reinvented pretty much everywhere (usually poorly!) all over the place. Why can't we just do it, and focus on the problems that _matter_ as they come up? tl;dr I agree with David. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
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
Re: [Development] Qt Playground - Command Line Parser experiment
On 08/03/2012 17:36, ext Laszlo Papp wrote: > It is not a separate module, but class(es). The name for this > experiment, in playground, would be something like "Command Line > Parser". According to the regulation: if nobody objects to this > addition from the beginning, I need to get the support of one > existing module maintainer in order to be able to experiment with > this feature in playground. Like Ossi said, normally this would just be a feature branch, due to their natural fitting into existing modules. However, this case is special. See below. > Either way, please let me know your thoughts. Thank you in advance! It has been a long tradition inside Trolltech, and later Qt Development Frameworks that all new employees come with a bright idea to implement a command-line parser. After all, the Qt framework doesn't come with any, so it must certainly somehow have been forgotten. Not so. We probably have 10-12 command-line parsers developed throughout the years, but none of them have ever been included in the product. Mostly because either, 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?) b) The parser is too complex, where it doesn't live up to the simplicity expected from Qt API and usage. 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) 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. Anyways, something to keep in mind when working on your implementation. It's a can of worms with *a lot* of bikeshedding ;) Good luck! -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
Hi, Sounds great, Im using boost:program_options. I would help in testing i dont really need boost. Ariel Ariel Molina Rueda On Mon, Mar 12, 2012 at 9:53 AM, Christian Kandeler wrote: > On 03/09/2012 12:36 AM, ext Laszlo Papp wrote: >> I would like to experiment with a command line parser in Qt >> Playground. The topic and the use case were more or less discussed >> previously on the qt5-feedback mailing list around last October. >> >> It is not a separate module, but class(es). The name for this >> experiment, in playground, would be something like "Command Line >> Parser". According to the regulation: if nobody objects to this >> addition from the beginning, I need to get the support of one existing >> module maintainer in order to be able to experiment with this feature >> in playground. >> >> Either way, please let me know your thoughts. Thank you in advance! > > After having written three project-specific command line parsers in as > many months, I am enthusiastically in favor of having a general one in > Qt. Definitely a good idea. > > > Christian > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On 03/09/2012 12:36 AM, ext Laszlo Papp wrote: > I would like to experiment with a command line parser in Qt > Playground. The topic and the use case were more or less discussed > previously on the qt5-feedback mailing list around last October. > > It is not a separate module, but class(es). The name for this > experiment, in playground, would be something like "Command Line > Parser". According to the regulation: if nobody objects to this > addition from the beginning, I need to get the support of one existing > module maintainer in order to be able to experiment with this feature > in playground. > > Either way, please let me know your thoughts. Thank you in advance! After having written three project-specific command line parsers in as many months, I am enthusiastically in favor of having a general one in Qt. Definitely a good idea. Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
[...] > it's entirely misguided to create a playground project for "classes" > (which are presumably meant to end up in qtcore). Fair enough, and you convinced me. ;) I will just push my changes then as previously with "WIP" so that it is rejected automatically. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On Thursday 08 March 2012 20:36:07 Laszlo Papp wrote: > Hi, > > I would like to experiment with a command line parser in Qt > Playground. The topic and the use case were more or less discussed > previously on the qt5-feedback mailing list around last October. > > It is not a separate module, but class(es). The name for this > experiment, in playground, would be something like "Command Line > Parser". According to the regulation: if nobody objects to this > addition from the beginning, I need to get the support of one existing > module maintainer in order to be able to experiment with this feature > in playground. I was doing some experiment with this here: https://github.com/hugopl/qcmdlineparser If you want, we would join our efforts. > Either way, please let me know your thoughts. Thank you in advance! > > Best Regards, > Laszlo Papp > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- 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
Re: [Development] Qt Playground - Command Line Parser experiment
On Fri, Mar 09, 2012 at 01:36:07AM +0200, ext Laszlo Papp wrote: > It is not a separate module, but class(es). The name for this > experiment, in playground, > it's entirely misguided to create a playground project for "classes" (which are presumably meant to end up in qtcore). what you should be requesting is an official feature branch. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Playground - Command Line Parser experiment
Hi, I would like to experiment with a command line parser in Qt Playground. The topic and the use case were more or less discussed previously on the qt5-feedback mailing list around last October. It is not a separate module, but class(es). The name for this experiment, in playground, would be something like "Command Line Parser". According to the regulation: if nobody objects to this addition from the beginning, I need to get the support of one existing module maintainer in order to be able to experiment with this feature in playground. Either way, please let me know your thoughts. Thank you in advance! Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
