[Development] A new approach for Qt main()

[Laszlo Agocs]

Special macros for straightforward applications on exotic systems? Sure. Forcing an unnecessary change on existing and future applications on platforms that are doing just fine (i.e. the majority)? No.

Building on Friedemann's example the list of potentially problematic cases could go on forever. For example, what if you need to set certain application attributes, default surface formats, etc. before the Q(Gui)Application construction. Or the special cases where app object creation should be carefully placed. In the end those macros would need to get a lot more complicated than they look at first. Based on all the negative experience with testlib's similar and the qtdeclarative examples' main-wrapping macros, I'd rather prefer we think twice before introducing any such macros.

Also, if migration for the typical applications is seen that easy, it should be no problem for developers targeting exotic systems to provide a new-style entry point in their apps.

Best regards,
Laszlo

From: Development [mailto:development-bounces+laszlo.agocs=qt.io at qt-project.org] On Behalf Of Simon Hausmann
Sent: Friday, December 9, 2016 11:17 AM
To: Friedemann Kleint <Friedemann.Kleint at qt.io>; development at qt-project.org
Subject: Re: [Development] A new approach for Qt main()




Yes, and we will forever (?) support that kind of main function and application entry point. I don't think that we can break that.



I'm all interested in supporting a second supported way of describing an entry point that more closely matches today's semantics

of graphics applications on the underlying operating/windowing systems.



Oddly, I do like the way that we're doing this on Windows and have been doing it forever, by shoehorning main() into WinMain()

through a static library. I'm not suggesting to replace QtMain, but I wonder if we could offer a cross-platform QtMain (with a different

name that doesn't clash with the existing one) that requires the programmer to supply a _two_ (or more?) functions instead of one function. No

macros involved then.





Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:development-bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Friedemann Kleint <Friedemann.Kleint at qt.io<mailto:Friedemann.Kleint at qt.io>>
Sent: Friday, December 9, 2016 11:00:00 AM
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] A new approach for Qt main()

Hi,

 > Q_GUI_MAIN(appInit, appExit);

Magic macros for main should be avoided, IMO.

A typical application main() can look like

  main()
  {
     QApplication a();

     Initialization code for other libraries

     parseArguments(), return if failed

     show some FileDialog prompting for argument if sth was missing

     try {
       app.exec()
     } catch (exception) {
     }
     De-Initialize something
  }

There is no way to shoehorn this into some macro; this can already be
observed when trying to adding some initialization to a test.

Regards,
Friedemann

--

Friedemann Kleint
The Qt Company GmbH

_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20161209/9678e350/attachment.html>