Various Issues with PyQt6

[RoadrunnerWMC]

I just built the latest snapshot to try the fix for StandardButtons. It
works, but only fixed some of my dialogs. I then realized that that's
because there's another enum with the same issue:
`QtWidgets.QDialog.DialogCode`. I temporarily replaced references to this
with integers just so I could test the rest of the app, and everything else
now seems fine. So I think this is the last PyQt6 bug affecting my app.

On Fri, Feb 26, 2021 at 2:59 PM RoadrunnerWMC <roadrunnerwmc at gmail.com>
wrote:

> Thanks for fixing the StandardButtons bug. I wasn't sure if the other two
> would be PyQt or Qt issues; I'll look into it at the Qt level, then.
>
> On Fri, Feb 26, 2021 at 10:10 AM Phil Thompson <
> phil at riverbankcomputing.com> wrote:
>
>> On 26/02/2021 04:13, RoadrunnerWMC wrote:
>> > Hi again Phil,
>> >
>> > I just installed PyQt 6.0.2. The problems from my previous email are
>> > fixed
>> > now (thanks!) and my application is able to launch. I am having a few
>> > new
>> > issues now, though.
>> >
>> > Here's the main one:
>> >
>> >     from PyQt6 import QtCore, QtGui, QtWidgets
>> >     app = QtWidgets.QApplication([])
>> >
>> >     mbox = QtWidgets.QMessageBox()
>> >     mbox.setStandardButtons(QtWidgets.QMessageBox.StandardButtons.Yes |
>> > QtWidgets.QMessageBox.StandardButtons.No)
>> >     ret = mbox.exec()
>> >
>> >     # The return value is an integer, but
>> > QtWidgets.QMessageBox.StandardButtons
>> >     # can't be converted or compared to integers.
>> >
>> >     # This prints False no matter which button you clicked:
>> >     print(ret == QtWidgets.QMessageBox.StandardButtons.Yes)
>> >
>> >     # TypeError: int() argument must be a string, a bytes-like object
>> > or a
>> > number, not 'StandardButtons'
>> >     int(QtWidgets.QMessageBox.StandardButtons.Yes)
>> >
>> >     # TypeError: unsupported operand type(s) for &: 'int' and
>> > 'StandardButtons'
>> >     print(ret & QtWidgets.QMessageBox.StandardButtons.Yes)
>> >
>> > As far as I can tell, there's no way to check the return value of
>> > `QtWidgets.QMessageBox.exec()` without hardcoding integer values
>> > (yuck).
>> > One way to fix it would be to change `.exec()`'s return type to
>> > `QtWidgets.QMessageBox.StandardButtons`, but since the integer values
>> > of
>> > the enum are officially publicly documented (
>> > https://doc.qt.io/qt-6/qmessagebox.html#StandardButton-enum), my guess
>> > is
>> > that adding support for int comparisons to the `StandardButtons` class
>> > would be a better solution. Or maybe there already is a way to do this
>> > comparison and I just don't see it?
>>
>> That will be fixed in the next snapshot.
>>
>> > A second issue:
>> >
>> >     from PyQt6 import QtCore, QtGui, QtWidgets
>> >     app = QtWidgets.QApplication([])
>> >     folder = QtWidgets.QFileDialog.getExistingDirectory(None, 'Select a
>> > folder')
>> >     print(folder)
>> >
>> > For whatever reason, this actually creates a *file*-selection dialog,
>> > which
>> > doesn't let me choose a folder. (Platform is KDE Neon (Ubuntu 20.04),
>> > if it
>> > helps.)
>>
>> I've only tested on macOS but that puts up the correct dialog so it is
>> unlikely to be a PyQt issue.
>>
>> > One more issue I found on 6.0.1 after my previous email -- though
>> > unfortunately without a way to trigger it consistently -- is that
>> > sometimes
>> > `QMainWindow.restoreState()` or `QMainWindow.restoreGeometry()` (not
>> > sure
>> > which) crashes if the pre-existing state (or geometry) was saved by
>> > PyQt5.
>> >
>> > The best workaround I can think of is to append the PyQt version name
>> > ("PyQt5"/"PyQt6") to the application name passed to the QSettings
>> > constructor, thus preventing PyQt6 from ever trying to read PyQt5's
>> > settings and vice versa. Luckily, my application has very few settings
>> > and
>> > I don't expect anyone to switch back and forth between PyQt versions,
>> > so
>> > this won't be a big problem. It's still not really ideal, though.
>> >
>> > Is this crash considered a bug? If not, is there a better way for me to
>> > handle this situation?
>>
>> Again I can't see how that is a PyQt issue rather than a Qt issue.
>>
>> Phil
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20210301/e2b9725e/attachment.htm>