[Development] new Qt 5.8.0 rc snapshot available
Hi all, We have new snapshot for testing Linux: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/596/ Mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/664/ Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/689/ src: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/latest_src/ Packages are based on https://codereview.qt-project.org/#/c/179514/ . Packages are RTA smoke tested and everything seems to be mostly OK so please test the packages to see if we are ready for RC or not. Please make sure all open blockers are visible in https://bugreports.qt.io/issues/?filter=18053. We are trying to get rc out still before Christmas so please fix all found blockers immediately! And remember, no any nice-to-have's in '5.8.0' anymore! br, Jani Heikkinen Release Manager ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [Announce] Qt 5.7.1 and Qt Creator 4.2 released
Hi, I am happy to inform that Qt 5.7.1 and Qt Creator 4.2 are released today, see more info from http://blog.qt.io/blog/2016/12/14/qt-5-7-1-released/ and http://blog.qt.io/blog/2016/12/14/qt-creator-4-2-released/ Big thanks to everyone involved! br, Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikki...@qt.io +358 50 4873735 http://qt.io ___ Announce mailing list annou...@qt-project.org http://lists.qt-project.org/mailman/listinfo/announce ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new Qt 5.8.0 rc snapshot available
Hi, any plans on adding qtwayland to these packages as well ? Dominik Am 12/14/2016 um 11:56 AM schrieb Jani Heikkinen: > Hi all, > > We have new snapshot for testing > > Linux: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/596/ > Mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/664/ > Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/689/ > src: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/latest_src/ > > Packages are based on https://codereview.qt-project.org/#/c/179514/ . > Packages are RTA smoke tested and everything seems to be mostly OK so please > test the packages to see if we are ready for RC or not. Please make sure all > open blockers are visible in https://bugreports.qt.io/issues/?filter=18053. > > We are trying to get rc out still before Christmas so please fix all found > blockers immediately! And remember, no any nice-to-have's in '5.8.0' anymore! > > br, > Jani Heikkinen > Release Manager > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Dominik Holland SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany +49 (0)171 760 25 96 dominik.holl...@pelagicore.com www.pelagicore.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A new approach for Qt main()
On 2016-12-09 19:43, Thiago Macieira wrote: > 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: >>> 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. If we're not deprecating the traditional main(), that WFM. (That's not how I read the initial post, however...) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A new approach for Qt main()
> On 13 Dec 2016, at 14:51, Edward Welbourne wrote:
>
> Morten Sorvig supplied:
>
>> For some background, here’s what typical application startup looks
>> like on macOS, NaCl, and Emscripten:
>
> I've updated [0] to illustrate these.
> [0] https://wiki.qt.io/Application_Start-up_Patterns
Thanks!
>
>> macOS: Define the application delegate, create instance of it in main()
>>
>> // Define application delegate with app lifecycle callbacks
>> @interface AppDelegate ()
>> @end
>>
>> @implementation AppDelegate
>> - (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
>> // Init application here
>> }
>>
>> - (void)applicationWillTerminate:(NSNotification *)aNotification {
>> // Tear down here
>> }
>> @end
>
> Please say more about what has to happen in these, especially init;
> presumably, we need to add some handlers to something like an event
> queue, to ensure our application gets told what's happening and when to
> respond to it.
You are correct. On the highest level, the “Init” code would be:
g_application = new QGuiApplicaiton()
// Init application (create app windows etc)
This gives us a nice ordered startup: The native platform has been initialized,
we initialize Qt, and then call application initialization code.
Digging into QGuiApplicaiton construction, it will among other things select
and load a platform plugin, and then ask that platform plugin to create an
event dispatcher, which hooks into the native event queue.
The Qt event dispatcher implementation on macOS supports integrating with
an already running event loop, which is the case here. Calling app.exec()
is not required (and would not work in the callback).
Morten
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
