Re: [Development] QMovie no longer supports .mng

[Maurice Kalinowski]

> > As a distribution packager, I think that's a good plan. :-) The people 
> > on proprietary operating systems seem less happy about that, as 
> > evidenced by this thread. But that's not MY problem… ;-)
>
> Indeed.
>
> If we want the binaries to include the builds, we could include the DLLs for 
> those libraries too.

For all supported windows platforms? While we shrank the amount of Qt pre-built 
packages, there is still a larger amount of platforms/configurations we support 
and ask users to build from source. Stripping that away might be complicated.

Maurice 

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

Re: [Development] cmath, abs(), qt5 and gcc6

[Lisandro Damián Nicanor Pérez Meyer]

pebcak, by using cmath code should be using the std namespace.

Sorry for the noise.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] cmath, abs(), qt5 and gcc6

[Lisandro Damián Nicanor Pérez Meyer]

Suppose this simple code:

#include 
#include 

void Foo::bar() {

  QPointF refPos, newPos;

  /// They get some values.

  if( abs(refPos.x()-newPos.x()) > abs(refPos.y()-newPos.y()) ) {
// Do something.
  }
}


With gcc6 I will get:

error: call of overloaded ‘abs(qreal)’ is ambiguous
 if( abs(refPos.x()-newPos.x()) > abs(refPos.y()-newPos.y()) ) {
  ^
In file included from /usr/include/c++/6/cstdlib:75:0,
 from /usr/include/c++/6/bits/stl_algo.h:59,
 from /usr/include/c++/6/algorithm:62,
 from /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:85,
 from /usr/include/x86_64-linux-gnu/qt5/QtCore/qnamespace.h:37,
 from /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs.h:41,
 from /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:40,
 from /usr/include/x86_64-linux-gnu/qt5/QtGui/qclipboard.h:37,
 from /usr/include/x86_64-linux-gnu/qt5/QtGui/QClipboard:1,
 from 
/home/lisandro/damian/debian/propios/caneda/upstream/src/cgraphicsscene.cpp:21:
/usr/include/stdlib.h:774:12: note: candidate: int abs(int)
 extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur;
^~~
Yes, the example code might be too simplistic, but I think it's enough to get
the idea.

I know I can easily solve this by replacing cmath's abs with QGlobal's qAbs(),
but I wonder if this is a bug in gcc6, in my code or Qt.

It might be worth to note that, according to
https://gcc.gnu.org/gcc-6/porting_to.html#math.h

  Header  changes

  The C++ library now provides its own  header that wraps the C
  library header of the same name. The C++ header defines additional overloads
  of some functions and ensures that all standard functions are defined as
  real functions and not as macros. Code which assumes that sin, cos, pow,
  isfinite etc. are macros may no longer compile.

Any hints?

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QMovie no longer supports .mng

[Jake Petroules]

If we can simply update libmng and recompile against the new version then we 
should do so immediately!

On Apr 26, 2016, at 4:47 PM, Thiago Macieira 
> wrote:

On quarta-feira, 27 de abril de 2016 01:39:38 PDT Kevin Kofler wrote:
Thiago Macieira wrote:
Sorry, just deleting. That makes downloading and maintaining such a
library SEP.

As a distribution packager, I think that's a good plan. :-) The people on
proprietary operating systems seem less happy about that, as evidenced by
this thread. But that's not MY problem… ;-)

Indeed.

If we want the binaries to include the builds, we could include the DLLs for
those libraries too.

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

--
Jake Petroules - 
jake.petrou...@theqtcompany.com
Consulting Services Engineer - The Qt Company
Qbs build system evangelist - qbs.io

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

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Thiago Macieira]

On terça-feira, 26 de abril de 2016 20:51:30 PDT Lisandro Damián Nicanor Pérez 
Meyer wrote:
> Please correct me if I'm wrong: the feature which will break API was added
> in 5.6.0, and we can say that most of the people out there are not using
> it.

No ABI breakage happened. There's a change in behaviour that most applications 
will want, but some don't. We're trying to figure out a way to allow those 
exceptions to revert to the old behaviour.

-- 
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] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Lisandro Damián Nicanor Pérez Meyer]

