[Development] Qt 5.5.0 RC packages available

[Heikkinen Jani]

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/snapshots/qt/5.5/5.5.0-rc/latest_src/


Please check the packages now. If nothing serious found during testing we will 
release these packages as RC at the beginning of next. So please inform me 
immediately if you find something broken & blocking the RC


br,

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

Re: [Development] QtCS: Long Term Release discussion

[Kalinowski Maurice]

> 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. 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 impossible.
> > >
> > > WEC 2013 was never considered deprecated. The deprecation applies to
> > > WEC 7 only.
> >
> > Well ok, but how does Lars Knoll’s sentence  "we could make
> > VS2013 the compiler baseline for 5.7.“ fit into this? As the only
> > supported compiler for wec2013 is a cl with  v 17.00 aka vs2012.
> 
> Apparently VS2013 can also be used for WEC2013.

 [Kalinowski Maurice] 
Correct, check the discussion here: 
https://codereview.qt-project.org/#/c/113276/

As a summary, SDK makers / board vendors can select to include the VS2013 
compiler into their package even though the IDE is VS2012 based. However, that 
puts quite some requirement on the vendor side and that needs to be evaluated.

Maurice

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

Re: [Development] QtCS: Long Term Release discussion

[Thiago Macieira]

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. 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 impossible.
> > 
> > WEC 2013 was never considered deprecated. The deprecation applies to WEC 7
> > only.
> 
> Well ok, but how does Lars Knoll’s sentence  "we could make
> VS2013 the compiler baseline for 5.7.“ fit into this? As the only supported
> compiler for wec2013 is a cl with  v 17.00 aka vs2012.

Apparently VS2013 can also be used for WEC2013.
-- 
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] QtCS: Long Term Release discussion

[Gunnar Roth]

> 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 you would go straight to making a back port
>> very hard or even impossible.
> 
> WEC 2013 was never considered deprecated. The deprecation applies to WEC 7 
> only.


Well ok, but how does Lars Knoll’s sentence  "we could make
VS2013 the compiler baseline for 5.7.“ fit into this? As the only supported 
compiler for wec2013 is a cl with  v 17.00 aka vs2012. 


Regards, 
Gunnar

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

Re: [Development] QtCS: Long Term Release discussion

[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 you would go straight to making a back port
> very hard or even impossible.

WEC 2013 was never considered deprecated. The deprecation applies to WEC 7 
only.
-- 
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] Some Qt3D feedback

[Stephen Kelly]

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 in the future (for consistency for example), then we'll end 
up with lots more of that: 'QNode' in the 'QSG' and 'Qt3D' namespaces, 
'QComponent' in the 'QQml' and 'Qt3D' namespaces etc.

I don't at all buy the argument that IDEs can know and show the fully 
qualified name and there is therefore no problem. A lot of the time people 
are reading code on websites/github/gerrit/code review tools/Stack Overflow 
etc and those typically do not provide context, except if by chance.

> * class name prefixing is a widely used and understood scheme by our
> users. Do we really want an inconsistency now in one place? I don’t think
> we have enough arguments to actually go down that route.

Right. That's exactly what started this thread.

> So what do we do with Qt 3D? For 5.5, we’re too late to do any changes.

I do not see the logic in the claim that it is too late for Qt 5.5 but not 
too late for Qt 5.6.

> But we’re talking about a Tech Preview here, so we can use it to collect
> some feedback on the namespace usage in there. We will however need to
> decide rather quickly whether we want to keep it or revert to regular Qt
> style class name prefixing for 5.6. I’m currently leaning towards the
> latter.

I agree with ossi that it is unrealistic/dishonest to expect a name 
consistency change like this to be done after the Qt 5.5 release. I will be 
extremely surprised if something like this changes after Qt 5.5 and before 
Qt 5.6. With the help of some sed :) :

 We couldn’t make things work in a source compatible way. Moving from 
 Qt3D::QTransform to Q3DTransform is not something you could do in a 
 transparent way. We could think about using a 'typedef Q3D::QTransform 
 QTransform’ for compatibility. But it would break things such as forward 
 declarations and typedefs.

The 'technical preview' label won't help. No one will treat the new module 
any differently. You will not be able to change the names. 

You wouldn't even bump the version of Enginio to fix the multitude of 
inconsistencies in that, even though the different version of it was 
*supposed* to make such changes and repairs possible. I don't see any way 
you would change all these Qt3D names.

But at least we'll get some years of experience and possibly feedback on the 
issue, and find a direction to go for consistency later.

*** Change of topic.

It seems that most people, but not everyone, in the discussion see the 
inconsistency and there are good reasons that it is not a good thing. It is 
also clear that now is not the right time to discuss those reasons, because 
we are discussing a decision that was made and committed to already in the 
past, instead of discussing something proposed for the future. 

The reasons for changing the use of the namespace were not compelling enough 
in their own to impel change when I first raised them a week ago. We needed 
a week for people to come out of the woodwork and give their view on whether 
there is inconsistency introduced (not everyone sees inconsistency here) and 
whether that is a good or bad thing.

This is another indication (in addition to the fact that new modules are not 
part of headerdiff review) that Qt probably needs to do some thinking about 
how new modules are discusssed/reviewed, so that these things can be 
resolved when there is time to discuss them calmly. 

Thanks,

Steve.


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

Re: [Development] QtCS: Notes from Modern C++ session

[Gunnar Roth]

> 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 available for use are:
>> * = default,
>> * = deleted,
 
> 
> Actually this is not supported in VS2012
> https://msdn.microsoft.com/en-us/library/hh567368.aspx
> 
> And Thiago’s link actually lists it under VS2013 as well :)
> 
> http://code.woboq.org/qt5/qtbase/src/corelib/global/qcompilerdetection.h.html#851
Thanks Eike, saved my writing that myself.
I thought Thiago is testing me somehow… ;-)

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

Re: [Development] QtCS: Long Term Release discussion

[Gunnar Roth]

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 people on older compilers/OSes happy and we could move
> a lot more aggressively towards C++11 in the dev branch directly after
> summer vacations (from the beginning of August).
> 
> Opinions?
> 
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 impossible. Actually we somehow assumed on vs2012  being supported 
for Qt 5. As we use Qml/QtQuick we would be cut off of this development.

Regards,
Gunnar

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

Re: [Development] QtCS: Long Term Release discussion

[Thiago Macieira]

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 discussed 
shortening release cycles again in QtCS but the conclusion was "let's look 
into this after the new CI is in place".

Anyway, the main point of decision is whether we want an LTS containing stuff 
effectively deprecated. That means maintaining it for a long period, which we 
don't want and don't have the manpower for.

It would be the ideal solution, but I simply don't think we could pull it off. 
Tough luck.

-- 
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] QtCS: Long Term Release discussion

[André Pönitz]

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 to-be-deprecated code in 5.6.
> > 
> > I would agree to this plan; we can deprecate platforms we don't want
> > to support long term in 5.5 already, though, which is what has
> > happened with QNX. Maybe old OSX as well? GCC 4.4?
> 
> Note that doing this means we'll be out-of-sync with the next Ubuntu LTS, 
> which was one of the goals. We'll be late by a couple of months, which means 
> the next opportunity won't come for another 18 months.

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?

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

Re: [Development] Bluetooth support for Windows (RT/10) in Qt 5.6

[Edward Sutton]

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 for Windsock 2.2, then I totally 
understand not having the resource for Qt to support all Windows platforms.

-Ed



On Jun 17, 2015, at 3:33 AM, Eric Lemanisser 
mailto:eric.lemaniss...@gmail.com>> wrote:

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 
mailto:q...@csipa.in.rs>> a écrit :
Hi,

A huge +1 on this, BT support on Windows is long overdue.

While there is certainly more inertia in the windows desktop version
than probably any other Qt supported platform, Microsoft itself is
trying to nudge people into quicker upgrade cycles, and while Win8 has
certainly gotten a pushback, with Win10 around the corner I would also
try not to get bogged down with pre-WinRT solutions, as painful as that
might sound in some cases.

