Skip to content

change the libOrder to favor Qt6#2157

Merged
j9ac9k merged 16 commits intopyqtgraph:masterfrom
Wubbzi:binding_load_order
Sep 27, 2022
Merged

change the libOrder to favor Qt6#2157
j9ac9k merged 16 commits intopyqtgraph:masterfrom
Wubbzi:binding_load_order

Conversation

@Wubbzi
Copy link
Copy Markdown
Contributor

@Wubbzi Wubbzi commented Dec 16, 2021

I'd like to propose changing the order in which Qt bindings are selected when one is not specified by the user.

Changing the libOrder to favor the newer Qt6 bindings is inevitable and I think now is as good of a time as any to do it.

Pros

  • Since last month, when I took an interest in pg, there have been a couple of issues that were caused by the PySide2 bindings, maybe more to come. While the issues will still probably need to be addressed, the number of users who see run into the issue will be less.
  • The vast majority of users will never see updates or bug fixes for these releases.
  • Qt 6.2 is an LTS build.
  • Some people have more than one binding installed and It's probably confusing to them why the newer binding they've installed isn't being used. I don't think everyone who uses the library is a programmer or has the time to dig into the code to figure it out why this is happening.

Cons

  • New versions could cause bigger issues than older versions(there is always the option of settingPYQTGRAPH_QT_LIB if this does happen to users with multiple versions of bindings)

Does anyone have a preference on the order of the v6 bindings? Right now, both versions have about the same number of users going based on the downloads.
https://pypistats.org/packages/pyside6
https://pypistats.org/packages/pyqt6

@pijyoi
Copy link
Copy Markdown
Contributor

pijyoi commented Dec 17, 2021

If you make this change, you may also want to modify the drop-down list in exampleLoaderTemplate.ui to match the order (for cosmetic reasons).

@Wubbzi
Copy link
Copy Markdown
Contributor Author

Wubbzi commented Dec 17, 2021

@pijyoi I could do that.

Could we get rid of 'default' too? The UX could be better if we set the index to the correct version in ExampleApp before the launch.

@pijyoi
Copy link
Copy Markdown
Contributor

pijyoi commented Dec 17, 2021

Sure. But correct version means matching it against PYQTGRAPH_QT_LIB and also the bindings that are found to be installed.

from collections import OrderedDict
from functools import lru_cache

import pkg_resources
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can it be assumed that this is available for use?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not as sure as I am about pkgutil so we can use that with minimal changes instead of pkg_resources.


def showEvent(self, event) -> None:
super(ExampleLoader, self).showEvent(event)
disabledColor = pg.mkColor(QtCore.Qt.GlobalColor.red)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may I suggest that this PR not change the public API at the same time?
QtGui.QColor(QtCore.Qt.GlobalColor.red) would seem to suffice.

@pijyoi
Copy link
Copy Markdown
Contributor

pijyoi commented Dec 21, 2021

So the original code populates the combo box through the.ui file. I was thinking, if we are going to take the trouble to programmatically mark out bindings that aren't available, would it make more sense to programmatically populate the combo box from the start?

And going even further, why not just populate the combo box only with the bindings that are available? Of course, showing the not available bindings does give an indication to the user that pyqtgraph works with multiple bindings.

@Wubbzi
Copy link
Copy Markdown
Contributor Author

Wubbzi commented Dec 22, 2021

if we are going to take the trouble to programmatically mark out bindings that aren't available, would it make more sense to programmatically populate the combo box from the start?

There isn't a good reason that I can think of for us not to do it this way. I'm pretty sure it would only be 1 line.

edit: I went ahead and did this, if for no other reason than it will be easier to change/update in the future.

And going even further, why not just populate the combo box only with the bindings that are available? Of course, showing the not available bindings does give an indication to the user that pyqtgraph works with multiple bindings.

Before marking the missing bindings in red, I was removing them, but like you said, a user might not know they have the option of using other bindings.

I think this is the better option. The one thing I'm not sure about is disabling the binding in addition to coloring it red. I think most people will understand it means the binding isn't installed, but maybe it would be better to mark the binding in red and not disable it, so they can see the traceback when an example is run.

Copy link
Copy Markdown
Contributor Author

@Wubbzi Wubbzi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When uninstalling PyQt5/6 with pip, there are other installed dependencies left behind, which means you will be able to import PyQt5 but QtCore/QtWidgets, etc will be missing and cause the library to fail to load.
Screen Shot 83

@j9ac9k
Copy link
Copy Markdown
Member

j9ac9k commented Sep 27, 2022

Hi @Wubbzi, hope you don't mind that I took over this PR, I really wanted this diff in 0.13.0 release; but there were a number of merge conflicts.

Thanks for the PR!

@j9ac9k j9ac9k merged commit c9c89db into pyqtgraph:master Sep 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants