[Development] A new approach for Qt main()

[Morten Sorvig]

Hi,

We should consider changing the way Qt initialization and startup works.
This is something I’ve personally been wanting to do for some time, and
a recent offline discussion pushed it on my stack again.

Currently, Qt and application startup looks something like this:

  int main(int argc, char **argv)
  {
  QApplication app(argc, argv);

  // Create root user objects/windows here

  return app.exec();
  }

This is fine for the application but cause problems for the Qt platform
implementation, which include:

* The main entry point may be named something else than main()

* The main entry point may be a callback which must be returned from

* The platform/Qt/application initialization order is incorrect

These have all been worked around in Qt platform code, for example by running
Qt on a separate thread, using setjmp/longjmp to simulate a stack, or by
temporarily setting up the native event loop before app.exec() is called.

We can continue with the workarounds, but they lead to complications in Qt
platform code and are also an extra hurdle for implementing support for new
platforms, so from the Qt platform development point of view it is desirable
with a cleanup. 

This would be an “all applications should/must port” event, not to be taken 
lightly. I think the porting would be trivial in many (if not most) cases,
but some apps have special requirements for QApplication object management
or main thread ownership. This includes our own QTestLib.

As a starting point for a concrete API discussion I’ll briefly describe the
solution I implemented for the NaCl port. The user API here is a macro which
takes application init and exit callback functions:

  Q_GUI_MAIN(appInit, appExit);

The use of a macro allows Qt to inject a main() call with native platform
initialization code into the application, if needed. The init and exit
functions are callbacks (which must return) and the root user objects
must be created on the heap. The QApplication object is managed by Qt
and has been created by the time appInit is called. The type of QApplication
is decided by the macro, where there are CORE and WIDGETS variants as well.

- Morten






___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Jake Petroules]

Without getting too much into the technical details, I'm all for it in 
principle. It would certainly help on iOS especially as there's a lot of 
complexity for the main() situation there, which is made even worse by trying 
to support dynamic libraries.

Can you give an example of what the definition of QT_GUI_MAIN would look like 
and what are the signatures of appInit and appExit?

> On Dec 9, 2016, at 1:35 AM, Morten Sorvig  wrote:
> 
> Hi,
> 
> We should consider changing the way Qt initialization and startup works.
> This is something I’ve personally been wanting to do for some time, and
> a recent offline discussion pushed it on my stack again.
> 
> Currently, Qt and application startup looks something like this:
> 
>  int main(int argc, char **argv)
>  {
>  QApplication app(argc, argv);
> 
>  // Create root user objects/windows here
> 
>  return app.exec();
>  }
> 
> This is fine for the application but cause problems for the Qt platform
> implementation, which include:
> 
> * The main entry point may be named something else than main()
> 
> * The main entry point may be a callback which must be returned from
> 
> * The platform/Qt/application initialization order is incorrect
> 
> These have all been worked around in Qt platform code, for example by running
> Qt on a separate thread, using setjmp/longjmp to simulate a stack, or by
> temporarily setting up the native event loop before app.exec() is called.
> 
> We can continue with the workarounds, but they lead to complications in Qt
> platform code and are also an extra hurdle for implementing support for new
> platforms, so from the Qt platform development point of view it is desirable
> with a cleanup. 
> 
> This would be an “all applications should/must port” event, not to be taken 
> lightly. I think the porting would be trivial in many (if not most) cases,
> but some apps have special requirements for QApplication object management
> or main thread ownership. This includes our own QTestLib.
> 
> As a starting point for a concrete API discussion I’ll briefly describe the
> solution I implemented for the NaCl port. The user API here is a macro which
> takes application init and exit callback functions:
> 
>  Q_GUI_MAIN(appInit, appExit);
> 
> The use of a macro allows Qt to inject a main() call with native platform
> initialization code into the application, if needed. The init and exit
> functions are callbacks (which must return) and the root user objects
> must be created on the heap. The QApplication object is managed by Qt
> and has been created by the time appInit is called. The type of QApplication
> is decided by the macro, where there are CORE and WIDGETS variants as well.
> 
> - Morten
> 
> 
> 
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Friedemann Kleint]

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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Simon Hausmann]

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  on 
behalf of Friedemann Kleint 
Sent: Friday, December 9, 2016 11:00:00 AM
To: development@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [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...@qt-project.org] On Behalf Of 
Simon Hausmann
Sent: Friday, December 9, 2016 11:17 AM
To: Friedemann Kleint ; development@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 
mailto:development-bounces+simon.hausmann=qt...@qt-project.org>>
 on behalf of Friedemann Kleint 