Best regards,
Attila

On 6/16/2015 1:42 PM, Kalinowski Maurice wrote:
> Hi everyone,
>
> It might sound weird that while we're trying to get 5.5.0 out I am starting a 
> discussion about Qt 5.6, but if you look at the release schedule there is not 
> much time for the feature freeze
>
> https://wiki.qt.io/Qt-5.6-release
>
> One of the items the Windows / WinRT team would really like to see included 
> to that release is support for Bluetooth and BTLE.
>
> The current idea is to use the WinRT API for that backend, as it provides the 
> advantage that it can also be used on Windows Desktop starting Windows 8(.1). 
> WinRT covers Windows 10 support (both classic and Unified Windows Platform) 
> as well.
>
> This leaves out support for Windows Desktop older than Windows 8. But as we 
> are aiming to implement new features, we should draw the line somewhere and 
> the WinRT backend clearly has the biggest potential to be supported in many 
> years' time, while the (or multiple) pure desktop solution would be 
> deprecated sooner or later again. Also given the fact that we can target 
> quite many platforms with one backend gives us a better coverage for 
> maintenance and resourcing.
>
> The reason that I am mentioning this on the mailing list is that after 
> talking to some folks here in The Qt Company, multiple people inside and 
> outside already started or wanted to start efforts on this topic. Hence the 
> aim of this email is to get everyone connected and work on it together to 
> make it happen within the 5.6 feature freeze.
>
> So, if you have worked on Bluetooth (LE) on Windows or want to, please get in 
> touch with me to align.
>
>
> BR,
> Maurice
>
>
> 
> Maurice Kalinowski - Senior Manager, Qt Tools
>
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
> Gesellschaft:
> Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
>
> Email: 
> maurice.kalinow...@theqtcompany.com
>  | Mobile: + 49 175 187 19 52 | Phone:
> +49 30 63 92 3255 www.qt.io |Qt Blog: 
> http://blog.qt.digia.com/ | Twitter:
> @QtbyDigia, @Qtproject | Facebook: 
> www.facebook.com/qt
>
>
> ___
> 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

This email and any files transmitted with it from The Charles Machine Works, 
Inc. are confidential and intended solely for the use of the individual or 
entity to which they are addressed. If you have received this email in error 
please notify the sender. Our company accepts no liability for the contents of 
this email, or for the consequences of any actions taken on the basis of the 
information provided, unless that information is subsequently confirmed in 
writing. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, the recipient should check this email and any attachments for 
the presence of viruses. The company accepts no liability for any damage caused 
by any virus transmitted by this email.
___
Development mailing list
Development@qt-project.org
http:

Re: [Development] QtCS: Long Term Release discussion

[Thiago Macieira]

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 deprecate platforms we don't want
> to support long term in 5.5 already, though, which is what has
> happened with QNX. Maybe old OSX as well? GCC 4.4?

Note that doing this means we'll be out-of-sync with the next Ubuntu LTS, 
which was one of the goals. We'll be late by a couple of months, which means 
the next opportunity won't come for another 18 months.

> I would also push the "C++11 in our API" to 5.7 to minimise the risks.

That's the least of the problems. The deprecations, especially of Qt Quick 1 
and QtWebKit, are what people will be complaining about.

-- 
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] QtCS: Long Term Release discussion

[Oswald Buddenhagen]

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? For all of the modules? Could Quick 1 stay too?*
> >
> >André
> >  *) Yes, we have a stake in that: The printing case.
> 
> As Thiago said, you could still easily use the module on your own. The
> code will not suddenly dissappear from the universe. And we had some
> discussions about how to fix the printing case in Qt Quick 2.
> 
tbh, i think thiago is a bit optimistic. the build system has several
files that are internal, and keeping them compatible between releases is
a burden.

the other argument is that it doesn't seem very wise to take the parts
that are effectively still part of the LTS entirely out of our testing
systems. especially as with the new CI, having these modules still in
shouldn't add much cost to the release process.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Some Qt3D feedback

