[Development] QCommandLineParser

[BRM]

----- Original Message -----

> From: David Faure <faure at kde.org>
> To: development at qt-project.org
> Cc: 
> Sent: Thursday, August 1, 2013 5:13 AM
> Subject: Re: [Development] QCommandLineParser
> 
> On Monday 29 July 2013 13:46:46 Thiago Macieira wrote:
>>  In other words: we don't have --help-qt now and I don't see any 
> point in 
>>  adding one in the internal parser.
> 
> We've had --help-qt in KDE for 15 years, and it's quite useful, when 
> looking 
> up one of these less-often-used options that come from Qt itself.
> 
>>  That said, it might be a good idea to move some of the "Qt" 
> options to the 
>>  main help output where they are useful, like -geometry, keeping hidden only 
> 
>>  the really obscure ones that most people won't ever need. Also, I'd 
> rather
>>  we didn't call them "Qt options", but simply something like 
> "system
>>  options". The fact that Qt handles them is irrelevant.
> 
> I don't think we should pollute the main help with selected builtin options 
> like -geometry. Different people use different options, so we'll be debating 
> 
> which are the most used options and which are the obscure options until the 
> end of time.
> 
> Overall I'm sure we all agree that the builtin Qt options are used less than 
> 
> the actual options coming from the application itself though, hence the idea 
> of splitting them into a --help-qt (which would itself be documented in --help 
> of course).

Having some method of at least optionally being able to provide a list of those options would be good.
In the rare times I've wanted to test my apps with some of the Qt options (like changing to use the Windows XP stylesheet on Linux for testing)
I've had to spend a good amount of time just trying to figure out what the option was.
Having an easy way to document it in a manner that is application accessible would therefore be good - even if we don't expect normal users to use them.

$0.02

Ben