mailto:friedemann.kle...@qt.io>>
Sent: Friday, December 9, 2016 11:00:00 AM
To: development@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Lars Knoll]

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.

When we then come to Qt6, we could deprecate using main() as the entry point, 
and remove support for it at least on the platforms where this is problematic.

Cheers,
Lars

From: Development  on 
behalf of Simon Hausmann 
Date: Friday, 9 December 2016 at 11:17
To: Friedemann Kleint , Qt development mailing list 

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  on 
behalf of Friedemann Kleint 
Sent: Friday, December 9, 2016 11:00:00 AM
To: development@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.8.0 change files. MAINTAINERS: your actions needed

[Jani Heikkinen]

Hi all,

Most of change files are still ongoing. MAINTAINERS: Please take an action and 
finalize those now.

br,
Jani


From: Development  on 
behalf of Jani Heikkinen 
Sent: Thursday, December 1, 2016 10:07 AM
To: development@qt-project.org
Subject: [Development] Qt 5.8.0 change files. MAINTAINERS: your actions needed

Hi,

We did initial change files for Qt 5.8.0 (for those modules where missing), see 
https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+5.8.0%22,n,z

Maintainers, please take those over & finalize as soon as possible. And of 
course make sure those will be reviewed soon as well. We need to get all these 
in now, RC is planned to happen 13th Dec!

br,
Jani




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Filippo Cucchetto]

Does this relates to moving Qt main loop to a different thread other than
the main thread? Cause currently creating the QtApp from a different thread
causes problems. In particular the plugins static objects are destroyed at
app exit and thus on the main thread (and this causes problems because
QObjects should be freed in the same thread where they've created). An
example is the QQmlComponentsCache.



Il 09 dic 2016 11:44, "Lars Knoll"  ha scritto:

> 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.
>
>
>
> When we then come to Qt6, we could deprecate using main() as the entry
> point, and remove support for it at least on the platforms where this is
> problematic.
>
>
>
> Cheers,
>
> Lars
>
>
>
> *From: *Development 
> on behalf of Simon Hausmann 
> *Date: *Friday, 9 December 2016 at 11:17
> *To: *Friedemann Kleint , Qt development mailing
> list 
> *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  qt...@qt-project.org> on behalf of Friedemann Kleint <
> friedemann.kle...@qt.io>
> *Sent:* Friday, December 9, 2016 11:00:00 AM
> *To:* development@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@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Laszlo Agocs]

There are two separate things in there, though: the entry point and the 
construction of the Q(Core|Gui)Application object. The problem is with the 
latter: is it not clear why Morten’s proposal moves that under the framework’s 
control. Introducing a new entry point, e.g. qtMain(), for all platforms in Qt 
6 is fine. Moving the application object construction into the underlying 
platform-specific entry point Qt provides is not.

Laszlo