[Marc Mutz]

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 registration is problematic with namespaced types

not a pro argument

> >> * One of our coding guidelines is that you write code once, but read it
> >> many times. Code written should be as self explaining as possible.
> >> Having generic class names inside an implicit namespace makes this
> >> difficult, as information is not fully local anymore

not a pro argument

> >> * class name prefixing is a widely used and understood scheme by our
> >> users.

not a pro argument

> You think you have countered all of them. But to claim that there were no
> pro- namespace arguments is just wrong.

Actually: no pro arguments.

What's your point?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Some Qt3D feedback

[Daniel Teske]

> 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 once, but read it
>> many times. Code written should be as self explaining as possible. Having
>> generic class names inside an implicit namespace makes this difficult, as
>> information is not fully local anymore 
 
>> * class name prefixing is a widely used and understood scheme by our
>> users.

You think you have countered all of them. But to claim that there were no pro-
namespace arguments is just wrong. 


> But after all I read from the proponents of name prefixing so far, we rather
> need to send the whole QtC bunch to the asylum because they've clearly
> backed themselves into a corner and can't possibly understand their code
> anymore. :)

As a Qt Creator developer, I wouldn't recommend making the Qt API inconsistent 
wiht itself by introducing namespaces into a module now. 

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

Re: [Development] Some Qt3D feedback

[Ulf Hermann]

> 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 API, didn't choose it for its own
> internal structure...?

Most of those classes are namespaced and prefixed at the same time. We probably 
all agree that we've successfully chosen the worst of both worlds there. Don't 
use that as reference, please.

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

Re: [Development] Some Qt3D feedback

[Marc Mutz]

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 nested classes and enums already, as 
well as typedefs. If you ban namespaces based on this, you need to ban nested 
types (e.g. error enums), too.

> * metatype registration is problematic with namespaced types, as the macro
> extracts the name of the type through the preprocessor. People can very
> easily end up registering the type multiple times with different
> (qualified vs non qualified) names.

Same counter-arguments as above, but Q_DECLARE_METATYPE with namespaces is 
actually easily fixed by internally prepending ::, thus making sure the 
argument is a fully-qualified name.

> * One of our coding guidelines is that you write code once, but read it
> many times. Code written should be as self explaining as possible. Having
> generic class names inside an implicit namespace makes this difficult, as
> information is not fully local anymore (you have to know that there’s a
> using directive at the beginning of the file to find the proper qualified
> class name). Generic and duplicated names from different namespaces can
> easily lead to confusion when reading code. (btw, this is also an argument
> against over-using auto)

Purely subjective, and highly controversial in the wider C++ community (with 
the controversity mainly between Qt and the rest of C++, afaict).

> * class name prefixing is a widely used and understood scheme by our
> users. Do we really want an inconsistency now in one place? I don’t think
> we have enough arguments to actually go down that route.

Show me one C++ library not of Qt origin that uses class name prefixes not due 
to backwards compatibility concerns.

[...]
> At the same time, I think we should start experimenting with namespaces
> for Qt types. A way to do that that doesn’t disrupt current Qt development
> is by adding headers that put the types into namespaces:
> 
> --
> #include 
> 
> QtCoreNamespace:
> 
> class QObject;
> namespace QtCore { // or should this simply be Qt?
> using ::QObject as Object;

This will exacerbate the problems you mentioned before, since every type will 
have two names, and there goes consistency...


> // or
> class Object : public QObject {
>   using QObject::QObject;
> }

This requires C++11 and makes Qt::Object and QObject distinct types. In 
particular, a cast from QLineEdit to Qt::Object is invalid, as QLineEdit is-
not-a Qt::Object. It also doesn't work for value tyoes.


> 
> Not sure this would work perfectly,

it wouldn't.

> but it might be worth a try :)

it isn't.

I'm sorry, but this mail contains no arguments against *namespaces*. It 
contains _some_ arguments against *nested types*, but Qt already widely 
violates that.

Curiously, you didn't list any pro-namespace arguments. I don't know what to 
make of this, but I fear that a decision is being made based solely on 
arguments from one side.

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 API, didn't choose it for its own 
internal structure...?

*And* they are using using directives all over the place. More than 2000. 
Maybe the devs over there got tired of typing QtCreatorCMakeProjectManager 
and QtCreatorCoreInternalDesignModeCoreListener? Maybe QtC already *has* the 
experience with namespaces we think we first needed to gather?

But after all I read from the proponents of name prefixing so far, we rather 
need to send the whole QtC bunch to the asylum because they've clearly backed 
themselves into a corner and can't possibly understand their code anymore. :)

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Some Qt3D feedback

[Knoll Lars]

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 gathered a week of
>opinions 
>and reasons, and I think it's time to put the thread to rest.
>
>Lars, what's your take on these two questions:
>
>1) What should be done for new modules with Qt 5.6+ ?
>
>2) What should be done with Qt3D?

This is mainly about how we use namespaces in Qt. We went through that
discussion during the times we moved from Qt 4 to Qt 5, and I was trying
to dog out the issues we had at that time.

During the time we worked on Qt 5, we actually discussed whether we should
move all of Qt into namespaces. It failed for several reasons. Some of
them are also valid for new code:

* (doesn’t really apply for new code) We couldn’t make things work in a
source compatible way. Moving from QObject to Qt::Object (or even
Qt::QObject) was not something you could do in a transparent way. We
thought about using a 'typedef Qt::Object QObject’ for compatibility. But
it would break things such as forward declarations and typedefs.

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

* metatype registration is problematic with namespaced types, as the macro
extracts the name of the type through the preprocessor. People can very
easily end up registering the type multiple times with different
(qualified vs non qualified) names.

* One of our coding guidelines is that you write code once, but read it
many times. Code written should be as self explaining as possible. Having
generic class names inside an implicit namespace makes this difficult, as
information is not fully local anymore (you have to know that there’s a
using directive at the beginning of the file to find the proper qualified
class name). Generic and duplicated names from different namespaces can
easily lead to confusion when reading code. (btw, this is also an argument
against over-using auto)

* class name prefixing is a widely used and understood scheme by our
users. Do we really want an inconsistency now in one place? I don’t think
we have enough arguments to actually go down that route.

So what do we do with Qt 3D? For 5.5, we’re too late to do any changes.
But we’re talking about a Tech Preview here, so we can use it to collect
some feedback on the namespace usage in there. We will however need to
decide rather quickly whether we want to keep it or revert to regular Qt
style class name prefixing for 5.6. I’m currently leaning towards the
latter.

At the same time, I think we should start experimenting with namespaces
for Qt types. A way to do that that doesn’t disrupt current Qt development
is by adding headers that put the types into namespaces:

--
#include 

QtCoreNamespace:

class QObject;
namespace QtCore { // or should this simply be Qt?
using ::QObject as Object;
// or
class Object : public QObject {
using QObject::QObject;
}
}
--

Not sure this would work perfectly, but it might be worth a try :)

Cheers,
Lars

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

Re: [Development] QtCS: Long Term Release discussion

[Knoll Lars]

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 have a stake in that: The printing case.

As Thiago said, you could still easily use the module on your own. The
code will not suddenly dissappear from the universe. And we had some
discussions about how to fix the printing case in Qt Quick 2.

Cheers,
Lars

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

Re: [Development] QtCS: Long Term Release discussion

[André Somers]

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.

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

Re: [Development] QtCS: Long Term Release discussion

[Knoll Lars]

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 in the new CI (exceptions in QNX 6.5). It’s
mainly about some details now and flipping the switch.
* We delay introducing hard dependencies to C++11 to Qt 5.7. This doesn’t
come at a huge cost from an R&D perspective as the 5.6 feature freeze is
in the beginning of August. So once everybody is back form summer
vacations, we could start cleaning up our code base aggressively.
* 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 still remove the deprecated modules from our Qt 5.6 release (maybe
with the exception of Qt Script).

