thiago.macieira at intel.com
Mon Jul 29 22:46:46 CEST 2013
On segunda-feira, 29 de julho de 2013 20:38:38, David Faure wrote:
> * later if we want to use QCommandLineParser for the builtin qapp options,
> qcoreapp would create its own *separate* instance, and register it
> internally in qcoreapp (not public, unlike the previous idea). And the
> magic is that every parser instance would have a --help-qt option, which
> delegates to the qcoreapp-owned instance to print out the builtin options.
> So, this needs no new API either to mark these options as the ones for
> --help- qt, they are already separated in a different internal-only parser,
> not mixed with the application options.
> By the time we want to create a command-line parser internally in QCoreApp,
> we can sort out the translation setup -- possibly like in KDE where the
> translators got automatically loaded from standard paths, which means tr()
> can be used inside the qapp constructors.
I like this idea. The internal parser does not need to handle any help
options, it might be at most used to simplify the handling of arguments that
we already do have anyway. If a help output is required, it should come from
the main application's parsing.
In other words: we don't have --help-qt now and I don't see any point in
adding one in the internal parser.
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.
PS: the -plugin option has to go. Its name is too generic.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the Development