From: Development 
[mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of 
Filippo Cucchetto
Sent: Friday, December 9, 2016 12:08 PM
To: Lars Knoll 
Cc: Qt Project Development Mailing-List 
Subject: Re: [Development] A new approach for Qt main()

Does this relates to moving Qt main loop to a different thread other than the 
main thread? Cause currently creating the QtApp from a different thread causes 
problems. In particular the plugins static objects are destroyed at app exit 
and thus on the main thread (and this causes problems because QObjects should 
be freed in the same thread where they've created). An example is the 
QQmlComponentsCache.



Il 09 dic 2016 11:44, "Lars Knoll" mailto:lars.kn...@qt.io>> 
ha scritto:
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.

When we then come to Qt6, we could deprecate using main() as the entry point, 
and remove support for it at least on the platforms where this is problematic.

Cheers,
Lars

From: Development 
mailto:qt...@qt-project.org>>
 on behalf of Simon Hausmann mailto:simon.hausm...@qt.io>>
Date: Friday, 9 December 2016 at 11:17
To: Friedemann Kleint 
mailto:friedemann.kle...@qt.io>>, Qt development 
mailing list mailto:development@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 
mailto:qt...@qt-project.org>>
 on behalf of Friedemann Kleint 
mailto:friedemann.kle...@qt.io>>
Sent: Friday, December 9, 2016 11:00:00 AM
To: development@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Friedemann Kleint]

Hi,

from the Windows POV, support for wmain() with wide arguments would be a 
nice thing to have (see https://bugreports.qt.io/browse/QTBUG-46118 ):


int wmain( int argc, wchar_t *argv[ ], wchar_t *envp[ ] )

Maybe that can be implemented by some smart modularization.

Regards,
Friedemann

--
Friedemann Kleint
The Qt Company GmbH

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Tor Arne Vestbø]

On 09/12/2016 11:44, Lars Knoll wrote:

Well, the problem is that the main() entry point is causing huge amounts
of issues on at least Android and iOS.


I don't know about Android, but on iOS this is patently false. While the 
workaround is complex, it has worked very well in the 3 years since its 
inception. Please don't use iOS as a straw-man in this discussion.


Tor Arne
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Jake Petroules]

> On Dec 9, 2016, at 3:40 AM, Tor Arne Vestbø  wrote:
> 
> On 09/12/2016 11:44, Lars Knoll wrote:
>> Well, the problem is that the main() entry point is causing huge amounts
>> of issues on at least Android and iOS.
> 
> I don't know about Android, but on iOS this is patently false. While the 
> workaround is complex, it has worked very well in the 3 years since its 
> inception. Please don't use iOS as a straw-man in this discussion.

The point is that we shouldn't need such a workaround in the first place. 
That's kind of the point of this discussion. And as I said, the iOS situation 
is made even worse further by dynamic libraries.

> 
> Tor Arne
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Eskil Abrahamsen Blomfeldt]

Den 09.12.2016 12:40, skrev Tor Arne Vestbø:

On 09/12/2016 11:44, Lars Knoll wrote:

Well, the problem is that the main() entry point is causing huge amounts
of issues on at least Android and iOS.


I don't know about Android, but on iOS this is patently false. While 
the workaround is complex, it has worked very well in the 3 years 
since its inception. Please don't use iOS as a straw-man in this 
discussion.


Speaking for Android, there are and have been thread synchronization 
issues due to Qt running a synchronous event loop in the main function. 
It is also impossible to make applications with multiple entry points 
and complex life cycles, which you would expect in an Android 
application consisting of several activities and services that can be 
triggered independently and simultaenously. Our work-around for this is 
to limit support to applications with one activity or one service per 
process in the application.


So while we have been able to find solutions for most our problems, both 
on Android and iOS, I guess Lars' point is that we are encountering more 
and more cases where we have to invent hacks and work-arounds and 
document limitations in order to be functional on modern platforms. It 
might be a sign that we should adapt.


--
Eskil Abrahamsen Blomfeldt
Senior Manager, R&D

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Tor Arne Vestbø]

On 09/12/2016 12:49, Jake Petroules wrote:

On Dec 9, 2016, at 3:40 AM, Tor Arne Vestbø 
wrote:

On 09/12/2016 11:44, Lars Knoll wrote:

Well, the problem is that the main() entry point is causing huge
amounts of issues on at least Android and iOS.


I don't know about Android, but on iOS this is patently false.
While the workaround is complex, it has worked very well in the 3
years since its inception. Please don't use iOS as a straw-man in
this discussion.


