Re: Non-Modal Dialog

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 8 Oct 2019 06:13:09 +0200
Maurizio Berti <[email protected]> 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    [email protected]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt