[Interest] [PROGRESS] Long pause with 5.7

william.crocker at analog.com william.crocker at analog.com
Mon Nov 14 13:36:20 CET 2016


On 11/14/2016 06:23 AM, william.crocker at analog.com wrote:
> This sender failed our fraud detection checks and may not be who they appear to
> be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing
>
>>>
>>> But, if there *IS* something to do (sync), and I do not give it enough time,
>>> then the new bug will be that my app only restores window size and location
>>> SOMETIMES, because processEvents was not given enough time.
>>
>> You seem to be misunderstanding what the timeout is. It doesn't say
>> "this function call may take at most 5 seconds", it says "wait at most
>> 5 seconds". If there are events in the event loop the processEvents()
>> function call will dispatch them and return. If there aren't it will
>> wait for some, and if in 5 seconds no event comes it will return. So
>> if as you say you don't believe there is anything to do and there are
>> no events then the 5 seconds wait is to be expected. The time an event
>> is a bit late and it is not dispatched by the time you call that there
>> will be no wait.
>>
>
> The doc currently says...
>
>      "Processes pending events for the calling thread for maxtime milliseconds
>       or until there are no more events to process, whichever is shorter."
>
> The "or until there are no more events to process" part implies, to me, that
> it would return immediately if called with no events to process.
>
> Either way, it seems like the doc needs to be extended with a description
> of what happens if there are no pending events at the time of the call.
>
> I think what I really need here is somthing-I-can-do which will
> insure a round trip to the X windows server. That would in sure that
> both the client and server buffers have been flushed. Perhaps I should
> query the value of an X-Atom from the server and than call processEvents.
> Then, if there are OR WOULD BE any events generated from my calls to resize()
> and move(), they would be in the local event queue waiting to be processed.
> That would require that I bypass Qt and interact with X-Windows directly.
> That could have it's own issues.
>

... or perhaps these days with Qt5 all I need to do
     is call QGuiApplication::sync()

The doc says all the right things:

     This function will first empty Qt's events by calling 
QCoreApplication::processEvents(),
     then the platform plugin will sync up with the windowsystem, and finally 
Qt's events
     will be delived by another call to QCoreApplication::processEvents();

Bill



More information about the Interest mailing list