[PyQt] Non-Modal Dialog

[Dennis Jensen]

I may be wrong but did you all miss the comment where I state you cannot 
use a QWidgets based object within anything but the Main Thread this 
includes almost all the Window like objects including QDialog -- PyQt 
comes right out and says this -- not that is not sub-Thread safe -- but 
that it is not even sub-Thread possible

On 10/8/2019 11:18 AM, Chuck Rhode wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 8 Oct 2019 06:13:09 +0200
> Maurizio Berti <maurizio.berti at gmail.com> wrote:
>
>> <snip> The issue with QPixmap.save() comes from the fact that, being
>> it's not thread safe, it would lock the main loop.  <snip> I think
>> that a good way to find out if it is is to check if the GUI actually
>> responds after the QThread.sleep. <snip> In my tests, using
>> QPixmap.save it didn't. <snip>
> The GUI doesn't respond in mine either, so I think we've established
> that I/O of the kind I've demonstrated WILL LOCK the GUI under the
> best of circumstances, and there isn't a good way to put a thread-safe
> wrapper around an unsafe task.  All the more reason to clue the user
> in as to the reason for the wait. ... so the $64 thousand question is,
> "Except for the clumsiness of the modal dialog box, might this
> thread-unsafe code not just as well be run directly from the GUI
> itself?"
>
> Thanks for sticking with me on this, BTW.
>
> I don't want to make too much of the QPixmap example.  There're
> general-case long-running tasks.  I don't feel I always have
> thread-safe alternatives for the things I want to fire off from a GUI
> environment.
>
> ... and this isn't for commercial consumption.  This is for my own
> fell purposes, so I just have to live with the consequences of a
> cobbled-up job.
>
> Getting the QMessageBox up and letting it settle before starting the
> long-running task is the hard part.  It's baffling that QMessageBox
> and its ancestors don't emit a "donePainting" signal.  It really does
> look as though you just have to wait "long enough."
>
>> When I'm asking out for help, I usually spend a *lot* of time making
>> my code as much as "standard" as possible: It's something that can
>> take a *long* time to be achieved. <snip> I've seen plenty of
>> "custom-styled-code" in both questions and answers that people would
>> just ignore because they were just too hard to read.  <snip>
> ... must ... control .. fIsT oF dEaTh!
>
> WRT excess *returns*, I should point out that *emacs* (Yes, I know
> other code editors do, too.) highlights them along with other
> syntactical sugar.  When you're dittoing code back and forth, it's
> easy to *cut* when you should *copy* and remove code that should be
> left in place.  Not seeing the highlighted *return* where you expect
> it to be, raises the notion that the function you're looking at may no
> longer be complete.  For the same reason, I like to see a shebang at
> the top and a #Fin comment at the bottom of every module because you
> never know when you or someone else will inadvertently shuffle a card
> deck.
>
> I spend a lot of time prettifying my code as though I might have to
> show it to someone someday, but really I'm doing it so I myself have a
> prayer of understanding it after putting it away for a year or two or
> ten.  Python's indentation discipline helps. ... and, yes, I've had
> cow-orkers obfuscate code (not Python) seemingly on purpose and then
> come to me for help debugging it.  That's were the fIsT oF dEaTh comes
> in.
>
> - -- 
> .. Be Seeing You,
> .. Chuck Rhode, Sheboygan, WI, USA
> .. Weather:  http://LacusVeris.com/WX
> .. 58° — Wind S 8 mph
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iEYEARECAAYFAl2ctu4ACgkQYNv8YqSjllLHgwCeMDUa1WzU3c/7hTVuEkWMJMVy
> GC4AnRm+HzG3SFAr3mjUJi5pkT3tQj00
> =FavB
> -----END PGP SIGNATURE-----
> _______________________________________________
> PyQt mailing list    PyQt at riverbankcomputing.com
> https://www.riverbankcomputing.com/mailman/listinfo/pyqt