[Development] A new approach for Qt main()

[Edward Welbourne]

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.dewit at 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.terrier at 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.