[Development] QCommandLineParser

[David Faure]

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).

About the naming: -geometry is indeed a system (X11) option, but -stylesheet, 
-graphicssystem, -qmljsdebugger, -reverse and many more are really options 
that are only available because the application is using Qt. So --help-qt 
seems prefectly relevant to me. If your app isn't made with Qt, these options 
won't work.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5