Re: [Development] Tagging private symbols as such

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

Re: [Development] Tagging private symbols as such

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

> 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()

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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:

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.

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

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

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

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

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

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

[Development] A new approach for Qt main()

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,