search

pyapp-kit / superqt

Missing widgets and components for Qt-python
https://pyapp-kit.github.io/superqt/
BSD 3-Clause "New" or "Revised" License
207 stars 36 forks source link

Breaking Refactor: Make GenericSliders inherit `QWidget` rather than `QSlider` or `QAbstractSlider` #249

Open tlambert03 opened 5 months ago

tlambert03 commented 5 months ago

The original design of all the Range sliders here (which all subclass sliders._generic_slider._GenericSlider) was to make them behave as much like drop-in replacements for QSlider as possible. I wanted them all to pass isinstance(obj, QSlider) checks, and inasmuch as possible, inherit all of the behaviors of QSlider.

However, that has proven difficult to maintain, and the biggest issue relates to signals (particularly with PySide). In most of the slider variants the value() (and therefore valueChanged signal) is of a different type than the superclass. QDoubleSlider, of course, has a value() of type float, while QRangeSlider has a value type of tuple[int, ...].

We do some "unsavory" patching of the signal instances, on the object instances themselves, like here and here. And, for the most part it works, but requires very ugly hacks (https://github.com/pyapp-kit/superqt/pull/51). But really, it doesn't work well... and it's just a matter of time before it breaks again. I already get misc bus errors and segfaults during tests on pyside6 with the current strategy (thought pyqt6 is fine).

So, the two main options that I can see are:

  1. Don't try to inherit from QAbstractSlider, since it already has the signal names we want to use, and changing the value type of signals has proven to be a bad idea. A refactor like this would mean either using composition, or re-implementing basically all of the methods in the C implementation of QAbstractSlider to make these objects essentially duck-QSliders (many of those are reimplemented anyway as is). They would no longer pass isinstance(), but they would still be mostly drop-in replacements.
  2. Use new (different) names signals that change types. For example QDoubleSlider.valueChanged would be QDoubleSlider.floatValueChanged or something like that, rangeChanged would have to be floatRangeChanged... and QRangeSlider.valueChanged might be QRangeSlider.valuesChanged, etc... This breaks a lot of existing code, but might be cleaner to implement.

this doesn't have to happen soon, but it's a bit of a ticking time bomb. @Czaki and @jni, just a heads up if you have any opinions.

jni commented 5 months ago

I don't have a strong opinion, but generally favour more elegant implementations even if it breaks existing code. This is especially true while the number of users is (relatively) small. So that sounds like option 2 might be better. I'd be happy to simul-change things on the napari side when the time comes.

Czaki commented 5 months ago

Hm. I think that @jni underestimate how it could break napari. I prefer option one. In addition, superqt could export the own abstract type that could be used in isinstance calls.

tlambert03 commented 5 months ago

thanks both. yeah I started looking into it. Option number one is going to be a lot of work (basically a complete reimplementation of QSlider from scratch), but it's probably the only way to preserve the same signal names. this will likely go on the backburner, but it's good to have an open issue for it