That would give us a pretty good baseline to work with for the LTS
release, we’d keep people on older compilers/OSes happy and we could move
a lot more aggressively towards C++11 in the dev branch directly after
summer vacations (from the beginning of August).

Opinions?

Cheers,
Lars

On 17/06/15 10:54, "André Somers"  wrote:

>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. See notes from that session.
>
>André
>
>___
>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] Avoid overloading of 'error'

[Koehne Kai]

> -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 the emissions. But note that there will be an delivery
> order
> problem: all slots connected to one signal will be received before all slots
> connected to the other. Unless Olivier adds a signal alias feature to moc :-)

I've put some patches that deprecate the 'error()' signals in favor of 
'errorOccurred()' up for review in a topic branch #errorAmbiguity :

https://codereview.qt-project.org/#/q/topic:errorAmbiguity,n,z

(The networking one's probably still need some work in the autotests).


Regarding the property name, I'm not convinced anymore it's a good idea to 
change from 'error()' to 'lastError()': error() and errorString() are actually 
pretty common in a lot of classes, even one's that do not suffer from the 
naming clash (because they don't feature a signal).


Regards

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

Re: [Development] QtCS: Long Term Release discussion

[André Somers]

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. See notes from that session.

André

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

Re: [Development] QtCS: Long Term Release discussion

[Knoll Lars]

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.
>
>Ok, thanks for explaining this out...
>
>> In turn, to keep 5.5 long-term implies keeping the current
>>infrastructure
>> long-term. The same infrastructure that we're having tons of problems
>>with,
>> for flaky tests, inability to populate the test infra for Qt version,
>>virtual
>> machine configurations, etc.
>>
>> 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 deprecate platforms we don't want
>to support long term in 5.5 already, though, which is what has
>happened with QNX. Maybe old OSX as well? GCC 4.4?
>
>I would also push the "C++11 in our API" to 5.7 to minimise the risks.

Pushing this to 5.7 could be an option, since the 5.6 feature freeze is
only 1.5 months away (out of which a couple of weeks are summer vacations
for many of us).

Cheers,
Lars


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

Re: [Development] QtCS: Long Term Release discussion

[Giuseppe D'Angelo]

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 keep 5.5 long-term implies keeping the current infrastructure
> long-term. The same infrastructure that we're having tons of problems with,
> for flaky tests, inability to populate the test infra for Qt version, virtual
> machine configurations, etc.
>
> 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 deprecate platforms we don't want
to support long term in 5.5 already, though, which is what has
happened with QNX. Maybe old OSX as well? GCC 4.4?

I would also push the "C++11 in our API" to 5.7 to minimise the risks.

Cheers,
-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Bluetooth support for Windows (RT/10) in Qt 5.6

[Eric Lemanisser]

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.
>
> While there is certainly more inertia in the windows desktop version
> than probably any other Qt supported platform, Microsoft itself is
> trying to nudge people into quicker upgrade cycles, and while Win8 has
> certainly gotten a pushback, with Win10 around the corner I would also
> try not to get bogged down with pre-WinRT solutions, as painful as that
> might sound in some cases.
>
> Best regards,
> Attila
>
> On 6/16/2015 1:42 PM, Kalinowski Maurice wrote:
> > Hi everyone,
> >
> > It might sound weird that while we're trying to get 5.5.0 out I am
> starting a discussion about Qt 5.6, but if you look at the release schedule
> there is not much time for the feature freeze
> >
> > https://wiki.qt.io/Qt-5.6-release
> >
> > One of the items the Windows / WinRT team would really like to see
> included to that release is support for Bluetooth and BTLE.
> >
> > The current idea is to use the WinRT API for that backend, as it
> provides the advantage that it can also be used on Windows Desktop starting
> Windows 8(.1). WinRT covers Windows 10 support (both classic and Unified
> Windows Platform) as well.
> >
> > This leaves out support for Windows Desktop older than Windows 8. But as
> we are aiming to implement new features, we should draw the line somewhere
> and the WinRT backend clearly has the biggest potential to be supported in
> many years' time, while the (or multiple) pure desktop solution would be
> deprecated sooner or later again. Also given the fact that we can target
> quite many platforms with one backend gives us a better coverage for
> maintenance and resourcing.
> >
> > The reason that I am mentioning this on the mailing list is that after
> talking to some folks here in The Qt Company, multiple people inside and
> outside already started or wanted to start efforts on this topic. Hence the
> aim of this email is to get everyone connected and work on it together to
> make it happen within the 5.6 feature freeze.
> >
> > So, if you have worked on Bluetooth (LE) on Windows or want to, please
> get in touch with me to align.
> >
> >
> > BR,
> > Maurice
> >
> >
> > 
> > Maurice Kalinowski - Senior Manager, Qt Tools
> >
> > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der
> Gesellschaft:
> > Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> >
> > Email: maurice.kalinow...@theqtcompany.com | Mobile: + 49 175 187 19 52
> | Phone:
> > +49 30 63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ |
> Twitter:
> > @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt
> >
> >
> > ___
> > 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] QtCS: Long Term Release discussion

[André Somers]

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 lockstep
> with Qt 5.6, including QtTest features. That means the "new CI" system cannot
> be backported to 5.5.
>
> In turn, to keep 5.5 long-term implies keeping the current infrastructure
> long-term. The same infrastructure that we're having tons of problems with,
> for flaky tests, inability to populate the test infra for Qt version, virtual
> machine configurations, etc.
Ok, so they really are tightly linked. Too bad, but that can't be 
helped. Thank you for your explanation (once again).
> 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.
What would be the impact of doing that? Is doing that feasible at all? 
And are you then thinking of all planned deprecations (compilers, 
platforms, modules) or "just" a part of these?

André



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

Re: [Development] Question about GTK+ support status

[Knoll Lars]

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+ 3, then it also becomes feasible to
>>have
>> platform theme plugins for both GTK+ 2 and 3. As you mentioned, a
>>platform
>> theme is the easy part. Implementing a QStyle for GTK+ 3.x is a lot more
>> work.
>
>I proposed removing QGtkStyle altogether, but moving it to qtstyleplugins
>is
>also a good idea. We just need to make sure we don't load it when the
>platform
>theme is gtk3 (as one can't load gtk2 and gtk3 libraries at the same
>time).
>
>> configure: add support for GTK+ 3.x -
>>https://codereview.qt-project.org/#/c/75599/
>> QGtk3ThemePlugin - https://codereview.qt-project.org/#/c/75757/
>
>Do we really need to keep gtk2 support in qtbase? I.e., do we really need
>to
>keep gtk2 theme if we have gtk3 theme?

IMO, we don’t. I’d be ok with removing gtk2 theming support once we have
gtk3 support in. I’d say let’s go that route unless someone has some good
and convincing arguments as to why we should keep gtk2 style support
around.

Cheers,
Lars

>
>Also the latter patch will need some rebasing for new version and new
>copyrights.
>
>--
>Dmitry Shachnev

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

Re: [Development] Question about GTK+ support status

[Dmitry Shachnev]

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 theme plugins for both GTK+ 2 and 3. As you mentioned, a platform
> theme is the easy part. Implementing a QStyle for GTK+ 3.x is a lot more
> work.

I proposed removing QGtkStyle altogether, but moving it to qtstyleplugins is
also a good idea. We just need to make sure we don't load it when the platform
theme is gtk3 (as one can't load gtk2 and gtk3 libraries at the same time).

> configure: add support for GTK+ 3.x - 
> https://codereview.qt-project.org/#/c/75599/
> QGtk3ThemePlugin - https://codereview.qt-project.org/#/c/75757/

Do we really need to keep gtk2 support in qtbase? I.e., do we really need to
keep gtk2 theme if we have gtk3 theme?

Also the latter patch will need some rebasing for new version and new
copyrights.

--
Dmitry Shachnev

signature.asc
Description: OpenPGP digital signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS: Long Term Release discussion

[Thiago Macieira]

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 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 blocker
> >> for a LTS release?
> > 
> > Because that would imply keeping it running for a "long term" and the team
> > maintaining it would really like to turn it off ASAP, in favour of the new
> > solution that is more manageable and should have fewer flaky tests.
> 
> 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 lockstep 
with Qt 5.6, including QtTest features. That means the "new CI" system cannot 
be backported to 5.5.

In turn, to keep 5.5 long-term implies keeping the current infrastructure 
long-term. The same infrastructure that we're having tons of problems with, 
for flaky tests, inability to populate the test infra for Qt version, virtual 
machine configurations, etc.

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.
-- 
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] QtCS: Discussion about deprecating things

[Rafael Roquetto]

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 completely dropped due to lack of compilers.
> 
> The changelog says "may be removed or stop compiling". I think that we'll 
> simply stop maintaining them and let them bitrot.

Which means, for QNX 6.5, that it will be officially dropped - except that in
practice all this means is that we can add C++11 code to the code, and it
won't build with 6.5, only 6.6.

6.5 is deprecated as of Qt 5.5 already.

> 
> > > * Android 2.3 support for 5.6 / “Qt LTS"
> > 
> > What's "LTS" here?
> 
> Long Term Support, subject of another session, whose note taker has not sent 
> the details to the list. Oh wait, that would be me!
> -- 
> 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

-- 
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts


smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS: Long Term Release discussion

[Simon Hausmann]

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 only Linux build that compiles to a 32-bit architecture.

We do have builds on Windows that target x86.

>  *  We do need to introduce a static builder to ensure things work. We
> need to document that static requires more complexity to make a working
> application and it's only tested with qmake.

We do have two static builds in the CI system and we've had them for a longer 
time:

* The build targetting iOS is - by design - creating static binaries.
* The qt5 build has a three static builds - one for Linux, one for OS X and 
one for Windows.


Simon

P.S.: I'm basing this solely on the information at

http://testresults.qt.io/ci/Qt5_dev_Integration/latest-success/

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

Re: [Development] QtCS: Long Term Release discussion

[Thiago Macieira]

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
> >   *  Qt WebKit, Qt Script, Qt Quick 1
> 
> Ok, I understand that support for these has to go at one point, though
> I'm not feeling too happy that that happens to be in a point release.
>  From my point of view, it breaks the compatibility promise of Qt. But I
> guess that's all water under the bridge, and there is nothing that can
> be done about it. We just can't maintain it any more I understand
> (especialy WebKit).

We've been through this time and time again. Let me repeat once more and never 
again:

There's no breakage of the compatibility promise. The code for those modules 
is not getting deleted from the Internet. You can still build the existing 
versions with newer versions of Qt and that should continue working. The 
number of changes required to keep Qt Quick 1 and QtScript running in the past 
4 minor releases supports this statement; QtWebKit never depended on Qt 
private API in the first place.

What's more, this is our BKM for deprecating modules. We've done that twice 
already: once for Qt Script Classic and once for QtAssistant ADP.

> > 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.
> 
> And that I don't understand, as it is exactly 5.6 that is no longer
> supporting a list of platforms, compilers and tecnologies that people
> actually rely on, right? So it seems to me, that making 5.6 LTS is one
> release too late. For instance, if one is relying on Quick 1 like we
> are, how are we supposed to stay on a supported platform? And no,
> porting to Quick 2 isn't an option. Not as long as we can't print the
> contents of our scene like we can with our Quick 1 based reporting
> engine by simply rendering pages (sections of the scene) to a QPrinter.

You're right. The problem is manpower.

So our hands are tied and we're making a less-than-ideal decision considering 
the technical aspects.

-- 
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] QtCS: Long Term Release discussion

[André Somers]

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* will be the first LTS release.
>> Mind to elaborate? Why is the "old Qt CI" a requirement or a blocker
>> for a LTS release?
> Because that would imply keeping it running for a "long term" and the team
> maintaining it would really like to turn it off ASAP, in favour of the new
> solution that is more manageable and should have fewer flaky tests.
>
Does the CI infrastructure depend on the Qt version then? What is it 
about 5.5 that prevents the CI from being upgraded?

André

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