Hi all,
We have finally Qt 5.5.0 RC packages available
Windows: http://download.qt.io/snapshots/qt/5.5/5.5.0-rc/2015-06-17_95/
Linux: http://download.qt.io/snapshots/qt/5.5/5.5.0-rc/2015-06-17_118/
Mac: http://download.qt.io/snapshots/qt/5.5/5.5.0-rc/2015-06-17_98/
src: http://download.qt.io
> On Thursday 18 June 2015 08:23:52 Gunnar Roth wrote:
> > > Am 17.06.2015 um 22:35 schrieb Thiago Macieira
> > > :
> > >
> > > On Wednesday 17 June 2015 19:30:25 Gunnar Roth wrote:
> > >> Yes that would make us (as a commercial user using a self made
> > >> port of qt
> > >> 5.4.1 to wec2013 ) ve
On Thursday 18 June 2015 08:23:52 Gunnar Roth wrote:
> > Am 17.06.2015 um 22:35 schrieb Thiago Macieira
> > :
> >
> > On Wednesday 17 June 2015 19:30:25 Gunnar Roth wrote:
> >> Yes that would make us (as a commercial user using a self made port of
> >> qt
> >> 5.4.1 to wec2013 ) very unhappy. Thi
> Am 17.06.2015 um 22:35 schrieb Thiago Macieira :
>
> On Wednesday 17 June 2015 19:30:25 Gunnar Roth wrote:
>> Yes that would make us (as a commercial user using a self made port of qt
>> 5.4.1 to wec2013 ) very unhappy. This means 5.6 will be the last version
>> wec2013 would be supported and
On Wednesday 17 June 2015 19:30:25 Gunnar Roth wrote:
> Yes that would make us (as a commercial user using a self made port of qt
> 5.4.1 to wec2013 ) very unhappy. This means 5.6 will be the last version
> wec2013 would be supported and you would go straight to making a back port
> very hard or e
Knoll Lars wrote:
> * Generic and duplicated names from different namespaces can
> easily lead to confusion when reading code.
... and when searching about information about a class by unqualified name.
'QTransform' is now ambiguous to google. If the namespace route is used for
existing modules
> Am 16.06.2015 um 22:49 schrieb Ziller Eike :
>
>
>> On Jun 16, 2015, at 16:52, Matthew Woehlke
>> wrote:
>>
>> On 2015-06-12 17:45, Thiago Macieira wrote:
>>> On Friday 12 June 2015 10:49:38 Matthew Woehlke wrote:
> On Friday 12 June 2015 08:08:51 André Somers wrote:
>> Not availabl
Hello Lars,
> Am 17.06.2015 um 12:27 schrieb Knoll Lars :
>
> * We make Qt 5.6 an LTS release
> * We could then have both WEC7 and WEC2013 (on VS2012) supported on 5.6.
> This would solve all problems for Windows Embedded and we could make
> VS2013 the compiler baseline for 5.7.
> we’d keep peopl
On Wednesday 17 June 2015 18:50:14 André Pönitz wrote:
> Would be possible to freeze 5.6 right now, and release that quickly
> after 5.5 as LTS, already running on the new CI, and do whatever
> else was originally planned for 5.6 in 5.7?
I don't think we can do two releases in the next 7 months. W
On Wed, Jun 17, 2015 at 07:31:19AM -0700, Thiago Macieira wrote:
> On Wednesday 17 June 2015 10:34:39 Giuseppe D'Angelo wrote:
> > > Since 5.5 LTS is an impossibility, the only alternative to minimising the
> > > issues is to push the deprecations to 5.7 and do one more "official"
> > > release of
I would like to see Qt Bluetooth support back to Windows 7. However I agree
work priority should be focused on Windows mobile devices.
For Windows 7 support I had to write an abstraction layer for Bluetooth that is
implemented using Winsock 2.2.
If Windows 10 and mobile devices drop support fo
On Wednesday 17 June 2015 10:34:39 Giuseppe D'Angelo wrote:
> > Since 5.5 LTS is an impossibility, the only alternative to minimising the
> > issues is to push the deprecations to 5.7 and do one more "official"
> > release of the to-be-deprecated code in 5.6.
>
> I would agree to this plan; we can
On Wed, Jun 17, 2015 at 10:44:38AM +, Knoll Lars wrote:
> On 17/06/15 12:34, "André Somers" wrote:
>
> >Knoll Lars schreef op 17-6-2015 om 12:27:
> >> * We’d still remove the deprecated modules from our Qt 5.6 release
> >>(maybe
> >> with the exception of Qt Script).
> >Is that really needed?
On Wednesday 17 June 2015 14:54:03 Daniel Teske wrote:
> > Curiously, you didn't list any pro-namespace arguments.
>
> Actually:
> >> We couldn’t make things work in a source compatible way.
not a pro argument
> >> * connect statements are hard with namespaces.
not a pro argument
> >> * meta
> Curiously, you didn't list any pro-namespace arguments.
Actually:
>> We couldn’t make things work in a source compatible way.
>> * connect statements are hard with namespaces.
>> * metatype registration is problematic with namespaced types
>> * One of our coding guidelines is that you writ
> That side might be the vocal majority, too, tramping over the silent majority,
> since I note that QtC is full of namespaces.
>
> Roughly one per library after a quick grep.
>
> If name prefixing is The Way To Go, I wonder why QtC, as the biggest internal
> consumer, and second-biggest producer o
On Wednesday 17 June 2015 12:56:54 Knoll Lars wrote:
[...]
> * connect statements are hard with namespaces. Old style connects could
> easily break if you forgot to fully qualify a parameter. New style
> connects might end up with rather ugly looking syntax.
This is nothing new. We have that for n
On 16/06/15 23:19, "Stephen Kelly" wrote:
>Stephen Kelly wrote:
>
>>> I said I'm happy to discuss. I'm just waiting for some more opinions,
>>> please don't take that as me trying to shut the discussion down. :)
>>
>> Cool. Let's wait and see.
>
>This thread has gone way off-topic now, but we ga
On 17/06/15 12:34, "André Somers" wrote:
>Knoll Lars schreef op 17-6-2015 om 12:27:
>> * We’d still remove the deprecated modules from our Qt 5.6 release
>>(maybe
>> with the exception of Qt Script).
>Is that really needed? For all of the modules? Could Quick 1 stay too?*
>
>André
> *) Yes, we h
Knoll Lars schreef op 17-6-2015 om 12:27:
> * We’d still remove the deprecated modules from our Qt 5.6 release (maybe
> with the exception of Qt Script).
Is that really needed? For all of the modules? Could Quick 1 stay too?*
André
*) Yes, we have a stake in that: The printing case.
___
Going through the discussions and looking at our time schedule, here’s
another proposal how we could do things (slightly different from what we
discussed at QtCS):
* We make Qt 5.6 an LTS release
* We already have of the current dev branch on pretty much all platforms
supported in Qt 5.5 working i
> -Original Message-
> From: development-bounces+kai.koehne=theqtcompany.com@qt-
> [...]
> So I recommend we begin the shift now in 5.6 and deprecate the old
> methods, to be removed in 6.0.
>
> As for the implementation, please connect one signal to the other, so we
> don't need to dupli
Giuseppe D'Angelo schreef op 17-6-2015 om 10:34:
> I would also push the "C++11 in our API" to 5.7 to minimise the risks.
> Cheers,
C++11 in our API was to be taken slowly anyway, according to the session
at QtCS. We would start with using it in the implementation to gain some
experience first.
On 17/06/15 10:34, "Giuseppe D'Angelo" wrote:
>On Wed, Jun 17, 2015 at 9:15 AM, Thiago Macieira
> wrote:
>>
>> Two different CI implementations. The "new CI" is being developed in
>>lockstep
>> with Qt 5.6, including QtTest features. That means the "new CI" system
>>cannot
>> be backported to 5.5
On Wed, Jun 17, 2015 at 9:15 AM, Thiago Macieira
wrote:
>
> Two different CI implementations. The "new CI" is being developed in lockstep
> with Qt 5.6, including QtTest features. That means the "new CI" system cannot
> be backported to 5.5.
Ok, thanks for explaining this out...
> In turn, to ke
Hello,
I totally +1 this feature !
However if I'm not mistaking, focusing on WinRT api discards MinGW
compiler, that's bad news for open source tools.
Best regards,
Eric
Le mar. 16 juin 2015 à 15:35, Attila Csipa a écrit :
> Hi,
>
> A huge +1 on this, BT support on Windows is long overdue.
>
Thiago Macieira schreef op 17-6-2015 om 09:15:
> On Wednesday 17 June 2015 09:01:19 André Somers wrote:
>> Does the CI infrastructure depend on the Qt version then? What is it
>> about 5.5 that prevents the CI from being upgraded?
> Two different CI implementations. The "new CI" is being develope
On 17/06/15 09:21, "Dmitry Shachnev" wrote:
>Hi J-P,
>
>On Tue, 16 Jun 2015 17:44:06 +, Nurmi J-P wrote:
>> Given that QGtkStyle is no longer part of the public API in Qt 5, how
>>about
>> making it a QStylePlugin and moving it out of QtWidgets? If someone
>> implements a style plugin for GTK
Hi J-P,
On Tue, 16 Jun 2015 17:44:06 +, Nurmi J-P wrote:
> Given that QGtkStyle is no longer part of the public API in Qt 5, how about
> making it a QStylePlugin and moving it out of QtWidgets? If someone
> implements a style plugin for GTK+ 3, then it also becomes feasible to have
> platform
On Wednesday 17 June 2015 09:01:19 André Somers wrote:
> Thiago Macieira schreef op 17-6-2015 om 08:57:
> > On Wednesday 17 June 2015 08:33:50 Giuseppe D'Angelo wrote:
> >> On Tue, Jun 16, 2015 at 10:49 PM, Thiago Macieira
> >>
> >> wrote:
> >>> Qt 5.5 would be ideal - but we'd need to support th
On Tue, Jun 16, 2015 at 01:48:07PM -0700, Thiago Macieira wrote:
> On Tuesday 16 June 2015 21:57:53 Giuseppe D'Angelo wrote:
> > > * Qt 5.6 will deprecate: QNX 6.5 (QNX 6.6 OK)
> > > * Qt 5.6 will deprecate WEC 7, 2013 only.
> >
> > Deprecate or drop them? From the C++11 thread I understood they w
On Tuesday, June 16, 2015 01:49:54 PM Thiago Macieira wrote:
[...]
> Other notes:
> * We will keep a Linux builder building 32-bit to make sure everything
> works - *no binary packages for Linux 32-bit*
We do have at least one Linux builder today that targets armv7, but AFAICS
that is the o
On Wednesday 17 June 2015 08:35:58 André Somers wrote:
> Thiago Macieira schreef op 16-6-2015 om 22:49:
> > Last year's notes[1]
> >
> > Qt 5.5 will be the last release to support:
> > * GCC 4.6
> > * OS X 10.7
> > * Windows Vista
> > * WIndows Embedded Compact 7
> >
Thiago Macieira schreef op 17-6-2015 om 08:57:
> On Wednesday 17 June 2015 08:33:50 Giuseppe D'Angelo wrote:
>> On Tue, Jun 16, 2015 at 10:49 PM, Thiago Macieira
>>
>> wrote:
>>> Qt 5.5 would be ideal - but we'd need to support the old Qt CI system for
>>> longer. So we're targetting that *Qt 5.6*
34 matches
Mail list logo
