Qt-interest Archive, February 2007
dynamic (re)allocation of QApplications
Message 1 in thread
Does Qt support the instantiation of more than one QApplication in a
process? I'm not concerned with whether you can allocate more than one
at a time, but rather I'm curious about whether I can safely construct
a QApplication, delete it after some use, and then construct another
one.
I've looked over the code for QApplication, and I don't see any reason
why this won't work (but, of course, it's complex enough that I may
well have missed something). Moreover, experiments indicate that I can
get away with recreating QApplications with no bad side-effects.
However, even if this kind of thing works now, I also want to know if
I can expect QApplication reconstruction to be supported in future
versions of Qt.
I'm interested in this functionality because it seems to be one way to
change the X11 display on which my GUI is displayed. That is,
QApplication seems to determine the active DISPLAY variable when it's
constructed. If I destroy the current QApplication, modify my DISPLAY
variable, and then create a new QApplication, I can effectively put my
GUI on a new system without necessarily destroying my underlying data.
Again, experiments seem to indicate that this works with recent
releases of Qt.
So, any thoughts or help on this would be great. Thanks.
Austin Bingham
--
[ signature omitted ]
Message 2 in thread
> Does Qt support the instantiation of more than one QApplication in a
> process?
Nope. Wouldn't make much sense either. QApplication contains the main
eventloop. A program with two main eventloops?
> I'm not concerned with whether you can allocate more than one
> at a time, but rather I'm curious about whether I can safely construct
> a QApplication, delete it after some use, and then construct another
> one.
Don't think this is impossible, though I don't see much use in it. In a
sense this would almost be equivalent with stopping an application an
restarting it.
Maybe you could do something like this:
int main(int argc, char *argv[]){
QApplication app1(argc, argv);
.......
app1.exec();
QApplication app2(argc, argv); <--- maybe parameters from results of
app1
.......
app2.exec();
}
Looks very _very_ strange.
Guido
--
[ signature omitted ]
Message 3 in thread
> > I'm not concerned with whether you can allocate more than one
> > at a time, but rather I'm curious about whether I can safely construct
> > a QApplication, delete it after some use, and then construct another
> > one.
>
> Don't think this is impossible, though I don't see much use in it. In a
> sense this would almost be equivalent with stopping an application an
> restarting it.
It's certainly not impossible, I'm just not sure if it has unexpected,
bad side-effects. The rationale for doing this was explained later in
my post. You're correct in one sense, which is that if your entire
application is based on Qt then the effect is to restart the
application. However, if your application also consists of non-Qt
things, then restarting the QApplication is really just restarting the
UI event loop.
> Maybe you could do something like this:
>
> int main(int argc, char *argv[]){
>
> QApplication app1(argc, argv);
>
>
> .......
> app1.exec();
>
> QApplication app2(argc, argv); <--- maybe parameters from results of
> app1
>
>
> .......
> app2.exec();
>
> }
>
> Looks very _very_ strange.
That's close to what I was describing, the difference being that I
want to actually destruct app1 before creating app2. I was imagining
the use of new/delete, but stack-based de/allocation would work, too.
It looks strange, I would imagine, because no one does it :)
Austin
--
[ signature omitted ]
Message 4 in thread
> I'm just not sure if it has unexpected, bad side-effects.
The worst side-effect for me would be that I'd have to take
care of all resources I use in app1, when I normally am a bit sloppy
with objects, which will only be deleted, when the program ends anyways.
Guido
--
[ signature omitted ]
Message 5 in thread
> The worst side-effect for me would be that I'd have to take
> care of all resources I use in app1, when I normally am a bit sloppy
> with objects, which will only be deleted, when the program ends anyways.
Well, let's take as a given that I can perform basic memory and
lifetime management. I'm concerned with, for instance, the possibility
of QApplication's use of static data that isn't accounted for across a
delete/construct cycle. Now, I see that the qapp pointer *does* seem
to be adjusted properly when the QApplication is deleted; this leads
me to think that reconstructing the QApplication is a possibility.
However, I'd like some assurance that, in fact, what I'm talking about
is supported behavior.
Austin
--
[ signature omitted ]
Message 6 in thread
On Wed, 14 Feb 2007 08:21:14 -0600
"Austin Bingham" <austin.bingham@xxxxxxxxx> wrote:
> I'm concerned with, for instance, the possibility
> of QApplication's use of static data that isn't accounted for across a
> delete/construct cycle.
Why not using a shared memory object and running the second application
in a new QProcess?
--
[ signature omitted ]
Message 7 in thread
Guido Seifert schrieb:
>> Does Qt support the instantiation of more than one QApplication in a
>> process?
>
> Nope. Wouldn't make much sense either. QApplication contains the main
> eventloop. A program with two main eventloops?
The latter is apparently intended to be possible if needed. See
QEventLoop...
However, Q[Core]Application is explicitely a singleton, so the answer is
still no. You can instantiate and delete it, but you can't instantiate
two or more independent objects in the same address space. But you may
prove me wrong...
Martin
--
[ signature omitted ]
Message 8 in thread
> The latter is apparently intended to be possible if needed. See
> QEventLoop...
I suppose this is for threads, which in Qt 4 can have their own
eventloop.
Guido
--
[ signature omitted ]
Message 9 in thread
"Austin Bingham" <austin.bingham@xxxxxxxxx> wrote in message
news:bf1abd10702140525y17065963qe386f11de6271ee3@xxxxxxxxxxxxxxxxx
> Does Qt support the instantiation of more than one QApplication in a
> process? I'm not concerned with whether you can allocate more than one
> at a time, but rather I'm curious about whether I can safely construct
> a QApplication, delete it after some use, and then construct another
> one.
>
> I've looked over the code for QApplication, and I don't see any reason
> why this won't work (but, of course, it's complex enough that I may
> well have missed something). Moreover, experiments indicate that I can
> get away with recreating QApplications with no bad side-effects.
> However, even if this kind of thing works now, I also want to know if
> I can expect QApplication reconstruction to be supported in future
> versions of Qt.
>
> I'm interested in this functionality because it seems to be one way to
> change the X11 display on which my GUI is displayed. That is,
> QApplication seems to determine the active DISPLAY variable when it's
> constructed. If I destroy the current QApplication, modify my DISPLAY
> variable, and then create a new QApplication, I can effectively put my
> GUI on a new system without necessarily destroying my underlying data.
> Again, experiments seem to indicate that this works with recent
> releases of Qt.
>
> So, any thoughts or help on this would be great. Thanks.
It should work, even though it is not necessarily covered with tests to
the fullest extent. You of course have to destroy your UI and recreate it
(and that includes i.e. QPixmap instances etc) - persisting this to a file
and restarting the second process before existing from the first one might
be an alternative that is easier to maintain.
There might be instances where static data is not correctly reset by the
Q(Core)Application d'tor, in which case we would like to know about it via
email to qt-bugs :)
Volker
--
[ signature omitted ]
Message 10 in thread
> It should work, even though it is not necessarily covered with tests to
> the fullest extent. You of course have to destroy your UI and recreate it
> (and that includes i.e. QPixmap instances etc) - persisting this to a file
> and restarting the second process before existing from the first one might
> be an alternative that is easier to maintain.
>
>
> There might be instances where static data is not correctly reset by the
> Q(Core)Application d'tor, in which case we would like to know about it via
> email to qt-bugs :)
Thanks for the info!
Are you saying that Qt intends to support this feature, though it may
have latent bugs? I'll be happy to help track down any bugs that
occur. What I want to avoid is investing time and effort in
implementing this approach only to find that it stops working in
future versions of Qt as it's a not-really-supported feature. Thanks
again.
Austin
--
[ signature omitted ]