The point is that we shouldn't need such a workaround in the first
place. That's kind of the point of this discussion. And as I said,
the iOS situation is made even worse further by dynamic libraries.


Obviously getting rid of workaround (in all platforms, not just iOS) 
would be preferable. But describing the current (x years and counting) 
situation as 'causing huge amount of issues' (on iOS) is just plain 
wrong, and derails the discussion from pragmatic and constructive 
solutions to the problem.


tor arne
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Tor Arne Vestbø]

On 09/12/2016 12:58, Eskil Abrahamsen Blomfeldt wrote:

Den 09.12.2016 12:40, skrev Tor Arne Vestbø:

On 09/12/2016 11:44, Lars Knoll wrote:

Well, the problem is that the main() entry point is causing huge amounts
of issues on at least Android and iOS.


I don't know about Android, but on iOS this is patently false. While
the workaround is complex, it has worked very well in the 3 years
since its inception. Please don't use iOS as a straw-man in this
discussion.


Speaking for Android, there are and have been thread synchronization
issues due to Qt running a synchronous event loop in the main function.
It is also impossible to make applications with multiple entry points
and complex life cycles, which you would expect in an Android
application consisting of several activities and services that can be
triggered independently and simultaenously. Our work-around for this is
to limit support to applications with one activity or one service per
process in the application.

So while we have been able to find solutions for most our problems, both
on Android and iOS, I guess Lars' point is that we are encountering more
and more cases where we have to invent hacks and work-arounds and
document limitations in order to be functional on modern platforms. It
might be a sign that we should adapt.


Yes, I'm not disagreeing that a new model for Qt initialization would be 
welcome, I was reacting to the swiping generalization Lars was making in 
trying to make his point :-)


tor arne
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Jake Petroules]

> On Dec 9, 2016, at 5:02 AM, Tor Arne Vestbø  wrote:
> 
> On 09/12/2016 12:49, Jake Petroules wrote:
>>> On Dec 9, 2016, at 3:40 AM, Tor Arne Vestbø 
>>> wrote:
>>> 
>>> On 09/12/2016 11:44, Lars Knoll wrote:
 Well, the problem is that the main() entry point is causing huge
 amounts of issues on at least Android and iOS.
>>> 
>>> I don't know about Android, but on iOS this is patently false.
>>> While the workaround is complex, it has worked very well in the 3
>>> years since its inception. Please don't use iOS as a straw-man in
>>> this discussion.
>> 
>> The point is that we shouldn't need such a workaround in the first
>> place. That's kind of the point of this discussion. And as I said,
>> the iOS situation is made even worse further by dynamic libraries.
> 
> Obviously getting rid of workaround (in all platforms, not just iOS) would be 
> preferable. But describing the current (x years and counting) situation as 
> 'causing huge amount of issues' (on iOS) is just plain wrong, and derails the 
> discussion from pragmatic and constructive solutions to the problem.

Again, I think you're missing Lars' point - "causing huge amount of issues" 
doesn't necessarily mean that we are constantly finding and fixing issues every 
week - in this context it means "the fact that we have a workaround at all", 
i.e. a suboptimal solution to an architectural problem that we wish wasn't 
there. Even ONE issue (the one that was "fixed" years ago) can still qualify as 
"huge amount of issues" simply because the solution in place is complicated and 
we don't like it.

I think at this point we're nitpicking linguistics. We both understood what 
Lars meant and obviously both agree with him.

> tor arne

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Bogdan Vatra]

