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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
