Hello,
it has been quite some time since this thread, but yesterday i tried the
approach using no_desktop just to find out, the the qtsvg imageformat plugin,
has ( of course) a dependency on qtsvg, which in turn does also depend on
widgets.
Ok so i thought i use -no-widgets when configuring, but
Hi,
Since a few days code.qt.io seems to be quite unreliable: Fetching changes via
git:// often fail with "fatal: read error: Invalid argument" (Windows) or
"fatal: read error: Connection reset by peer" (Linux).
Is someone already looking into this? Should we rather clone from the github
mirro
Thanks Kai for noticing...Mika (CC) tries to find a reason and fix.
-Olli
-Original Message-
From: Koehne Kai
Sent: 2. huhtikuuta 2015 12:03
To: Hirvonen Olli; development@qt-project.org
Subject: git://code.qt.io availability
Hi,
Since a few days code.qt.io seems to be quite unreliable
On Thu, Apr 02, 2015 at 10:09:18AM +, Hirvonen Olli wrote:
> Thanks Kai for noticing...Mika (CC) tries to find a reason and fix.
>
that should be fixed now, at least for the time being.
> -Olli
>
> -Original Message-
> From: Koehne Kai
> Sent: 2. huhtikuuta 2015 12:03
> To: Hirvonen
Hi,
the behavior of the widgets-based dialog is equivalent to Qt 4.X and
that was the end of the story back then. As reading material for Easter,
I pushed up a proposal to gerrit (
https://codereview.qt-project.org/#/c/109815/ ). I expect KDE 5 will
(again) provide a spectactular native file d
On 2015-04-02 09:11, Friedemann Kleint wrote:
> the behavior of the widgets-based dialog is equivalent to Qt 4.X and
> that was the end of the story back then. As reading material for Easter,
> I pushed up a proposal to gerrit (
> https://codereview.qt-project.org/#/c/109815/ ). I expect KDE 5 w
On Thursday April 02 2015 09:46:29 Matthew Woehlke wrote:
> It may be too late to change this for Qt 4, but please, let's get it
> right for Qt 5 :-).
With KF5 aiming to be "just" a modular set of extensions to Qt 5, why not leave
it like that, and just push the KDE devs to implement the file di
On 2015-04-02 10:38, René J.V. Bertin wrote:
> On Thursday April 02 2015 09:46:29 Matthew Woehlke wrote:
>> It may be too late to change this for Qt 4, but please, let's get it
>> right for Qt 5 :-).
>
> With KF5 aiming to be "just" a modular set of extensions to Qt 5, why
> not leave it like that
On Thursday April 02 2015 11:58:58 Matthew Woehlke wrote:
> Do you honestly expect that every Qt install on a Linux-based platform
> will also have the base KF5 libraries installed? Even on a machine that
No, and I didn't say that. I did mention "reasonably small" and "standalone",
meaning not r
On 2015-04-02 12:27, René J.V. Bertin wrote:
> On Thursday April 02 2015 11:58:58 Matthew Woehlke wrote:
>> Do you honestly expect that every Qt install on a Linux-based platform
>> will also have the base KF5 libraries installed? Even on a machine that
>
> No, and I didn't say that. I did mention
qtbase integrations used to take around 3 hours as recently as two weeks ago.
In the past week, I've caught several integrations lasting more than 6 hours.
The one currently running is integrating a single commit and has been running
for 6h30. I've seen one for 12 hours.
Is this a timeout not c
Environment:
windows 7 Ultimate
msys2
g++ : (Rev5, Built by MSYS2 project) 4.9.2
Compile-timethe followingerror:
tools/qsimd.cpp:36:22: fatal error: QByteArray: No such file or directory
#include
^
compilation terminated.
Makefile.Release:16625: recipe for target '.obj/
i found what caused the issue:
I accidentally also linked some other code to the application in which
a static initialization of a QNetworkAccessManger happened.
This also explains the different behavior between release and debug mode.
>> QEventLoop: Cannot be used without QApplication
>
> S
13 matches
Mail list logo