Please correct me if I'm wrong: the feature which will break API was added in 
5.6.0, and we can say that most of the people out there are not using it.

Ideally API/ABI should not be broken without a SONAME change. If I had some 
Qt5 app using it already I would be forced to do a hack in our packaging: 
faking a SONAME change.

Now it just happens that we in Debian haven't pushed 5.6 to unstable yet (we 
are waiting for 5.6.1) so it's not a problem for us now. It will be if pushed 
with 5.6.2 instead of 5.6.1.

Of course I'm only speaking for us Debian, I don't know the impact on other 
distros.

-- 
Wiki participants are, by nature, a pedantic, ornery, and unreasonable bunch.
So there's a camaraderie here we seldom see outside of our professional
contacts.
  http://www.c2.com/cgi/wiki?WhyWikiWorks

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QMovie no longer supports .mng

[Thiago Macieira]

On quarta-feira, 27 de abril de 2016 01:39:38 PDT Kevin Kofler wrote:
> Thiago Macieira wrote:
> > Sorry, just deleting. That makes downloading and maintaining such a
> > library SEP.
> 
> As a distribution packager, I think that's a good plan. :-) The people on
> proprietary operating systems seem less happy about that, as evidenced by
> this thread. But that's not MY problem… ;-)

Indeed.

If we want the binaries to include the builds, we could include the DLLs for 
those libraries too.

-- 
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] QMovie no longer supports .mng

[Kevin Kofler]

Thiago Macieira wrote:
> Sorry, just deleting. That makes downloading and maintaining such a
> library SEP.

As a distribution packager, I think that's a good plan. :-) The people on 
proprietary operating systems seem less happy about that, as evidenced by 
this thread. But that's not MY problem… ;-)

Kevin Kofler

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

Re: [Development] QMovie no longer supports .mng

[Thiago Macieira]

On quarta-feira, 27 de abril de 2016 01:11:28 PDT Kevin Kofler wrote:
> Jake Petroules wrote:
> > The MNG and JPEG2000 plugins are no longer built by default on most
> > platforms because upstream development has stalled and there are known
> > security vulnerabilities. See
> > https://codereview.qt-project.org/#/c/141429/
> 
> For libmng, you bundle the ancient version 1.0.10 from 2009 (!). The current
> version is 2.0.3 from 2015:
> https://sourceforge.net/projects/libmng/files/libmng-devel/
> Despite the new major version number, qt5-qtimageformats compiles with no
> changes against that version.

Nice!

I wonder why the bundled copies are still present. The commit that disabled 
them was "Build MNG and Jpeg2000 plugins only if system libs found".

Deletion in https://codereview.qt-project.org/157156.

> For JPEG2000:
> > You can still build them manually if you really want them. Perhaps you
> > could help port the JPEG2000 plugin to
> > https://github.com/uclouvain/openjpeg
> 
> That would be an option. But I would start by just getting the Jasper
> security fixes from a GNU/Linux distribution (e.g.:
> http://pkgs.fedoraproject.org/cgit/rpms/jasper.git/tree/
> ) and applying them to your bundled copy.

Sorry, just deleting. That makes downloading and maintaining such a library 
SEP.

https://en.wikipedia.org/wiki/SEP_field

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

Re: [Development] QMovie no longer supports .mng

[Kevin Kofler]

I wrote:
> For libmng, you bundle the ancient version 1.0.10 from 2009 (!).

Sorry, from 2007, even!

Kevin Kofler

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

Re: [Development] QMovie no longer supports .mng

[Kevin Kofler]

Jake Petroules wrote:
> The MNG and JPEG2000 plugins are no longer built by default on most
> platforms because upstream development has stalled and there are known
> security vulnerabilities. See
> https://codereview.qt-project.org/#/c/141429/

For libmng, you bundle the ancient version 1.0.10 from 2009 (!). The current 
version is 2.0.3 from 2015:
https://sourceforge.net/projects/libmng/files/libmng-devel/
Despite the new major version number, qt5-qtimageformats compiles with no 
changes against that version.

For JPEG2000:

> You can still build them manually if you really want them. Perhaps you
> could help port the JPEG2000 plugin to
> https://github.com/uclouvain/openjpeg

That would be an option. But I would start by just getting the Jasper 
security fixes from a GNU/Linux distribution (e.g.:
http://pkgs.fedoraproject.org/cgit/rpms/jasper.git/tree/
) and applying them to your bundled copy.

Kevin Kofler

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

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Alejandro Exojo]

El Tuesday 26 April 2016, Shawn Rutledge escribió:
> Personally I think event compression should be a cross-platform feature if
> we’re going to have it.  The event-pileup problem can happen also on
> Windows for example, but it seems that we never implemented event
> compression on any platform other than X11.  I’m not sure why.  But we
> don’t plan to do that in the 5.6 series, anyway.

Are you thinking in a generic event compression feature, not only for input 
events? For example, I emit a signal with a "last value" parameter with a 
queued connection (or I just post the event manually), and the receiver can 
discard previous values that it did not have time to process because it was 
slower than the sender. That's not an input event, but it happens through the 
event system anyway.

Now I would think of reimplementing QCoreApplication::notify, but there is the 
warning about Qt6 change, and there is no way to access the already posted 
events (that I know of). There are some reports asking for the feature, BTW:

https://bugreports.qt.io/browse/QTBUG-2688
https://bugreports.qt.io/browse/QTBUG-44293

I suppose if notify() was "soft deprecated" there is not that much 
time/interest in doing this?

> I was told to request this exception on the mailing list, because we
> usually try to maintain source compatibility between releases.

This change being added doesn't worry me much (I don't think it will set my 
computer on fire), so I'm not opposing to it (honestly!) but I don't think the 
issue is source compatibility. It's adding features on already released 
branches. There is a process to ensure that code released has gone through a 
testing procedure. Adding this is bypassing it, while other much innocent 
changes have to wait.

Let me point at some examples, for illustration purposes:

A one line change that fixes QPalette::resolve. It's an obvious fix, but it 
wasn't unit tested, and it changes behaviour, so who knows what might break:

https://codereview.qt-project.org/148552

A microoptimization that looks entirely safe to everyone, but it's not 
critical, so it wasn't committed to the stable branch:

https://codereview.qt-project.org/138746

A simple setter/getter/member addition to QIcon and one line addition to the 
OS X platform plugin to make the system tray icons look properly on Yosemite 
and newer. It's trivial, but it was new API, so it could not go in the stable 
branch:

https://codereview.qt-project.org/115120

Again, honestly, I don't have an axe to grind. Two of this issues affected me, 
but not a lot, and it's already solved, so no big deal now. I'm just a bit 
confused when I see this differences in interpretation of the rules, because I 
don't know what to expect and what not.

Thanks.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Thiago Macieira]

On terça-feira, 26 de abril de 2016 10:02:46 PDT Matthew Woehlke wrote:
> Since when does SC mean that code written for version Y must compile
> against version X (X < Y)? Usually it's only the other way around... Or
> do I not understand what would break, here? (Is the problem just that
> code written against 5.6.1 would not compile with 5.7.0?)

We offer bi-directional source and binary compatibility inside the same minor 
version. Code written for 5.x.y also compiles and runs on 5.x.z, whichever 
values of y and z are.

-- 
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] Qt 5.6 QTcpSocket WindowsXp32 mingw32 strange behavior of connected signal. After so many years of using Qt.

[Thiago Macieira]

On terça-feira, 26 de abril de 2016 11:54:15 PDT Oleg Shalnev wrote:
> And socket is connected!!!
> 
> The problem is that socket connected and signal emmited.
> 
> Only then after couple of seconds program received error "Remote host
> closed"
> 
> 
> On Linux and Android all ok.
> 
> 
> Qt 5.5 5.6, WindowsXP_32, mingw32


Are you sure it's not some service on your Windows machine that tries to do 
content filtering?

-- 
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] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Matthew Woehlke]

On 2016-04-26 08:08, Shawn Rutledge wrote:
> If the application does not handle high-frequency events (mouse 
> movements and window moves/resizes) quickly enough, some events will 
> be dropped.

Do you really mean dropped? Or do you mean merged? There is a HUGE
difference...

Please don't EVER simply discard input events (at least, not without
being specifically asked to do so); that is a form of data loss.

> https://codereview.qt-project.org/#/c/157011 adds an application
> attribute, AA_CompressHighFrequencyEvents, which is true by default
> on X11, and you can unset it to disable the compression. The
> advantage of doing it this way is that you can control it
> dynamically: maybe you want to have compression only some of the
> time, depending on what the application is doing with the events. But
> it requires an exception to the source compatibility rule: if you
> have used that flag in your application, then you won’t be able to
> compile it with 5.6.0 anymore.

Since when does SC mean that code written for version Y must compile
against version X (X < Y)? Usually it's only the other way around... Or
do I not understand what would break, here? (Is the problem just that
code written against 5.6.1 would not compile with 5.7.0?)

-- 
Matthew

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

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Simon Hausmann]

Hi,

The way you describe the problem sounds like it is specific to tablet events on 
X-Windows. In my opinion a solution to the problem applied to the 5.6 branch of 
Qt
should also be limited to tablet events on X-Windows. Wouldn't it therefore be 
easiest to simply not do tablet event compression on X-Windows without any 
changes to the API?

The day somebody really wants event compression for tablet events, we can 
consider introducing new API perhaps in a new minor release.

Simon


From: Development  on 
behalf of Shawn Rutledge 
Sent: Tuesday, April 26, 2016 2:08 PM
To: development@qt-project.org
Subject: [Development] Exception to source compatibility: adding 
AA_CompressHighFrequencyEvents flag

In 5.6.0, an event compression feature was added to the xcb platform plugin, to 
fix QTBUG-40889 and QTBUG-47069.  That is here: 
https://codereview.qt-project.org/#/c/126136/  Qt 4 had a similar feature, and 
then it was possible to turn it on or off, using widget attribute 
WA_NoX11EventCompression.  Using a widget attribute doesn’t make sense now, 
because you might not be using widgets, and the platform plugin isn’t 
necessarily aware of them even if you are.  This time the compression was done 
with no way to turn it off, and QTBUG-44964 was written up as a task to come up 
with a way to enable/disable the compression.  If the application does not 
handle high-frequency events (mouse movements and window moves/resizes) quickly 
enough, some events will be dropped.  So, sufficiently responsive applications 
shouldn’t experience any event compression.

This causes some trouble for drawing-tablet applications like Krita though.  
It’s not right to compress move events from tablet devices by default, because 
the application may be using some complex brush-painting algorithm, but 
nevertheless the artist using it expects to get smooth brush strokes, not 
jagged piecewise ones.  So maybe the XCB plugin simply shouldn’t compress 
those; but then we’d have a behavior change in 5.6.1 relative to 5.6.0, and 
anyway the decision to compress or not doesn’t pay attention to which device 
it’s coming from, so far.  It might be possible though.

Personally I think event compression should be a cross-platform feature if 
we’re going to have it.  The event-pileup problem can happen also on Windows 
for example, but it seems that we never implemented event compression on any 
platform other than X11.  I’m not sure why.  But we don’t plan to do that in 
the 5.6 series, anyway.

https://codereview.qt-project.org/#/c/156755 makes it possible to turn off the 
compression feature by setting an env variable; that works OK, but it’s meant 
as a short-term hack: we know that we need proper public API eventually.  The 
question is whether we should be adding API in a patch release like 5.6.1.  Of 
course this time it’s an LTS release, so it seems reasonable to expect 
long-term solutions to problems like this, rather than short-term hacks.  And 
it was brought up that env variables are inherited by child processes, so if 
for some reason your paint program starts child processes, you might need to 
unset the env variable first.  And as usual, env variables which affect 
behavior in platform plugins need to be set before the QGuiApplication is 
created, because the platform plugin reads it at static-initialization time, 
when it is loaded.

https://codereview.qt-project.org/#/c/157011 adds an application attribute,
AA_CompressHighFrequencyEvents, which is true by default on X11, and you can 
unset it to disable the compression.  The advantage of doing it this way is 
that you can control it dynamically: maybe you want to have compression only 
some of the time, depending on what the application is doing with the events.  
But it requires an exception to the source compatibility rule: if you have used 
that flag in your application, then you won’t be able to compile it with 5.6.0 
anymore.  (You could ifdef it though.)  Of course forward compatibility 
shouldn’t be a problem.  And even if we implement compression as a 
cross-platform feature eventually, we can still use that flag to enable/disable 
it.

I was told to request this exception on the mailing list, because we usually 
try to maintain source compatibility between releases.

So, any objections?

___
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] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Giuseppe D'Angelo]

On Tue, Apr 26, 2016 at 1:08 PM, Shawn Rutledge  wrote:
>
>
> I was told to request this exception on the mailing list, because we usually 
> try to maintain source compatibility between releases.
>
> So, any objections?

(Having been the one asking for bringing the matter up to the ML): an
exception in this case can be agreeable. (Note that however these
exceptions may have an impact in the "current" release branch too,
that is, suppose that 5.7 was already released, a 5.6->5.7 merge would
then break compatibility there too.)

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

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Morten Sorvig]

> On 26 Apr 2016, at 14:08, Shawn Rutledge  wrote:
> 
> Personally I think event compression should be a cross-platform feature if 
> we’re going to have it.  The event-pileup problem can happen also on Windows 
> for example, but it seems that we never implemented event compression on any 
> platform other than X11.  I’m not sure why.  But we don’t plan to do that in 
> the 5.6 series, anyway.

For OS X: My first thought is that we should let the OS compress events for us. 
Which it does, at least for wheel events. Event compression in Qt can then be a 
feature for those platforms that need it (implemented in cross-platform code), 
but not mandatory.

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

[Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Shawn Rutledge]

In 5.6.0, an event compression feature was added to the xcb platform plugin, to 
fix QTBUG-40889 and QTBUG-47069.  That is here: 
https://codereview.qt-project.org/#/c/126136/  Qt 4 had a similar feature, and 
then it was possible to turn it on or off, using widget attribute 
WA_NoX11EventCompression.  Using a widget attribute doesn’t make sense now, 
because you might not be using widgets, and the platform plugin isn’t 
necessarily aware of them even if you are.  This time the compression was done 
with no way to turn it off, and QTBUG-44964 was written up as a task to come up 
with a way to enable/disable the compression.  If the application does not 
handle high-frequency events (mouse movements and window moves/resizes) quickly 
enough, some events will be dropped.  So, sufficiently responsive applications 
shouldn’t experience any event compression.

This causes some trouble for drawing-tablet applications like Krita though.  
It’s not right to compress move events from tablet devices by default, because 
the application may be using some complex brush-painting algorithm, but 
nevertheless the artist using it expects to get smooth brush strokes, not 
jagged piecewise ones.  So maybe the XCB plugin simply shouldn’t compress 
those; but then we’d have a behavior change in 5.6.1 relative to 5.6.0, and 
anyway the decision to compress or not doesn’t pay attention to which device 
it’s coming from, so far.  It might be possible though.

Personally I think event compression should be a cross-platform feature if 
we’re going to have it.  The event-pileup problem can happen also on Windows 
for example, but it seems that we never implemented event compression on any 
platform other than X11.  I’m not sure why.  But we don’t plan to do that in 
the 5.6 series, anyway.

https://codereview.qt-project.org/#/c/156755 makes it possible to turn off the 
compression feature by setting an env variable; that works OK, but it’s meant 
as a short-term hack: we know that we need proper public API eventually.  The 
question is whether we should be adding API in a patch release like 5.6.1.  Of 
course this time it’s an LTS release, so it seems reasonable to expect 
long-term solutions to problems like this, rather than short-term hacks.  And 
it was brought up that env variables are inherited by child processes, so if 
for some reason your paint program starts child processes, you might need to 
unset the env variable first.  And as usual, env variables which affect 
behavior in platform plugins need to be set before the QGuiApplication is 
created, because the platform plugin reads it at static-initialization time, 
when it is loaded.

