Qt-interest Archive, March 2008
Re: Multiple QApplication support
Message 1 in thread
You can't have multiple QApplication instances in a single application. This
is a fundamental restriction in Qt.
Why would you even want to do that? You should be able to merge the code of
your two applications and get rid of the QApplication object in one of them.
Put the python interpreter in it's own thread and use queued connects to pass
data between the threads.
I wrote a code generator a while ago that you could use for inspiration on how
to embed the python code. You can find it at
http://www.thorsen-consulting.dk/freebies.html in the download box in the
upper right corner.
Sincerely,
Bo Thorsen.
On fredag den 29. Februar 2008, Luke Campagnola wrote:
> I'm going to repeat a theme that I've read in a few posts, but haven't
> really seen any satisfactory answer to (So I apologize if I've just missed
> the answer). The basic problem is combining two independent qt-enabled
> applications together in an elegant/seamless manner. Here's an example:
>
> I have one data acquisition application written in C++ with Qt. I also have
> analysis software written in python with Qt. I want to combine these two
> applications together by embedding a python interpreter into the C++ app,
> but for various reasons it is not possible to have the two running in the
> same thread. This situation is impossible, however, since there can be only
> one QApplication event loop running in the entire application.
>
> A great solution would be to simply allow the creation of multiple
> QApplication instances that do not communicate (except possibly by event
> posting or other means). This way the python application can easily run on
> its own or embedded, regardless of whether the C++ application is already
> using Qt.
>
> I've seen this problem a few different times--people implementing plugins
> from preexisting applications, people running multiple threads that need to
> control their own GUIs, etc.
>
> So my questions are:
>
> 1) How have people worked around this problem? Anything really elegant? (or
> is my understanding of the problem totally off-base?)
>
> 2) Is there a good reason that we can't have multiple QApplication
> instances running in multiple threads, as long as they simply behave as
> independent applications?
>
>
> Thanks,
> Q
--
[ signature omitted ]
Message 2 in thread
On Sat, Mar 1, 2008 at 3:10 AM, Bo Thorsen <bo@xxxxxxxxxxxxxxxxxxxxx> wrote:
> You can't have multiple QApplication instances in a single application. This
> is a fundamental restriction in Qt.
>
> Put the python interpreter in it's own thread and use queued connects to pass
> data between the threads.
Thanks for pointing this out--I've been using Qt 3 and hadn't noticed
this new feature yet. The ability to run multiple concurrent event
loops goes a long way toward making the problem simpler.
> Why would you even want to do that? You should be able to merge the code of
> your two applications and get rid of the QApplication object in one of them.
My current solution is to have the python script pass a function
pointer to the C++ app, which then posts an event to the GUI thread so
that it can create the interface on behalf of the python script. This
works, but it's a hassle and a very roundabout way of solving a simple
problem. A much easier solution would be for me to just tk or gtk in
python so I don't have to worry about the conflict, but of course
that's rediculous and forces me to abandon Qt, which I love dearly. As
a more extreme example, let's say I don't have access to the code in
one application or the other.
The straightforward approach, from my point of view, is to simply
allow each thread to create its own dialogs and manage them with its
own event loop. This way it is not necessary for the script and
application to have any knowledge about whether the other is already
using Qt, and if so, how to gain access to the GUI thread. This is why
I have seen this question come up so many times with plugin
architectures--a plugin API should only expose the parts of the
application that are relevant to the plugin. If the GUI is not
explicitly part of that, then it should be left out of the API, and
the plugin should have the option of managing its own GUI if desired.
I think my point is more a matter of principle--if two threads want to
run their own GUIs independently, there's no reason to force them to
cooperate and manage a single GUI thread. Perhaps there's a design
consideration in Qt that I have missed, but it seems to me that if we
can run multiple event loops, each loop should be able to manage its
own widgets.
Thanks for your response, please let me know if I'm way off-base here :)
Luke
--
[ signature omitted ]
Message 3 in thread
Luke Campagnola wrote:
> On Sat, Mar 1, 2008 at 3:10 AM, Bo Thorsen <bo@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
>> You can't have multiple QApplication instances in a single application. This
>> is a fundamental restriction in Qt.
>>
It's actually worse than that - IIRC this is a fundamental restriction
of Win32 at the very least; I seem to remember that this is true of some
Linux setups as well.
At the risk of talking out the, er, wrong end as it were... my
understanding is that in Win32, you must have exactly one GUI event
loop. You may have more event loops... but the UI's events will all go
there. (Presumably, you can break this rule by using the hooking
functions, but that is in the realms of Dark Magic, sez I.)
> A much easier solution would be for me to just tk or gtk in
> python so I don't have to worry about the conflict, but of course
> that's rediculous and forces me to abandon Qt, which I love dearly. As
> a more extreme example, let's say I don't have access to the code in
> one application or the other.
>
*cough* http://www.froglogic.com/tq
Just sayin'. :)
(What, you mean you don't want to add a third language to the mix?
Whyever not...? hehe...)
> I think my point is more a matter of principle--if two threads want to
> run their own GUIs independently, there's no reason to force them to
> cooperate and manage a single GUI thread. Perhaps there's a design
> consideration in Qt that I have missed, but it seems to me that if we
> can run multiple event loops, each loop should be able to manage its
> own widgets.
>
See also my response to Bo...
So note that my original quandary was a different situation, in that in
many cases I do not have control of the base GUI application in any way,
and I am running a non-GUI Qt DLL on top of it... but that *sometimes*
that DLL might be hosted by a Qt-based GUI application. For example, in
one project my normal runtime environment is as an extension of Windows
Explorer - but one of the tricks that Google Desktop pulls is that it
"pretends" to be Explorer, and thus loads all of its extensions... and
yep, it's a Qt4 app. Hence my confusion.
--
[ signature omitted ]
