> On 10 Dec 2016, at 01:43, Thiago Macieira <thiago.macie...@intel.com> wrote: > > Em sexta-feira, 9 de dezembro de 2016, às 16:50:29 PST, Matthew Woehlke > escreveu: >> On 2016-12-09 16:23, Thiago Macieira wrote: >>> Em sexta-feira, 9 de dezembro de 2016, às 15:28:13 PST, Matthew Woehlke >>> >>> escreveu: >>>> I can work around that, though it's obnoxious. I'm more concerned about >>>> not being able to tinker with the CLI arguments before Qt gets them. >>> >>> That's a valid concern, but not one that warrants a QApplication subclass. >> >> Right; that one is an issue if the user is no longer in control of >> instantiating the Q*Application instance. > > Ah, that's a good point. > > Though quite frankly I don't see that as an issue. Applications can only have > access to argc and argv if they write the main() function, which means they > can continue to use the current functionality. > > I'm imaginiing that this new way is needed for platforms where a main() > function makes no sense, in which case there's no command-line to begin with.
That is one use case, another is where the standard way to start the native platform and event loop is not compatible with the Q*Application on stack and app.exec() pattern. (See macOS example in the other mail) Morten _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development