https://codereview.qt-project.org/#/c/157011 adds an application attribute, 
AA_CompressHighFrequencyEvents, which is true by default on X11, and you can 
unset it to disable the compression.  The advantage of doing it this way is 
that you can control it dynamically: maybe you want to have compression only 
some of the time, depending on what the application is doing with the events.  
But it requires an exception to the source compatibility rule: if you have used 
that flag in your application, then you won’t be able to compile it with 5.6.0 
anymore.  (You could ifdef it though.)  Of course forward compatibility 
shouldn’t be a problem.  And even if we implement compression as a 
cross-platform feature eventually, we can still use that flag to enable/disable 
it.

I was told to request this exception on the mailing list, because we usually 
try to maintain source compatibility between releases.

So, any objections?

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

[Development] Qt 5.6 QTcpSocket WindowsXp32 mingw32 strange behavior of connected signal. After so many years of using Qt.

[Oleg Shalnev]

Hi all!
I have no idea what's the (hell) is going on.
The simplest test...


SocketTest::SocketTest()

{

  mSocket=new QTcpSocket(this);

  QObject::connect(mSocket, SIGNAL(hostFound()), this, SLOT(onHostFound()));

  QObject::connect(mSocket, SIGNAL(connected()), this, SLOT(onConnected()));

  QObject::connect(mSocket, SIGNAL(error(QAbstractSocket::SocketError)),

   this, SLOT(onError(QAbstractSocket::SocketError)));

}


void SocketTest::start()

{

  mSocket->connectToHost(QHostAddress("1.1.1.1"), 2000);

}


void SocketTest::onHostFound()

{

  qDebug()<<"OnHostFound"connectToHost(QHostAddress("192.168.1.2"), 2000);
}

void SocketTest::onHostFound()
{
  qDebug()<<"OnHostFound"

Re: [Development] CI failures

[Eskil Abrahamsen Blomfeldt]

Den 23.04.2016 13:11, skrev Simon Hausmann:

Hi,

Usually the CI system won't rebuild depending modules, but in this case no 
builds exist of qtbase. That is because MinGW 5.3 was added to the CI system - 
replacing MinGW 4.9 - maybe yesterday (I'm not sure exactly when) and qtbase 
doesn't compile with it.

I'll try to get access to a laptop and see if I can revert the changes.


Hi,

MinGW 5.3 apparently includes some of the Directwrite 2 APIs, but not 
all, so my configure test would pass, but then the actual code would 
fail to compile. Friedemann has a patch here which fixes it:


https://codereview.qt-project.org/#/c/156927/

--
Eskil Abrahamsen Blomfeldt
Senior Manager, Qt Graphics/Multimedia

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

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

Re: [Development] Qt3D CI wedged

[Sean Harmer]

On Tuesday 26 April 2016 07:15:47 Tony Sarajärvi wrote:
> Hi,
> 
> We ran out of disk space on the CI master. Problem has been fixed now and
> things are being restarted.

Thanks. Don't worry about re-staging the Qt 3D changes though, I found a 
problem with them after staging that I've since fixed. Just waiting to be able 
to push them once the CI is unblocked.

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt3D CI wedged

[Tony Sarajärvi]

Hi,

We ran out of disk space on the CI master. Problem has been fixed now and 
things are being restarted.

-Tony


> -Original Message-
> From: Development [mailto:development-
> bounces+tony.sarajarvi=qt...@qt-project.org] On Behalf Of Marc Mutz
> Sent: 26. huhtikuuta 2016 10:15
> To: development@qt-project.org
> Subject: Re: [Development] Qt3D CI wedged
> 
> On Monday 25 April 2016 21:03:24 Sean Harmer wrote:
> > Hi All,
> >
> > is someone around who could kill the current Qt 3D CI integration please?
> > It's been going since lunchtime today and appears to be stuck.
> 
> Same for QtBase integrations: running since 14:13 yesterday.
> 
> --
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - Qt, C++ and OpenGL Experts
> ___
> 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] Qt3D CI wedged

[Marc Mutz]

On Monday 25 April 2016 21:03:24 Sean Harmer wrote:
> Hi All,
> 
> is someone around who could kill the current Qt 3D CI integration please?
> It's been going since lunchtime today and appears to be stuck.

Same for QtBase integrations: running since 14:13 yesterday.

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