On vineri, 9 decembrie 2016 12:58:46 EET Eskil Abrahamsen Blomfeldt wrote:
> Den 09.12.2016 12:40, skrev Tor Arne Vestbø:
> > On 09/12/2016 11:44, Lars Knoll wrote:
> >> Well, the problem is that the main() entry point is causing huge amounts
> >> of issues on at least Android and iOS.
> > 
> > I don't know about Android, but on iOS this is patently false. While
> > the workaround is complex, it has worked very well in the 3 years
> > since its inception. Please don't use iOS as a straw-man in this
> > discussion.
> 
> Speaking for Android, there are and have been thread synchronization
> issues due to Qt running a synchronous event loop in the main function.
> It is also impossible to make applications with multiple entry points
> and complex life cycles, which you would expect in an Android
> application consisting of several activities and services that can be
> triggered independently and simultaenously. Our work-around for this is
> to limit support to applications with one activity or one service per
> process in the application.
> 
> So while we have been able to find solutions for most our problems, both
> on Android and iOS, I guess Lars' point is that we are encountering more
> and more cases where we have to invent hacks and work-arounds and
> document limitations in order to be functional on modern platforms. It
> might be a sign that we should adapt.

IMHO (at least) for Android the biggest problem is the QPA architecture which 
is not designed for multiple Activities/Services. On Android we'll need a QPA 
instance for every Activities/Services :). This also means we'll need to 
redesign QtAndroidExtras as well.

Even if having  multiple Activities in the same process will be a nice thing, 
is not a very demanding feature. The most demanding feature will be to support 
multiple Services alongside an Activity in the same process.

Cheers,
BogDan.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Tor Arne Vestbø]

On 09/12/2016 14:10, Jake Petroules wrote:

Again, I think you're missing Lars' point - "causing huge amount of
issues" doesn't necessarily mean that we are constantly finding and
fixing issues every week - in this context it means "the fact that we
have a workaround at all", i.e. a suboptimal solution to an
architectural problem that we wish wasn't there. Even ONE issue (the
one that was "fixed" years ago) can still qualify as "huge amount of
issues" simply because the solution in place is complicated and we
don't like it.


Yes, linguistics is quite important when trying to make a point over the 
internet. For example using the present tense "causing" instead of past 
tense. The fact that you personally have some sort of allergic reaction 
to the current situation, based on the strong argument of "not liking 
it", is not of much concern to me in shaping the future solution in this 
area.


tor arne
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Andre Poenitz]

Whatever the problem is, I think we should try hard to have a solution 
that 1. does not use macros and 2. that does not optically change the 
int main(int argc, char *argv[]) { QApplication app(argc, argv)... } stanza.

Macros look and feel ugly and outdated in contemporary C++, are harder 
to debug, etc etc. Changing away from a normal main will make look Qt
code alien, not to mention the necessary adaptation in documentation
and each and every "getting started with Qt" tutorial out there. This would
be a high price to pay.

I have to admit that I don't really understand the scope of the problem yet. 
If this is about having customization points in the QApplication object's life 
cycle, or supporting multiple entry points or similar one could have e.g. 
a number of QApplication::setFooCustomization(std::function<...>)
static functions that can be used to register callbacks by the platform
specific Qt and/or user code. Also, the actual "application object" 
lifecycle does not have to be match the user's QApplication object
in main(). The real thing can be created whenever it make sense, and
what the user sees will only forward calls, or hold back calls, or possible 
finalize initialization or whatever using the registered callbacks.

For me it would be helpful to have a list of problems that need to be 
solved before discussing one specific potential solution.

Andre'



From: Development  on 
behalf of Lars Knoll 
Sent: Friday, December 9, 2016 11:44 AM
To: Simon Hausmann; Friedemann Kleint; development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()

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.

When we then come to Qt6, we could deprecate using main() as the entry point, 
and remove support for it at least on the platforms where this is problematic.

Cheers,
Lars

From: Development  on 
behalf of Simon Hausmann 
Date: Friday, 9 December 2016 at 11:17
To: Friedemann Kleint , Qt development mailing list 

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  on 
behalf of Friedemann Kleint 
Sent: Friday, December 9, 2016 11:00:00 AM
To: development@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Morten Sorvig]

> On 9 Dec 2016, at 12:11, Laszlo Agocs  wrote:
> 
> There are two separate things in there, though: the entry point and the 
> construction of the Q(Core|Gui)Application object. The problem is with the 
> latter: is it not clear why Morten’s proposal moves that under the 
> framework’s control. Introducing a new entry point, e.g. qtMain(), for all 
> platforms in Qt 6 is fine. Moving the application object construction into 
> the underlying platform-specific entry point Qt provides is not.


The reasoning was that QApplication management ended up as boilerplate code, so 
let’s simplify. This is especially true if the application type has already 
been selected via a macro.

Keeping support for setting options before creating the application object is a 
very good argument for letting user code control it though.

Morten



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Morten Sorvig]

> On 9 Dec 2016, at 11:41, Laszlo Agocs  wrote:
> 
>  
> 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. 
> 


>  
> 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.

I think we should have one primary way to handle app init though, which would 
be mentioned first in the documentation and which most of the examples use. So 
I would prefer to keep the current API if we can’t find a new primary API.

Morten
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Morten Sorvig]

> On 9 Dec 2016, at 14:51, Andre Poenitz  wrote:
> 
> 
> Whatever the problem is, I think we should try hard to have a solution 
> that 1. does not use macros and 2. that does not optically change the 
> int main(int argc, char *argv[]) { QApplication app(argc, argv)... } stanza.

This sounds like the current approach, where we solve the startup issue by
adding complexity to the Qt platform implementation that allows us to keep 
main().

The suggested approach would solve the issue by changing the API, and the
motivation is a simplification of the Qt platform implementation. So the
benefit is perhaps not immediately clear to those not directly involved
with Qt platform development, except for the potential for faster developed,
more stable Qt.

> 
> Macros look and feel ugly and outdated in contemporary C++, are harder 
> to debug, etc etc. Changing away from a normal main will make look Qt
> code alien, not to mention the necessary adaptation in documentation
> and each and every "getting started with Qt" tutorial out there. This would
> be a high price to pay.

Indeed if keeping the normal main (and docs etc) is very important then
that could tip the scales over to not making API changes.

Morten
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Matthew Woehlke]

On 2016-12-09 04:35, Morten Sorvig wrote:
> We should consider changing the way Qt initialization and startup works.
> This is something I’ve personally been wanting to do for some time, and
> a recent offline discussion pushed it on my stack again.
> 
> Currently, Qt and application startup looks something like this:
> 
>   int main(int argc, char **argv)
>   {
>   QApplication app(argc, argv);
> 
>   // Create root user objects/windows here
> 
>   return app.exec();
>   }
> 
> We can continue with the workarounds, but they lead to complications in Qt
> platform code and are also an extra hurdle for implementing support for new
> platforms, so from the Qt platform development point of view it is desirable
> with a cleanup. 
> 
> This would be an “all applications should/must port” event, not to be taken 
> lightly. I think the porting would be trivial in many (if not most) cases,
> but some apps have special requirements for QApplication object management
> or main thread ownership. This includes our own QTestLib.

One concern I have is if users are monkeying with argc/argv prior to
constructing a QApplication instance. IIRC, KDE used to do this (not
sure if they still do), and qtCliArgs¹ does this also. This allows, for
instance, enforcing a consistent argument naming policy that differs
from Qt's own policy, while still being able to pass Qt CLI arguments.

Also, how does this work if someone wants to subclass Q*Application?
(Again, I have projects that do that...)

(¹ https://github.com/Kitware/qtextensions/blob/master/core/qtCliArgs.h)

-- 
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Thiago Macieira]

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.

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?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Thiago Macieira]

Em sexta-feira, 9 de dezembro de 2016, às 11:10:15 PST, Matthew Woehlke 
escreveu:
> Also, how does this work if someone wants to subclass Q*Application?
> (Again, I have projects that do that...)

But why do they do that?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Konstantin Tokarev]

09.12.2016, 20:11, "Thiago Macieira" :
>  Em sexta-feira, 9 de dezembro de 2016, às 11:10:15 PST, Matthew Woehlke
>  escreveu:
>>   Also, how does this work if someone wants to subclass Q*Application?
>>   (Again, I have projects that do that...)
>
>  But why do they do that?


