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
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. We
Hello Lars,
Am 17.06.2015 um 12:27 schrieb Knoll Lars lars.kn...@theqtcompany.com:
* 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
Am 16.06.2015 um 22:49 schrieb Ziller Eike eike.zil...@theqtcompany.com:
On Jun 16, 2015, at 16:52, Matthew Woehlke mw_tr...@users.sourceforge.net
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
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 even
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
On Tue, Jun 16, 2015 at 10:49 PM, Thiago Macieira
thiago.macie...@intel.com 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* will be the first LTS release.
Mind to elaborate? Why is the old Qt CI a requirement or a
On Wednesday 17 June 2015 08:33:50 Giuseppe D'Angelo wrote:
On Tue, Jun 16, 2015 at 10:49 PM, Thiago Macieira
thiago.macie...@intel.com 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* will be the first LTS release.
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
thiago.macie...@intel.com wrote:
Qt 5.5 would be ideal - but we'd need to
On 17/06/15 09:21, Dmitry Shachnev mitya57...@gmail.com 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
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 q...@csipa.in.rs a écrit :
Hi,
A huge +1 on this, BT support on Windows is
On Wed, Jun 17, 2015 at 9:15 AM, Thiago Macieira
thiago.macie...@intel.com 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...
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
* QNX 6.5
* Qt WebKit, Qt Script, Qt Quick 1
Ok, I understand that
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 will
be
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
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 developed in
Ok, given these extra votes, I've just submitted the removal right now and for
5.5.0:
https://codereview.qt-project.org/114503
On Wednesday 17 June 2015 05:33:34 Knoll Lars wrote:
Yes, let's remove them. The font files shouldn't be part of qtbase for sure.
We might still decide to package up
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
* QNX 6.5
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
thiago.macie...@intel.com wrote:
Qt 5.5 would be ideal - but we'd need to support the old Qt CI system for
longer. So we're targetting
-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 duplicate
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.
On 17/06/15 10:34, Giuseppe D'Angelo dange...@gmail.com wrote:
On Wed, Jun 17, 2015 at 9:15 AM, Thiago Macieira
thiago.macie...@intel.com 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
On 17/06/15 12:34, André Somers an...@familiesomers.nl 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é
*)
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 16/06/15 23:19, Stephen Kelly steve...@gmail.com 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
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 of Qt
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 write code
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
* metatype
On Wed, Jun 17, 2015 at 10:44:38AM +, Knoll Lars wrote:
On 17/06/15 12:34, André Somers an...@familiesomers.nl 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
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
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
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 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 the
33 matches
Mail list logo
