[Interest] QPrintPreviewWidget

[Dan Allen]

Thanks for your help Bill.


On 04/04/17 17:56, william.crocker at analog.com wrote:
> On 04/04/2017 11:52 AM, Dan Allen wrote:
>> Hi Bill,
>>
>> What you've listed below is pretty much how my printing mechanism 
>> works.  This
>> works perfectly and I'm happy with it.
>>
>> I'm still a little confused as to why the preview can't operate in 
>> the same
>> way.  If another thread paints into a QImage and then informs the 
>> dialog using a
>> signal such that the GUI thread can then display it on the screen, 
>> why is this
>> an issue?
>
> I do not think that is an issue.
> I think you can paint to a QImage in a non-GUI thread, because
> a QIMage is a non-GUI object, unlike a QPixmap which is (or at least
> was historically) a "GUI" object.
>
> The term GUI (in this conversation and in my understanding)
> is generally when you interact with the underlying window system to
> create and use Windows which appear on the screen.
>
> Yes, the QPainter class lives in the QtGUI module, but I do not
> believe it's use is restricted to the main thread. On Linux and
> in the past, interaction with the X11 server was limited to the main
> thread. That is why use of QPixmap was limited to the main thread.
> That is why use of on screen Windows was limited to the main thread.
>
> From the QPixmap doc:
>
>     "...pixel data in a pixmap is internal and is managed
>      by the underlying window system."
>
> So (at least in the past) when you draw on a QPixmap, instructions
> are being sent to the "underlying window system" and (in the past)
> that was across a network connection to the X11 server.
>
> How any of this has changed with the introduction
> of QPA (Qt Platform Abstraction) I do not know.
>
> Bill
>
>> Why does the GUI thread have to do the time consuming task?  The Qt
>> documentation for QImage states "When using QPainter on a QImage, the 
>> painting
>> can be performed in another thread than the current GUI thread."
>
> Yes. That is my understanding too, as stated above.
>
>>
>> Thanks,
>>
>> Dan Allen.
>>
>>
>> On 03/04/17 14:49, william.crocker at analog.com wrote:
>>> On 04/01/2017 09:48 AM, Dan Allen wrote:
>>>> Hi Bill,
>>>>
>>>> I agree, however when the print is quite complex it makes the GUI very
>>>> unresponsive.
>>>>
>>>> Painting into an off screen image is not GUI related. The print 
>>>> preview could
>>>> show something like "Generating Preview" while a background thread 
>>>> generates it
>>>> and then show it when it's ready for example. This would prevent 
>>>> the GUI from
>>>> seeming unresponsive to the user. I wasn't sure if there was a 
>>>> current method to
>>>> do something like this.
>>>>
>>>
>>> Yes. We agree that the actual printing is non GUI, but if you want
>>> to show a print preview or progress meter, that is GUI and needs
>>> to stay in the main thread.
>>>
>>> So, something like:
>>> - Create a progress meter dialog.
>>> - Start your printing in a sub thread.
>>> - The main thread waits, perhaps in a sub-QEventLoop, servicing events.
>>> - After a few seconds, if printing has not completed, show the dialog.
>>> - The sub-event loop monitors the printing process with a thread safe
>>>   communication mechanism, like signals and slots.
>>> - When the printing completes, close the dialog.
>>> - Exit your sub-event loop.
>>>
>>>> Thanks,
>>>>
>>>> Dan Allen.
>>>>
>>>>
>>>> On 01/04/17 13:43, william.crocker at analog.com wrote:
>>>>> On 04/01/2017 03:41 AM, Dan Allen wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Could anyone tell me if it's possible to paint into a 
>>>>>> QPrintPreviewWidget in
>>>>>> another thread, and if so, how?
>>>>>>
>>>>>> I have created a class to perform printing and this runs in 
>>>>>> another thread.
>>>>>> When used for printing it works fine.  However when used for the 
>>>>>> print
>>>>>> preview,
>>>>>> nothing is shown unless I force the signal to either 
>>>>>> Qt::DirectConnection
>>>>>> (i.e.
>>>>>> use the GUI thread) or Qt ::BlockingQueuedConnection (i.e. block 
>>>>>> the GUI
>>>>>> thread).
>>>>>>
>>>>> Dan:
>>>>>
>>>>> Conventional wisdom, if not the rule of law, states that all GUI 
>>>>> activity
>>>>> should be done from the main thread. You may just be experiencing
>>>>> the Qt library enforcing this rule.
>>>>>
>>>>> Bill
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Dan Allen.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Interest mailing list
>>>>>> Interest at qt-project.org
>>>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Interest mailing list
>>>>> Interest at qt-project.org
>>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>>
>>>>
>>>> _______________________________________________
>>>> Interest mailing list
>>>> Interest at qt-project.org
>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Interest mailing list
>>> Interest at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest