Em sexta-feira, 9 de dezembro de 2016, às 10:44:24 PST, Lars Knoll escreveu: >>>>> Well, the problem is that the main() entry point is causing huge >>>>> amounts of issues on at least Android and iOS. We’d help those >>>>> platforms a lot if we didn’t support this kind of entry point (on >>>>> those platforms) anymore. But I agree that we can’t break this in >>>>> Qt 5, but we can prepare for Qt6. >>>>> >>>>> I’d propose to define a new entry point that works better on these >>>>> platforms and offering that as the recommended way for new >>>>> apps. The best solution is probably a static library that provides >>>>> callbacks that can be used to initialize things.
On 9 December 2016 18:05, Thiago Macieira replied: >>>> Can we get a description of what those problems are, for those of >>>> us who have never developed anything for those OSes, so we're not >>>> discussing things in the abstract? I haven't seen an actual reply to that, but these fragments at least point towards a sketch of the reply: 2016-12-12 10:56 GMT+01:00 Mark De Wit <mark.de...@iesve.com>: >>> I have an application based on qt-solutions qtwinmigrate sample. >>> >>> Because we're integrating Qt into an existing MFC application, >>> we're not even running QApplication exec. The application uses >>> MFC's entry point for startup and drives the Qt event loop >>> manually as part of the MFC event loop. 12.12.2016, 13:08, "Benjamin TERRIER" <b.terr...@gmail.com>: >> I also did something like that on Linux with a software written with >> another graphical framework. >> We made it work by calling QApplication::processEvents() in the other >> framework event loop. 12 December 2016 15:49 Konstantin Tokarev > Same is true for QtWebKit in WebKit2 mode - in background processes we > don't run exec() directly, it is invoked inside WTF::RunLoop. and I've heard some conversations over meals, so let's sketch what I think is the main pattern for which the present architecture is a problem: * In some systems, the event loop isn't ours to control. What that means in practice is that all we can do is register call-backs to respond to events. Details remain a mystery, but presumably we get some way to register a "getting started" call-back, which can presumably register a "shutting down" call-back and assorted call-backs for other events. I'd like to see detailed descriptions of what the actual details are, for this, on each of the platforms for which traditional C main() isn't a good model. To have one architecture that works for such environments and also works for the traditional main() context, we need Qt's event loop to be optional. Something we may as well call QApplication might provide a default event loop implementation (for main() use), but none of the rest of our code should presume this is the event loop in use. We need all our "register handler" APIs to be designed to be agnostic about whose event loop those handlers get registered to. This shall mean even Qt-internal events (e.g. those implementing signal/slot interactions) can be packaged as platform-native events (that Qt shall unpack and enact when they're delivered). We should, none the less, be able to package that architecture with Q*Application objects that *do* provide an event loop so that existing main() users and tutorials don't need to change what main() looks like; there might be some changes to how they register handlers and there shall surely be some changes "under the bonnet" to how moc implements signals and slots (so that their handling is message-loop-agnostic). ... and that's about as much as I think anyone can say about the future architecture until someone familiar with the main()-incompatible world can explain to us all what the contexts are in which the old way fails. Perhaps we need a Wiki page, detailing the different ways platforms support start-up and shut-down. So let's have a wiki page for that: * https://wiki.qt.io/Application_Start-up_Patterns While I'm at it, I've put that into * https://wiki.qt.io/Category:Developing_Qt::Architecture and invite anyone who knows about wiki pages that talk about Qt's architecture to add them to [[Category:Developing_Qt::Architecture]]. They might be more discoverable that way. Eddy. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development