-Original Message-
From: Jason H [mailto:scorp...@yahoo.com]
Sent: Monday, February 17, 2014 7:00 PM
To: Koehne Kai; Alan Ezust; qt-interest mailing list
Subject: Re: [Interest] Qt Maintenance Tool vs Online Installer
Online installer stalls for whatever reason. The offline
Hello,I've solved the problem. I had to include zlib paths:configure -opensource -system-zlib -I %ZLIB_ROOT%\include -L %ZLIB_ROOT%\libThank you.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Hi all,
does QNAM support 100 continue
(http://tools.ietf.org/html/rfc2616#section-8.2.3)? I don't thing so - or did I
miss something?
Stanislav Kolář | Research Development
Kerio Technologies
Anglické nábřeží 1, 301 00 Plzeň
Tel: +420 377 338 901
Social collaboration reinvented.
Hi,
We have a bunch of unit tests written using QTestLib. Some tests use
classes like QAction and QMenu, but never draw anything to the screen or
access the clipboard. Those classes require us to instatiate a QApplication
instead of a QCoreApplication in the test runner. The tests are run on a
Hi.
I’ve looked at QLabel code and concluded that QLabel doesn’t support shrinking
less than 80 characters long.
Fix me if I’m wrong.
If I’m right then even QLabel not suitable for mobile development, and I have
to write something simple, that will for example use QStaticText, to draw text
Le 18/02/2014 12:57, igor.mironc...@gmail.com a écrit :
Hi.
I’ve looked at QLabel code and concluded that QLabel doesn’t support
shrinking less than 80
characters long.
Fix me if I’m wrong.
Try to include your text in qtyour text here/qt tags, QLabel should then
shrink and cut
the lines
I've set QLabel::setWordWrap( true ). But as I say QLabel shrinks only to 80
chars long...
-Original Message-
From: Yves Bailly
Sent: Tuesday, February 18, 2014 1:33 PM
To: igor.mironc...@gmail.com ; interest@qt-project.org
Subject: Re: [Interest] QLabel and QScrollArea
Le 18/02/2014
Hello everyone, I use qt-creator to debug an android app in a physical
android device, the debug message I write through qDebug() don't show in
qtcreator's Application Output panel, in fact all the message generated from
logcat don't show. But If I debug the app in an emulator the debug
Hi,
I had the same problem a few days ago, when I downloaded Qt3D as a .zip file. I
don't know the cause for the problem, but I solved it:
When I used git to clone the repository, it compiled fine.
But I have another problem now: Qt3D is compiled on Windows, the .dll files
exist and are in the
Hello,
I have the same problem 90% of the time, but it's always ok if when I
launch my application from creator the device is in sleeping mode (power
saving mode). Don't ask me why...
Le 18-02-2014 13:26, 见良 a écrit :
Hello everyone, I use qt-creator to debug an android app in a physical
Not at the moment. There were some efforts in the past to add compositing of
GL-based windows into eglfs, similarly to how sw-rendered QWidget windows are
handled, but these got cancelled in favour of the upcoming QOpenGLWidget and
QQuickWidget APIs which will provide a modern replacement
Nothing stops you from using OpenGL in a Qt application, what you cannot do
is mixing QGLWidget with other widgets. Take hellogl_es2 for example and strip
out the MainWindow with all the widgets. If you only have the QGLWidget and
nothing else, it will work fine on eglfs too.
Or you could just
Tirsdag 18. februar 2014 14.38.35 skrev Christoph Kurz:
Hi,
I had the same problem a few days ago, when I downloaded Qt3D as a .zip
file. I don't know the cause for the problem, but I solved it:
When I used git to clone the repository, it compiled fine.
Downloading as zip file is not
Am 18.02.2014 um 15:25 schrieb Agocs Laszlo laszlo.ag...@digia.com:
Nothing stops you from using OpenGL in a Qt application, what you cannot do
is mixing QGLWidget with other widgets. Take hellogl_es2 for example and
strip out the MainWindow with all the widgets. If you only have the
Em ter 18 fev 2014, às 11:13:26, Stanislav Kolář escreveu:
Hi all,
does QNAM support 100 continue
(http://tools.ietf.org/html/rfc2616#section-8.2.3)? I don't thing so - or
did I miss something?
It supports 100 continue.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software
Em ter 18 fev 2014, às 12:21:13, Teemu patja escreveu:
Has the QT project solved the above problem in the QT CI system?
The tests are not run via SSH and the OS X servers are not headless.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology
I undestand the QT CI system is built on top of Jenkins. With Jenkins the
common way for connecting OSX build slaves is over SSH.
Can you share how you are using the OSX build slaves for these tests?
To clarify, the show stopper is not the headlessness, but rather pasteboard
access with QT = 5.
Thank you, Thiago, for the response, but I really don't know how to ask
QNetworkAccessManager::post() not to send all data but wait for 100 continue
(or an error status) from the server before sending the data part. And how to
set timeout for waiting for the response etc.
Stanislav Kolář |
18.02.2014, 17:46, Peter Kuemmel syntheti...@gmx.net:
Not at the moment. There were some efforts in the past to add compositing
of GL-based windows into eglfs, similarly to how sw-rendered QWidget windows
are handled, but these got cancelled in favour of the upcoming QOpenGLWidget
and
Em ter 18 fev 2014, às 18:55:41, Stanislav Kolář escreveu:
Thank you, Thiago, for the response, but I really don't know how to ask
QNetworkAccessManager::post() not to send all data but wait for 100
continue (or an error status) from the server before sending the data
part. And how to set
Em ter 18 fev 2014, às 19:52:18, Teemu Patja escreveu:
I undestand the QT CI system is built on top of Jenkins. With Jenkins the
common way for connecting OSX build slaves is over SSH.
Can you share how you are using the OSX build slaves for these tests?
To clarify, the show stopper is not
No, I meant mixing regular widgets with QGLWidget. Like, say, having a
QGLWidget as a child of another QWidget, in a layout or in an MDI area, etc. On
platforms that restrict themselves to a single native window and window surface
this is problematic since a QGLWidget always requires its own
OK, but it in fact means that QNAM doesn't supports 100-continue as described
in http://tools.ietf.org/html/rfc2616#section-8.2.3 :-(, so we cannot use it if
(for example) we have 100MB data for upload and we don't want to upload entire
100MB buffer to the server if the result of the request is
Em ter 18 fev 2014, às 22:13:51, Stanislav Kolář escreveu:
OK, but it in fact means that QNAM doesn't supports 100-continue as
described in http://tools.ietf.org/html/rfc2616#section-8.2.3 :-(, so we
cannot use it if (for example) we have 100MB data for upload and we don't
want to upload
I have what seems to be an obvious question/answer but the subtleties may not
be what I think they are. We have a project with about 500 files most of which
inherit from QObject or QWidget which means they all have moc run on them.
Currently I have each moc created file compiled as a separate
On Tuesday, February 18, 2014 17:04:54 Michael Jackson wrote:
I have what seems to be an obvious question/answer but the subtleties may
not be what I think they are. We have a project with about 500 files most
of which inherit from QObject or QWidget which means they all have moc run
on them.
Hi,
For reference I created a bug to track this issue:
https://bugreports.qt-project.org/browse/QTBUG-36921
Bruno.
Le 11/02/2014 19:34, Bruno Coudoin a écrit :
After publishing my application in the play store I am not seing my
application on Nexus 7 first gen. Looking at some forums I found
Mike wrote:
Sent: Wednesday, 19 February 2014 9:05 AM
I have what seems to be an obvious question/answer but the subtleties may
not be what I think they are. We have a project with about 500 files most
of
which inherit from QObject or QWidget which means they all have moc run
on them.
On Feb 18, 2014, at 7:48 PM, Tony Rietwyk t...@rightsoft.com.au wrote:
Mike wrote:
Sent: Wednesday, 19 February 2014 9:05 AM
I have what seems to be an obvious question/answer but the subtleties may
not be what I think they are. We have a project with about 500 files most
of
which
Look at the problem from the other side:
1) separate moc_*.cpp has to be compiled only during full [re]builds
or when the corresponding class' header file is changed;
2) when moc_*.cpp is #include-d into the implementation .cpp file,
they are both compiled at every change.
I think it's pretty
30 matches
Mail list logo