Re: [Interest] QtHttpServer License
Hello André, judging by marketing changes coming from The Qt Company [1] since at least 2020, I would generally not expect a GPL to LGPL switch in any foreseeable future. If this is an important component in your software that you rather implement with Qt, you can look into Qt commercial licensing (but considering [2]). [1] https://www.qt.io/blog/qt-offering-changes-2020 [2] https://burkhardstubert.substack.com/p/do-not-sign-the-qt-license-agreement Cheers Dmitriy On Fri, Oct 11, 2024 at 10:32 AM A. Klitzing wrote: > Hi, > > We currently use http_parser with custom code in our EUPL licensed > software. But we would like to switch to QtHttpServer. However, the > GPL seems to prevent us from doing so. Will the QtHttpServer module > also be available under LGPL in the medium term? > > Best regards >André Klitzing > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Installer problems
To be honest, I've been experiencing a similar issue for the past several weeks, but the timeouts were mainly during repo refresh. After a couple of retries, it worked again, and visiting download.qt.io in the browser also worked without timeouts, so I always thought this was some problem on my end. It also happened on different machines. Cheers Dmitriy On Tue, Jul 4, 2023 at 5:29 AM Tino Pyssysalo via Interest < interest@qt-project.org> wrote: > Could you please file a bug, so we can study and fix the problems? 33% > success rate sounds really poor. Socket time-outs have not been a common > issue. > > > > Tino Pyssysalo > > Installer product manager > > The Qt Group > > > > > > On 3.7.2023, 15.49, "Interest on behalf of Turtle Creek Software" < > interest-boun...@qt-project.org on behalf of supp...@turtlesoft.com> > wrote: > > > > To diagnose a recent problem, we needed to install Qt on several different > computers with different Qt and OS setups. > > > > The open source installer has about a 33% success rate. It gives several > hash and socket time-out errors along the way, then often aborts > completely. At that point it deletes all previously downloaded files, even > if 1GB done out of 1.13GB. > > > > I think the design probably can be improved. Every other app download > goes OK here. Even if interrupted, they finish the remainder later. > > > > Thanks, Casey McDermott > > TurtleSoft.com > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] can't dump QStringList with qDebug()
Hi,
I'm sure you have already tried it, but just a wild guess: do you have
#include in this .cpp file?
Cheers
Dmitriy
On Tue, Mar 7, 2023 at 11:04 AM Hamish Moffatt via Interest <
interest@qt-project.org> wrote:
> On 7/3/23 20:11, Kai Köhne wrote:
> > Hi,
> >
> > This looks like a compiler issue to me.
> >> const auto connections = QSqlDatabase::connectionNames();
> >> qDebug() << "Closing open connections:" << connections;
> >>
> >> claiming that
> >> ../../../src/server/server_database.cpp:691:45: error: invalid operands
> to binary expression ('QDebug' and>
> >> 'const QList')
> > I think this is the place where it goes wrong:
> >
> >> ../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qdebug.h:217:53: note:
> candidate template ignored: requirement
> 'std::conjunction_v,
> QString>, QTypeTraits::has_ostream_operator>>' was
> not satisfied [with T = QString]
> >> inline QDebugIfHasDebugStreamContainer, T> operator<<(QDebug
> debug, const QList &vec)
> >> ^
> > Anyhow, I couldn't reproduce this in a minimal example (and apparently
> you didn't manage either?). At minimum we need the exact compiler +
> compiler options passed on command line.
>
>
> It's happening in both Visual C++ and gcc 10, but on further
> investigation, only in one .cpp file; the same code in other files works
> fine. I'll keep investigating.
>
>
> thanks
>
> Hamish
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Windows installer for Qt programs
Hello Alexander, you could try Qt Installer Framework: https://doc.qt.io/qtinstallerframework/index.html Cheers Dmitriy On Tue, Apr 21, 2020 at 9:20 AM "Alexander Carôt" wrote: > Hello all, > > I consider shipping my Qt built software with a conventional installer on > Windows. > > Can anyone give me a recommendation of a solid freeware for this purpose ? > > Thanks in advance, > best > > Alex > > -- > http://www.carot.de > Email : alexan...@carot.de > Tel.: +49 (0)177 5719797 > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Stepping into Qt sources (Qt 5.14, MinGW 64-bit)
I agree with Ulf, sometimes stepping into release sources gives you a rough idea of what is going on, assess whether you can fix it and if it is reasonable to go through the whole process of building/debugging your own Qt version. That's not what I usually do in my work, so it takes an effort. Cheers Dmitriy On Mon, Jan 27, 2020 at 5:31 PM Ulf Hermann wrote: > > Stepping into -O2 builds (-O3 for QtCore and QtGui) is painful at best. > The > > debug information we provide is not usable for more than getting > backtraces to > > help the developer solving issues. > > Stepping into optimized builds is kind of an annoyance but, at least for > me, it is much less of a pain than you make it sound. When I'm are > looking for the kind of bugs that only occur in release builds, due to > some race condition or some optimization/UB my code didn't account for, > it is _very_ handy to have the debug symbols for the officially > distributed builds. Also, the above mentioned backtraces alone are worth > every single byte of debuginfo we provide. Therefore, debug symbols for > release builds are important and QTBUG-81354 needs to be fixed. > > Ulf > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Stepping into Qt sources (Qt 5.14, MinGW 64-bit)
Hi Thiago, thanks for clarifying! Will do Cheers Dmitriy On Sun, Jan 26, 2020 at 12:23 AM Thiago Macieira wrote: > On Saturday, 25 January 2020 10:53:23 PST Dmitriy Purgin wrote: > > With version 5.14 I can't debug into the Qt sources anymore, although > I've > > installed both Qt Debug Information Files and Sources using the online > > installer. I don't think it actually installed the debug information > files > > though because the online installer shows "0.00 bytes" next to the marked > > "Qt Debug Information Files" when I start it again. After a quick look in > > the installation folder, I don't see anything related to debugging. I > would > > expect d-suffixed libraries, enormously big .libs or .dlls, or something > > .pdb-like. > > > > Is there anything I miss? How can I debug into Qt 5.14 without having to > > compile it myself, just as it worked before? > > You're not missing anything. The MinGW binaries now match the Linux ones: > no > debug libraries anymore. > > If you want to step into Qt source, compile from source with debug > information. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Stepping into Qt sources (Qt 5.14, MinGW 64-bit)
Hi all, Since 5.14 the MinGW version of Qt does not include debug libraries. With the previous versions of Qt, if I wanted to step into the Qt sources, I used to install the sources with the online installer, pointed to the sources directory in Debugger Options in Qt Creator, and it just worked. With version 5.14 I can't debug into the Qt sources anymore, although I've installed both Qt Debug Information Files and Sources using the online installer. I don't think it actually installed the debug information files though because the online installer shows "0.00 bytes" next to the marked "Qt Debug Information Files" when I start it again. After a quick look in the installation folder, I don't see anything related to debugging. I would expect d-suffixed libraries, enormously big .libs or .dlls, or something .pdb-like. Is there anything I miss? How can I debug into Qt 5.14 without having to compile it myself, just as it worked before? Thanks & cheers Dmitriy ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
Hi Giuseppe, > This trick is used in several places in Qt itself (look for "includemoc" > in commits). Not only it helps build times but also it produces slightly > better code overall. Could you please elaborate what exactly do you mean under 'better code'? How does including the xxx_moc.cpp affect the code generation by moc? If moc decides to generate a better code when included explicitly in a cpp file, why can't it generate the same better code otherwise? Is there a technical reason for it? Thanks! Cheers Dmitriy On Fri, Dec 6, 2019 at 9:49 AM Giuseppe D'Angelo via Interest < interest@qt-project.org> wrote: > Il 06/12/19 09:42, Uwe Rathmann ha scritto: > > Something you can try is to include the moc file at the end of your cpp > > file. This can be done like this: > > > > #include "moc_XYZ.cpp" > > > > This type of construction is at least supported by qmake. > > > > This does not reduce the number of moc runs, but it reduces the number > > of compiler runs. As a rule of thumb for not too large classes I would > > expect, that ~50% of the compile time is spent inside the Qt headers and > > by including the moc file the overall compile time goes down by 33% as > > the headers need to be processed only once. > > This trick is used in several places in Qt itself (look for "includemoc" > in commits). Not only it helps build times but also it produces slightly > better code overall. > > HTH, > -- > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Android: can QCoreApplication::exec() be terminated unexpectedly?
Hi Alexander, I'm not an Android expert nor have I written a Qt/Android application other than small demos but what I remember from Java/Android application lifecycle, an application consists of "activities" that may be paused/unloaded/terminated by the operating system at any time due to various reasons [1]. In a Java application, you get to override the corresponding methods that the OS calls when a lifecycle event occurs, and it is the programmer's responsibility to save and restore the state of the application. Maybe this is what's happening in your Qt application as well? Just a guess. [1] https://developer.android.com/guide/components/activities/intro-activities Cheers Dmitriy On Sat, Nov 30, 2019 at 1:36 PM Alexander Dyagilev wrote: > Hello, > > It seems that my app "suffers" from unexpected terminating of > QCoreApplication::exec() event loop processing. > > I was always thinking that QCoreApplication::exec() terminates only if > one calls QCoreApplication::quit(). > > But under Android it seems that either QCoreApplication::quit() is > somehow called by Qt itself (i.e. not by my code), or it's terminated > due to an unknown (for me) reason. > > I use QApplication for main activity process and QAndroidService for > service process. Don't know exactly inside what process this occurs. > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Fwd: windeployqt
Sorry, forwarding this back to the mailing list -- Forwarded message - From: Dmitriy Purgin Date: Wed, Nov 27, 2019 at 8:12 PM Subject: Re: [Interest] windeployqt To: Jason H Hi Jason, which command line arguments did you use in windeployqt, which directory structure does your application have and did you add Qt paths to the environment of the command line before running windeployqt? I know that the documentation for windeployqt was quite obscure last time I checked, especially regarding the deployment of QML applications. You should especially pay attention to specifying the path to your application's QML files so that windeployqt can resolve the dependencies. In the resulting deployment you should get the compiler/C/C++ runtime (like libgcc.., libstdc++... in case of MinGW; msvcrt...something in case of VC++), Qt dlls (like QtCore, QtGui, QtQuick, ... and whatever your application is using), a subdirectory with platform plugins (this will probably be qwindows.dll) and (important) a lot of subdirectories with QML modules even with those that your application does not use explicitly. If you double click the application or start it from the console and nothing happens, you should look into the task manager: if the process of your app is running but you see nothing then the QML part of the application probably has a fault. Mostly this is because of import paths or windeployqt being unable to resolve the QML dependencies correctly. You can also debug it by building your application with CONFIG += console, in this case, you will get a terminal window with QML errors if this is the case. Cheers Dmitriy On Wed, Nov 27, 2019 at 7:56 PM Jason H wrote: > I tried to use windeployqt to create a QML application directory structure > to run on a system without Qt. > I placed the resulting directory tree on the system and got nothing. Like > I double clicked the .exe and nothing happened. So I went to the command > line (cmd.exe) It just gave me the prompt back. No window was created. > > I loaded it up in depends.exe on the system that built it and I only noted > two things: > 1. QtCore5.dll had an invalid signature > 2. The app was linking against i386 and x64 libraries. > > I don't know if those were the problems though. > > > How do I debug this? > > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] qtcreator cpu usage
Hi, try turning off the Clang Code Model plugin and see if it helps Cheers Dmitriy On Wed, Feb 6, 2019 at 8:41 PM jlk wrote: > Every once in a while Qt Creator (5.12.0 linux, and also previous > version) revs my laptops fans up to maximum speed for about a minute > when nothing is going on (no building, nothing running, a couple of > projects open). I notice it once every week or two. What is it doing? > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] clang-tidy version in Qt Creator
Well, try turning on more clang-tidy and clazy checks than the default shipment of Qt Creator has! ;-) With a project of a decent size your PC's fans will be blowing all the time like mining is still a thing! Cheers On Tue, Feb 5, 2019 at 1:04 PM Nikos Chantziaras wrote: > On 05/02/2019 09:34, Nikolai Kosjar wrote: > > On 2/4/19 10:18 PM, Bernhard Lindner wrote: > >> Is there a way to switch/select the clang-tidy version used by Qt > Creator for static code > >> analysis on Linux? > > > > No as Qt Creator can only use the shipped/customized clang binary for > > this. While this come with some advantages (performance in case tidy and > > clazy checks are requested, same lib interface), it does not permit > > switching versions that easily. > > Since performance in static analysis is not actually important, it would > be better if Creator would be able to use external clang binaries for this. > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Weird sizing in Qt Designer 5.12.0 with hi-res screen
Off topic but out of curiosity: what is the software you have on your screenshot? A harmony learning helper or some kind of a harmony progression generator? Cheers Dmitriy On Wed, Jan 23, 2019 at 2:52 AM Tony Rietwyk wrote: > Hi Everybody, > > I have recently installed a hi-res screen 3840 x 2160 @ 150% scaling on > my Windows 10 machine. > > The attached screen capture has Qt Designer on the right of the actual > running dialog, with a screen ruler on top of the designer. You can see > the following: > > - Designer is showing the form at double the size it should be (1200 for > a form at minimum size 600 high). > > - Even the grid spacing has been stretched. > > - We do not set any of the newer high-res related settings at run time, > so the dialog appears at the expected 600 pixels high. Instead we use > style sheets to adjust fonts, images, etc. > > Why is Designer doing this? Where is it getting the factor of 2 from? > How do I get it to display the form at the correct size? > > Regards, Tony > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to deal with database specific syntax
Exactly, that's what I meant by "supporting the stored procedure call syntax". Sorry, it was a bit vague. Anyway, in this case you're implementing a single interface for an SP call backed by multiple "syntax handlers" which is much easier than handling lots of syntactic differences for any kind of operations one might want to do with a database. It's not ideal, it has its drawbacks but it also has advantages. Moreover, pmqt71 has explicitly stated that he/she doesn't want to go the ORM way. Cheers 2015-02-12 12:26 GMT+06:00 alexander golks : > Am Thu, 12 Feb 2015 08:59:18 +0600 > schrieb Dmitriy Purgin : > > > Hi, > > > > Actually I don't think it's a Qt-related question but here's my approach > to > > it. > > > > Since you struggle with both syntaxes, you may want to try and > encapsulate > > SQL code to stored procedures on the DB side and by that I mean not only > > simple data retrieval or updating but also the business logic. You are > > still obliged to support both DB backends but at least it will reduce the > > dependencies in your C++ program down to supporting the stored procedure > > call syntax which is pretty simple. Here you may also gain a performance > > boost since the data operations are as close to data as it can be. > > ifair, each driver may handle stored procedure calls differently (1). > some need special handling for multiple result sets, others need special > handling for in/out values. > so you may still need to handle different "syntax" foreach driver. > > [1] http://doc.qt.io/qt-5/sql-driver.html > > > > > Regards > > Dmitriy Purgin > > > > 2015-02-11 18:54 GMT+06:00 pmqt71 : > > > > > Hi all, > > > > > > in my Qt application I've to duplicate sql instructions for MySql and > > > Postgres due to different sql syntax. > > > Most problems are on date types. For instance, MySql has DATEDIFF, > > > Postgres has EXTRACT, CAST... > > > > > > Without using ORMs, is there a way to manage specific sql syntax? > > > > > > > > > Thanks > > > pm > > > > > > > > > ___ > > > Interest mailing list > > > Interest@qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/interest > > > > > > > > > -- > /* > * "There's definitely something wrong here." > * > * Husse Jul 11 2007 > */ > > ___ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to deal with database specific syntax
Hi, Actually I don't think it's a Qt-related question but here's my approach to it. Since you struggle with both syntaxes, you may want to try and encapsulate SQL code to stored procedures on the DB side and by that I mean not only simple data retrieval or updating but also the business logic. You are still obliged to support both DB backends but at least it will reduce the dependencies in your C++ program down to supporting the stored procedure call syntax which is pretty simple. Here you may also gain a performance boost since the data operations are as close to data as it can be. Regards Dmitriy Purgin 2015-02-11 18:54 GMT+06:00 pmqt71 : > Hi all, > > in my Qt application I've to duplicate sql instructions for MySql and > Postgres due to different sql syntax. > Most problems are on date types. For instance, MySql has DATEDIFF, > Postgres has EXTRACT, CAST... > > Without using ORMs, is there a way to manage specific sql syntax? > > > Thanks > pm > > > ___ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtConcurrent and event-driven objects
Hello, thanks for answering. Sorry, I might have described it not clear enough. Tasks that utilize timers and sockets are actually quite separate tasks. I used the code posted just to show the execution context. I'll start with tasks using timers. These are executed once in a minute to do some simple jobs: check for license availability, call a stored procedure in DB to perform scheduled cleanup or look if the database has some notifications to send. I like your idea from 2), seems to be the way to go. But the central part of the application (I mentioned it least in my previous mail) is a QTcpServer instance which is an HTTP-like server. It doesn't use any timers but just listens to incoming connections. The listener spawns a new thread passing a socket descriptor to it upon seeing an incoming connection. Then the thread creates its own socket using the descriptor passed, reads data, processes it and writes back the response. Thus the sockets are not cross-threaded, they are created in an already spawned thread from the pool. The reason for using thread-per-connection approach is that the most connections produce database queries which are synchronous in Qt. So in this case threads are being constantly created and destroyed: typical HTTP session lifetime here is about a second or less and there is a constant load of 15-20 connections per second. I think it's a perfect place to use a QThreadPool instance reusing the threads whose runnables are done. My hesitation about QThreadPool handling connections of QTcpServer is the following: suppose that a thread is spawned by QThreadPool and a QTcpSocket instance is created in a QRunnable executed in the pool. Is this the case that any slot of a runnable connected to a QTcpSocket signal is actually executed in the thread that created the QThreadPool instance, just like it is the case for QTimer (see my prev. mail)? The documentation states you cannot start a timer or connect a socket in a thread that is not the object's thread. The object thread here is the QThreadPool's thread thus main thread (If I'm not wrong). The sockets don't seem to cause any problems with QThreadPool so far but I should clearly revert it back to my old design if it isn't supposed to work like this. Once again, my old design that uses QThread-only approach with my own thread pool worked as expected, the thing is I want to refactor my code to utilize more library facilities which seem to be less error-prone, more maintainable and unified. Thanks again for joining the discussion. Cheers Dmitriy 2015-01-27 14:28 GMT+06:00 Bo Thorsen : > On 01/26/2015 11:56 AM, Dmitriy Purgin wrote: > > Another important thing for me is network. The docs also specify that > > the network module should also follow single thread policy. Does that > > mean that an instance of QTcpSocket can't be used in QRunnable started > > by QThreadPool? > > You can only use the socket in one thread at a time. You can pass it on > to another thread, but you will find yourself with weird bugs if you do > this a lot. > > You haven't given enough information to say if this is a problem for you > or not. If the threads just send stuff over the socket, then implement > this with simple message parsing to the thread that have the socket. If > the threads handle incoming messages (which I wouldn't expect, since > you're using timers instead of handling incoming data signals), the > answer depends on whether your protocol allows out of sync answers or not. > > Bo Thorsen, > Director, Viking Software. > > -- > Viking Software > Qt and C++ developers for hire > http://www.vikingsoft.eu > ___ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QtConcurrent and event-driven objects
Hi,
I'm using Qt to power an application server with multithreaded TCP listener
and maintenence tasks running in separate threads. The TCP listener runs in
main thread and spawns a separate thread to handle socket operation. The
socket is being created when the thread is running using a socket
descriptor passed from the TCP listener. The maintenance threads hold a
timer only and run on timer shot to query DB and do stuff (doesn't really
matter).
The thing is, I have always used it like this:
// [L1] Listing 1
// this simplified sample code neglects cleanup and possible memory leaks
class MaintenanceWorker : public QObject
{
Q_OBJECT
public:
MaintenanceWorker()
: QObject(NULL),
mTimer(NULL)
{
// executes in main thread
moveToThread(&mThread);
connect(&mThread, SIGNAL(started()), this, SLOT(onThreadStarted()));
}
private slots:
void onThreadStarted()
{
// executes in spawned thread
mTimer = new QTimer();
connect(mTimer, SIGNAL(timeout()), this, SLOT(onTimerTimeout()));
mTimer->start(6);
}
void onTimerTimeout()
{
// executes in spawned thread
}
private:
QThread mThread;
QTimer* mTimer; // to be created in thread
};
After porting the project from Qt 4 to Qt 5 (using Qt 5.3 now) I've decided
to use high-level QtConcurrent facilities and namely QThreadPool for its
ability to reuse threads, control pool size and so on. So the sample code
above was transformed into this:
// [L2] Listing 2
// this simplified sample code neglects cleanup and possible memory leaks
class MaintenanceWorker : public QObject, public QRunnable
{
Q_OBJECT
public:
MaintenanceWorker()
: QObject(NULL),
mTimer(NULL)
{
// executes in main thread
}
void run()
{
// executes in spawned thread
mTimer = new QTimer();
connect(mTimer, SIGNAL(timeout()), this, SLOT(onTimerTimeout()));
mTimer->start(6);
QEventLoop loop;
loop.exec();
}
void onTimerTimeout()
{
// executes in main thread (!!!)
}
private:
QTimer* mTimer; // to be created in thread
};
// ...
QThreadPool threadPool;
threadPool.start(new MaintenanceWorker());
So the problem is that onTimerTimeout() slot runs in main thread (checked
with QThread::currentThread()). After reading the docs carefully -- which
had to be the first thing to do, my bad -- I've found that [cite1]:
- *The child of a QObject must
always be created in the thread where the parent was created.* This
implies, among other things, that you should never pass the QThread
object (this) as the parent of an
object created in the thread (since the QThread
object itself was created in
another thread).
- *Event driven objects may only be used in a single thread.*
Specifically, this applies to the timer mechanism
and the network module
. For example, you cannot
start a timer or connect a socket in a thread that is not the object's
thread .
It turns out that in case of [L2] MaintenanceWorker's thread is main thread
but in case of [L1] MaintenanceWorker's thread is the created QThread
thanks to moveToThread() call. Could anyone please tell if my conclusions
are true? If so, it's perfectly fine with me since I've found the
explanation in the docs but is there any feasible way of using timers
inside QRunnables started with QThreadPool? I've taken a quick look at
QThreadPool sources and didn't find anything moving the runnable to thread.
This can be worked around if connection type is explicitly set to
DirectConnection when connecting timer slot but is it a good practice?
Another important thing for me is network. The docs also specify that the
network module should also follow single thread policy. Does that mean that
an instance of QTcpSocket can't be used in QRunnable started by
QThreadPool?
Thanks
Cheers
Dmitriy
[cite1]
http://doc.qt.io/qt-5/threads-qobject.html#signals-and-slots-across-threads
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Best practices for making a Qt facade for a C library
Hi Damian, the application itself is GPLv3, for PulseAudio parts see [1] (every file that starts with pulseaudio). I'm planning to release the library under LGPL but didn't upload anything for public availability yet. As soon as I port all the functionality from my app to the lib, I'll make a separate repo on github. Cheers Dmitriy [1] https://github.com/dpurgin/harbour-callrecorder/tree/master/daemon/src 2015-01-14 13:27 GMT+06:00 Damian Ivanov : > Hi Dmitriy, > > Wanted to ask if your stuff is open source and is available on github? > > 2015-01-14 0:26 GMT+01:00 Ian Monroe : > > On Tue, Jan 13, 2015 at 10:57 AM, Dmitriy Purgin > wrote: > >> > >> Hello all, > >> > >> I'm developing a small Qt project for SailfishOS (a Linux distribution, > >> Meego descendant, Qt 5 based) and had to use some of PulseAudio (a sound > >> server for POSIX OSes) API functions which are pure C. I've wrapped > them in > >> a couple of classes but it's evolving to something bigger now and I'm > trying > >> to detach these into a shared library which seems to become a basic > >> PulseAudio binding. It's my first facading of a C library and I'm kind > of > >> stuck on the architecture now and hope that someone can share ideas on > that. > > > > > > Have you looked at the code generation done by QtGstreamer for glib > stuff? > > Not sure if it's any good, just want to make sure you know of it: > > http://cgit.freedesktop.org/gstreamer/qt-gstreamer/tree/ > > > >> > >> So with the problem stated, my question is: does anyone know any "good > >> practices" in designing this kind of relationships between classes or > can > >> share similar designs to look at? There's no technical problem for me to > >> expose the inner parts of some classes to some other classes, I just > >> wondered if there's a subtle way of doing this. > > > > > > I wrap a C library and had a similar situation. My solution in this case > > would be to give QtPulseAudioSource a new base class named something like > > PulseAudioInterface. That class defines pa_context, it could possibly > just > > be a void pointer. It has a member variable for it and a > > setPulseAudioContext method. Then QtPulseAudioContext would have a class > > called something likeblessPulseAudioInterface. QtPulseAudioSource could > call > > it in its constructor. > > > > In this way it is pretty hidden from users of the library, and > > QtPulseAudioContext has zero deps on AudioSource. > > > > Ian > > > > ___ > > Interest mailing list > > Interest@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/interest > > > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Best practices for making a Qt facade for a C library
Hello Ian, thanks for your reply. I think I can use some ideas from QtGstreamer, didn't really know about its existence. I'll try your approach, it feels to me so much better, but I'd prefer composition over inheritance. Thanks! Cheers Dmitriy 2015-01-14 5:26 GMT+06:00 Ian Monroe : > On Tue, Jan 13, 2015 at 10:57 AM, Dmitriy Purgin > wrote: > >> Hello all, >> >> I'm developing a small Qt project for SailfishOS (a Linux distribution, >> Meego descendant, Qt 5 based) and had to use some of PulseAudio (a sound >> server for POSIX OSes) API functions which are pure C. I've wrapped them in >> a couple of classes but it's evolving to something bigger now and I'm >> trying to detach these into a shared library which seems to become a basic >> PulseAudio binding. It's my first facading of a C library and I'm kind of >> stuck on the architecture now and hope that someone can share ideas on >> that. >> > > Have you looked at the code generation done by QtGstreamer for glib stuff? > Not sure if it's any good, just want to make sure you know of it: > http://cgit.freedesktop.org/gstreamer/qt-gstreamer/tree/ > > >> So with the problem stated, my question is: does anyone know any "good >> practices" in designing this kind of relationships between classes or can >> share similar designs to look at? There's no technical problem for me to >> expose the inner parts of some classes to some other classes, I just >> wondered if there's a subtle way of doing this. >> > > I wrap a C library and had a similar situation. My solution in this case > would be to give QtPulseAudioSource a new base class named something like > PulseAudioInterface. That class defines pa_context, it could possibly just > be a void pointer. It has a member variable for it and a > setPulseAudioContext method. Then QtPulseAudioContext would have a class > called something likeblessPulseAudioInterface. QtPulseAudioSource could > call it in its constructor. > > In this way it is pretty hidden from users of the library, and > QtPulseAudioContext has zero deps on AudioSource. > > Ian > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Best practices for making a Qt facade for a C library
Hello all,
I'm developing a small Qt project for SailfishOS (a Linux distribution,
Meego descendant, Qt 5 based) and had to use some of PulseAudio (a sound
server for POSIX OSes) API functions which are pure C. I've wrapped them in
a couple of classes but it's evolving to something bigger now and I'm
trying to detach these into a shared library which seems to become a basic
PulseAudio binding. It's my first facading of a C library and I'm kind of
stuck on the architecture now and hope that someone can share ideas on
that.
Obviously, I'm looking forward to encapsulate all the C code in my library
and provide library users with Qt-style classes, signals and slots, thus
eliminating libpulse dependency for them. My basic architecture is quite
simple: for the Qt classes I use d-pointers containing relevant PulseAudio
data and static methods to use for PulseAudio callbacks which are called
for any kind of events. To emit Qt signals upon PulseAudio events I use
q-pointers in these static methods. So this goes like this:
// in pseudocode suspiciously resembling C++
class QtPulseAudioContext : public QObject
{
...
signals:
void connected();
private:
QtPulseAudioContextPrivate* d;
};
class QPulseAudioContextPrivate
{
pa_context* paContext; // PulseAudio C data
QtPulseAudioContext* q;
// callback for PulseAudio event
static void onContextCallback(..., void* userData)
{
QtPulseAudioContextPrivate* d = reinterpret_cast<
QtPulseAudioContextPrivate* >(userData);
// processed an event from PulseAudio, redo it Qt style
emit d->q->connected();
}
};
As for now I'm dealing with three PulseAudio objects: "context"
representing connection to PulseAudio server, "sinks" representing audio
outputs and "sources" representing audio inputs. Naturally, I've wrapped
them as three separate classes. Both sinks and sources operate within
single context and any PulseAudio API call involving sinks and sources must
provide the corresponding context. When these classes were bundled in my
application, I've passed PulseAudio's pa_context* to a ctor of my class,
used it internally and was pretty happy with that:
// in pseudocode suspiciously resembling C++
class QtPulseAudioContext
{
QtPulseAudioSource* getSource(...);
};
QtPulseAudioSource* QtPulseAudioContext::getSource(...)
{
...
new QtPulseAudioSource(d->paContext);
...
}
class QtPulseAudioSource
{
QtPulseAudioSource(pa_context* context); // pa_context is PulseAudio
stuff
// the implementation of the following would need to call
// PulseAudio API and use pa_context
void setDefaultPort(const QString& name);
};
Now passing pa_context is a no-go since it exposes PulseAudio dependency to
a library user. So my first call is to somehow provide
QtPulseAudioContext's private data to a source or sink constructors or even
construct their private data in QtPulseAudioContext. I don't think any of
both is a good way. The former violates the incapsulation of
QtPulseAudioContext, the latter moves initialization of a private data
outside the class that owns this data.
So with the problem stated, my question is: does anyone know any "good
practices" in designing this kind of relationships between classes or can
share similar designs to look at? There's no technical problem for me to
expose the inner parts of some classes to some other classes, I just
wondered if there's a subtle way of doing this.
Thanks in advance.
Best regards,
Dmitriy
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QThreadPool & writing to the DB
Also, if you're using QThreadPool::globalInstance(), keep in mind that
it's max thread count is set to number of cores on the system by
default [1]. If you're using an instance of QThreadPool (set by
default) for long-running threads as well as for DB queries, you could
end up in a situation where the query threads are queued for running
instead of actual running [2].
[1] http://qt-project.org/doc/qt-4.8/qthreadpool.html#maxThreadCount-prop
[2] http://qt-project.org/doc/qt-4.8/qthreadpool.html#start
2014-08-19 17:46 GMT+06:00 Dmitriy Purgin :
> Hi,
>
> In addition to what Sze-Howe told, you should consider the backend
> used by the Qt database driver. In your case of SQLite you could end
> up in a situtation where multiple simultaneous INSERT queries
> seriously degrade the performance of SQLite engine which uses file
> locks to isolate transactions.
>
> Cheers
>
> 2014-08-18 12:26 GMT+06:00 Igor Mironchik :
>> Hi.
>>
>> I want to move write to DB operation to another thread (from the GUI
>> thread). And I implemented the following QRunnable:
>>
>>
>> //
>>
>> // SourcesLogWritter
>>
>> //
>>
>>
>> class SourcesLogWritter
>>
>> : public QRunnable
>>
>> {
>>
>> public:
>>
>> SourcesLogWritter()
>>
>> {
>>
>> setAutoDelete( false );
>>
>> }
>>
>>
>> void setData( const QDateTime & dateTime,
>>
>> const QString & channelName,
>>
>> Como::Source::Type type,
>>
>> const QString & sourceName,
>>
>> const QString & typeName,
>>
>> const QVariant & value,
>>
>> const QString & desc )
>>
>> {
>>
>> m_dateTime = dateTime;
>>
>> m_channelName = channelName;
>>
>> m_type = type;
>>
>> m_sourceName = sourceName;
>>
>> m_typeName = typeName;
>>
>> m_value = value;
>>
>> m_desc = desc;
>>
>> }
>>
>>
>> void run()
>>
>> {
>>
>> QSqlQuery insert( QLatin1String(
>>
>> "INSERT INTO sourcesLog ( dateTime, channelName, type,
>> "
>>
>> "sourceName, typeName, value, desc ) "
>>
>> "VALUES ( ?, ?, ?, ?, ?, ?, ? )" ) );
>>
>>
>> insert.addBindValue( dateTimeToString( m_dateTime ) );
>>
>> insert.addBindValue( m_channelName );
>>
>> insert.addBindValue( (int) m_type );
>>
>> insert.addBindValue( m_sourceName );
>>
>> insert.addBindValue( m_typeName );
>>
>> insert.addBindValue( m_value.toString() );
>>
>> insert.addBindValue( m_desc );
>>
>>
>> insert.exec();
>>
>> }
>>
>>
>> private:
>>
>> QDateTime m_dateTime;
>>
>> QString m_channelName;
>>
>> Como::Source::Type m_type;
>>
>> QString m_sourceName;
>>
>> QString m_typeName;
>>
>> QVariant m_value;
>>
>> QString m_desc;
>>
>> }; // class SourcesLogWritter
>>
>> Is it OK to launch this runnable every time when I need to write to the log?
>>
>> I do the following:
>>
>> d->m_sourcesLogWritter->setData( dateTime, channelName,
>>
>> type, sourceName, typeName, value, desc );
>>
>>
>> QThreadPool::globalInstance()->start(
>>
>> d->m_sourcesLogWritter.data() );
>>
>> And what if previous operation is still not finished and I will launch
>> another?
>>
>> Thanks.
>>
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QThreadPool & writing to the DB
Hi,
In addition to what Sze-Howe told, you should consider the backend
used by the Qt database driver. In your case of SQLite you could end
up in a situtation where multiple simultaneous INSERT queries
seriously degrade the performance of SQLite engine which uses file
locks to isolate transactions.
Cheers
2014-08-18 12:26 GMT+06:00 Igor Mironchik :
> Hi.
>
> I want to move write to DB operation to another thread (from the GUI
> thread). And I implemented the following QRunnable:
>
>
> //
>
> // SourcesLogWritter
>
> //
>
>
> class SourcesLogWritter
>
> : public QRunnable
>
> {
>
> public:
>
> SourcesLogWritter()
>
> {
>
> setAutoDelete( false );
>
> }
>
>
> void setData( const QDateTime & dateTime,
>
> const QString & channelName,
>
> Como::Source::Type type,
>
> const QString & sourceName,
>
> const QString & typeName,
>
> const QVariant & value,
>
> const QString & desc )
>
> {
>
> m_dateTime = dateTime;
>
> m_channelName = channelName;
>
> m_type = type;
>
> m_sourceName = sourceName;
>
> m_typeName = typeName;
>
> m_value = value;
>
> m_desc = desc;
>
> }
>
>
> void run()
>
> {
>
> QSqlQuery insert( QLatin1String(
>
> "INSERT INTO sourcesLog ( dateTime, channelName, type, "
>
> "sourceName, typeName, value, desc ) "
>
> "VALUES ( ?, ?, ?, ?, ?, ?, ? )" ) );
>
>
> insert.addBindValue( dateTimeToString( m_dateTime ) );
>
> insert.addBindValue( m_channelName );
>
> insert.addBindValue( (int) m_type );
>
> insert.addBindValue( m_sourceName );
>
> insert.addBindValue( m_typeName );
>
> insert.addBindValue( m_value.toString() );
>
> insert.addBindValue( m_desc );
>
>
> insert.exec();
>
> }
>
>
> private:
>
> QDateTime m_dateTime;
>
> QString m_channelName;
>
> Como::Source::Type m_type;
>
> QString m_sourceName;
>
> QString m_typeName;
>
> QVariant m_value;
>
> QString m_desc;
>
> }; // class SourcesLogWritter
>
> Is it OK to launch this runnable every time when I need to write to the log?
>
> I do the following:
>
> d->m_sourcesLogWritter->setData( dateTime, channelName,
>
> type, sourceName, typeName, value, desc );
>
>
> QThreadPool::globalInstance()->start(
>
> d->m_sourcesLogWritter.data() );
>
> And what if previous operation is still not finished and I will launch
> another?
>
> Thanks.
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QHash memory management
Hi, take a look at qDeleteAll() function: http://qt-project.org/doc/qt-5/qtalgorithms.html Cheers 2014-08-06 3:50 GMT+06:00 Giuseppe D'Angelo : > On 5 August 2014 23:24, preeteesh kakkar wrote: >> Yes, you do need to delete them. You can keep them as scoped_ptr instead of >> raw pointer. > > You can't use scoped / unique ptr inside of a Qt container because > they're not copiable. A shared pointer works, though. > > -- > Giuseppe D'Angelo > ___ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Preventing QUrl from encoding query parameters
Hi,
If you pass this raw QString or QByteArray somewhere, why use QUrl
then? Anyway, try QUrl::fromPercentEncoding():
QUrl url("http://example.com?query=[{\"name\":\"value\"}]";);
qDebug() << QUrl::fromPercentEncoding(url.toEncoded());
// produces: "http://example.com?query=[{"name":"value"}]";
Cheers
2014-08-02 5:33 GMT+06:00 Lorne Sturtevant :
> I am to connect to a 3rd party API over http. This API does not accept
> requests that the URLs that are properly percent encoded for invalid
> characters. For example. It requires urls to be of the form:
> http://example.com?query=[{"name":"value"}].
>
> I create the QUrl like this:
> QUrl url =
> QUrl::fromEncoded("http://example.com?query=[{\"name\":\"value\"}]";);
>
> url.toString() shows that the string is percent encoded as
> http://example.com?query=[%7B%22name%22:%22value%22%7D] as it should
> be. The problem is that the 3rd part API can't handle the percent
> encoded form.
>
> I've tested this with curl as well:
> curl http://example.com?query=[{"name":"value"}] returns the correct result.
> curl http://example.com?query=[%7B%22name%22:%22value%22%7D] returns an
> error from the 3rd party API.
>
> So my question is. How can I force QUrl not to percent encode the URL?
> Even though it's an error, I want QUrl to ignore it and just use the raw
> string I provide.
>
> --
> Lorne Sturtevant
> Sum Ergo Cogito
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Server application is crashing.
Hello, btw have you considered upgrading to Qt 5? I have done such a migration in February this year for the sake of JSON parser and PCRE backend for regular expressions. The whole process took about two weeks with extensive testing, there isn't really much to do if you didn't use Qt3-compatibility classes. Our server application uses QtCore, QtNetwork, QtSql and QtXml and performs mostly SQL quering, serving static content and proxying some requests to other servers. Cheers Dmitriy Purgin 2014-07-07 16:11 GMT+06:00 william.croc...@analog.com : > On 07/06/2014 10:19 PM, Thiago Macieira wrote: >> On Sunday 06 July 2014 19:46:25 Bill Crocker wrote: >>> #0 0x083ff8ef in QResourceFileEngineHandler::create(QString const&) const >>> () >>> #1 0x0848ffdf in QAbstractFileEngine::create(QString const&) () >> >> These functions no longer exist in Qt 5 or 4.8. >> >> So whatever the problem was, it's no longer valid. >> > > Well then I will upgrade to 4.8.6 > again and take it from there. > > Thanks. > > Bill > ___ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Qt 5.2.1 on Linux: QAudioInput::bytesReady() behaviour
Hi there,
I'm writing an application capturing raw audio from two mono inputs
simultaneously and then encoding it with 3rd party library into one
stereo data stream (one channel per input). Since each pass of the
encoder should be fed with equal number of samples of each channel, at
some point in my program I have to know how many samples are available
from both inputs. Unfortunately, neither QAudioInput::bytesReady() nor
QIODevice::bytesAvailable() seem to do the solid job for me.
I've reduced my program down to simple mono channel audio capture to
illustrate the problem. So the code is pretty straight-forward (using
push mode):
class Application : public QCoreApplication
{
// ...
QAudioInput* mAudioInput;
QIODevice* mIoDevice;
};
Application::Application(/* ... */): QCoreApplication(/* ... */)
{
QAudioFormat audioFormat;
// audio format initialization skipped
mAudioInput = new
QAudioInput(QAudioDeviceInfo::defaultInputDevice(), audioFormat);
mIoDevice = mAudioInput->start();
connect(mIoDevice, SIGNAL(readyRead()),
this, SLOT(onIoDeviceReadyRead()));
}
void Application::onIoDeviceReadyRead()
{
qDebug() << "mAudioInput->state(): " << mAudioInput->state() <<
", mAudioInput->bytesReady(): " << mAudioInput->bytesReady();
// this always returns 0
qDebug() << "mIoDevice->bytesAvailable(): " << mIoDevice->bytesAvailable();
// this always shows some data
qDebug() << "mIoDevice->readAll().size(): " << mIoDevice->readAll().size();
}
The problem is, I don't know how to check reliably how much data is
available before reading. QAudioInput::bytesReady() always shows zero
on first call of onIoDeviceReadyRead(), although some data is always
read with QIODevice::readAll(). If I do not actually read the data
then QAudioInput::bytesReady() increases on subsequent calls, although
actually read data is naturally bigger than the values shown by
QAudioInput::bytesReady(). If I call QIODevice::readAll() on every
pass of onIoDeviceReadyRead(), there is a rare occurrence of non-zero
value in QAudioInput::bytesRead() which is always smaller than
actually read data.
I worked this around using a supplementary buffer of QByteArray being
appended by QIODevice::readAll() whenever QIODevice::readyRead() is
emitted, although it doesn't seem to be efficient due to repeated
remove() calls after the samples are processed by the encoder.
Could someone please tell if there is a way of "peeking" available
bytes in QIODevice without actually reading from it? If yes, would
unread bytes persist in QIODevice until next readyRead(), just like it
does in QTcpSocket?
Thanks in advance.
Cheers
Dmitriy Purgin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