To override virtual methods, like notify()

>  --
>  Thiago Macieira - thiago.macieira (AT) intel.com
>    Software Architect - Intel Open Source Technology Center
>
>  ___
>  Development mailing list
>  Development@qt-project.org
>  http://lists.qt-project.org/mailman/listinfo/development


-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Thiago Macieira]

Em sexta-feira, 9 de dezembro de 2016, às 20:13:57 PST, Konstantin Tokarev 
escreveu:
> 09.12.2016, 20:11, "Thiago Macieira" :
> >  Em sexta-feira, 9 de dezembro de 2016, às 11:10:15 PST, Matthew Woehlke
> > 
> >  escreveu:
> >>   Also, how does this work if someone wants to subclass Q*Application?
> >>   (Again, I have projects that do that...)
> > 
> >  But why do they do that?
> 
> To override virtual methods, like notify()

Ok, that's no longer a valid reason because we'll deprecate that practice in 
Qt 6.

Any other reasons?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Matthew Woehlke]

On 2016-12-09 12:10, Thiago Macieira wrote:
> Em sexta-feira, 9 de dezembro de 2016, às 11:10:15 PST, Matthew Woehlke 
> escreveu:
>> Also, how does this work if someone wants to subclass Q*Application?
>> (Again, I have projects that do that...)
> 
> But why do they do that?

...because I have a number of executables which share logic, and it
seemed like the obvious thing to do. (It saves having to create an
entirely separate singleton that interacts closely with QApplication.)

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.

-- 
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Thiago Macieira]

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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Matthew Woehlke]

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.

-- 
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A new approach for Qt main()

[Thiago Macieira]

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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Tagging private symbols as such

[Lisandro Damián Nicanor Pérez Meyer]

On jueves, 8 de diciembre de 2016 02:02:36 ART Kevin Kofler wrote:
> Dmitry Shachnev wrote:
> > I also dislike this change. As Lisandro says, we do not want it in Debian
> > (because we keep track of versions ourselves in the symbols file, and when
> > the versions are in the symbols themselves they are just useless noise for
> > us). And as you say, you do not want distributions Qt builds to be ABI
> > incompatible with upstream (we also would like to avoid that), so if this
> > patch gets applied upstream, we will be in a bad situation.
> > 
> > I wonder what was the reason for OpenSUSE to have this change — I could
> > not find a relevant changelog entry. Why cannot they just rebuild all
> > packages using private headers for every Qt release, like we do?
> 
> See my replies: RPM tracks symbol versions, but not the actual names, e.g.,
[snip]

Thanks for clarifying the issue, this was neither inmediately clear to me.
 
> The difference in implementation compared to the Qt_5.x symbol versions
> would be that the private symbols would of course NOT provide the older
> symbol versions, only the latest one, making it effectively an = dependency
> rather than a >= one.

Right.

> RPM explicitly does NOT track individual symbols as Debian tooling
> apparently does.

And once again, right (although we can later force the last version to be the 
final one). And this is exactly where our tooling would make our lives not 
easy if the above gets implemented.

So, as I've said before, there is a valid use case for this, although if 
implemented we might need to avoid it for some time, hopefully not too long.

Thiago: should I push to gerrit the complete patch as it is or just the QPA 
stuff on one patch and the private symbols versioning on another? And to what 
branch exactly?

-- 
2: Windows con las funciones que realiza se clasifica como:
* Un bug
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Tagging private symbols as such

[Thiago Macieira]

Em sexta-feira, 9 de dezembro de 2016, às 23:23:50 PST, Lisandro Damián 
Nicanor Pérez Meyer escreveu:
> Thiago: should I push to gerrit the complete patch as it is or just the QPA
> stuff on one patch and the private symbols versioning on another? And to
> what branch exactly?

Please split. They do completely different things.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development