[PyQt] QApplication was not created in the main()

[Alan Ezust]

I am not sure, I haven't tried what you are trying to do.

Perhaps if you are consistent about creating all QWidgets in the same
thread as your QApplication, and the one and only QApplication is created
as a stack variable in a function before any of the QWidgets are created,
and you have proper parent-child relationships between QObjects that never
cross thread boundaries, your program might work in another thread...

To better understand the topic, you should read
http://qt-project.org/doc/qt-5/thread-basics.html

GUI Thread and Worker Thread

As mentioned, each program has one thread when it is started. This thread
is called the "main thread" (also known as the "GUI thread" in Qt
applications). The Qt GUI must run in this thread. All widgets and several
related classes, for example QPixmap
<http://qt-project.org/doc/qt-5/qpixmap.html>, don't work in secondary
threads. A secondary thread is commonly referred to as a "worker thread"
because it is used to offload processing work from the main thread."






On Mon, Jul 28, 2014 at 9:41 AM, Gelonida N <gelonida at gmail.com> wrote:

> On 7/28/2014 6:18 PM, Alan Ezust wrote:
>
>>
>>
>>
>> On Mon, Jul 28, 2014 at 7:14 AM, Gelonida N <gelonida at gmail.com
>> <mailto:gelonida at gmail.com>> wrote:
>>
>>     Hi Alan,
>>
>>     On 7/26/2014 7:35 PM, Alan Ezust wrote:
>>
>>         You are only supposed to create one QApplication, and that should
>> be
>>         main. Why do you want to create a second one somewhere else? That
>> is
>>         probably a mistake.
>>
>>
>>     I think I did not express myself very well.
>>
>>     I do not want to create a second instance of a QApplication.
>>     I just want to know whether I can create an application from a
>>     thread which is NOT the main thread.
>>
>>
>> Why would you want to? What problem does it solve?
>>
>
> Main reason is because I want :-P to have my liberties and I want to
> understand where limitations come from.
>
> Another reason is, that I have some existing code, which does already
> something in the main thread and which has a  threading server, which shall
> create and start a QApplication under certain situations. Restructuring the
> code such, that the QApplication would start in the mean thread would be a
> little annoying and cost me some refactoring.
>
> On the other side I want to understand what a certain warning means, why
> it is where and which impact it might have.
>
>
> Another reason is, that I am doing some experiments with Ipython, Ipython
> kernels, applications being able to run headless or with GUI with a debug
> console or without and that at the moment IPython and QApplication want to
> execute in the main thread.
> There seems to be a mode, where both can share the same thread but so far
> I didn't find example code being able to do so. So the quickest solution
> would be to move the QApplication away from the main thread.
>
> By the way I will probably post a similiar question to the IPython mailing
> list in order to understand, why IPython insists on being run in the main
> thread.
>
>
>      I do not intend to create multiple QApplications, but wanted to
>>     know, what is so special about the main thread and why PyQt tells
>>     me, that I should create my GUI in the main thread.
>>
>>
>> That is a Qt limitation, not just a PyQt limitation. Because the GUI
>> classes are not thread-safe.
>> Other languages/frameworks have similar restrictions.
>>
>
> I don't agree. If code is not thread safe you're not allowed to call code
> from multiple threads without precautions and further knowledge.
>
> However whether you start non thread safe code in thread A or in thread B
> should not matter.
>
> So I expect there's another reason for the warning,, which I'd like to
> learn.
>
> I'd like to understand it and if there's no blocking point to learn how I
> can get rid of this warning.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20140728/a567ee49/attachment.html>