Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Circular attempt for bindings #154

Open
dpizetta opened this issue May 21, 2018 · 11 comments
Open

Circular attempt for bindings #154

dpizetta opened this issue May 21, 2018 · 11 comments
Assignees
Milestone

Comments

@dpizetta
Copy link
Contributor

Hi, I'd like to implement a change for setup the binding in a circular form. Here is an example.

If the preference list is [pyqt5, pyside2, pyqt, pyside]:

  • choosing pyqt, if it is not found, it should try pyside, pyqt5, pyside2;
  • choosing pyside2, if it is not found, it should try pyqt, pyside2, pyqt5;

I think this would improve the auto setup and even the message that the "qtpy.PythonQtError: No Qt bindings could be found", because if you choose the last one, all the previous are not tested, so it is not "not found" actually.

Let me know what do you think about it, tks

@goanpeca
Copy link
Member

goanpeca commented May 21, 2018

@dpizetta it sounds like a good idea :-) @ccordoba12 ?

Just for context, is there any particular issues on your side that would directly benefit from this? Like an example of what was the problem?

@goanpeca
Copy link
Member

I would add that we need to add an else check so that if the last item in the list is not found, it should say something regarding that, instead of saying that it failed to use whatever binding check came last. Pyside at the moment, which is misleading

@ccordoba12
Copy link
Member

@dpizetta, I like it! But things should not be circular. Instead we should always prefer the bindings for the same Qt major version, then the other ones. And the PyQt bindings should be preferred over the PySide ones because they are more stable.

So, according to what you post above:

  • choosing pyside, if it is not found, it should try pyqt, pyqt5, pyside2;
  • choosing pyqt, if it is not found, it should try pyside, pyqt5, pyside2;
  • choosing pyside2, if it is not found, it should try pyqt5, pyqt, pyside

@dpizetta
Copy link
Contributor Author

Hi @goanpeca , @ccordoba12 thank you. I agree with your comments. Implementing this proposal also include the additional feature from @goanpeca. I'll post PR soon.

@goanpeca
Copy link
Member

Thanks @dpizetta :-) !

@goanpeca goanpeca added this to the v1.4.3 milestone May 21, 2018
@dpizetta
Copy link
Contributor Author

@goanpeca > Just for context, is there any particular issues on your side that would directly benefit from this? Like an example of what was the problem?
Sorry, I miss this question. The main problem is: if you choose the last one, i.e PySide, but it is not installed, it wouldn't try the other ones. So I think it should be nice to have this feature. In addition, I would like to add some functions that can be useful for other users, ex. get_available_api, that returns installed qt bindings..etc. I practically finished the code, but I would like to add more information about the changes to be well documented.

@ccordoba12
Copy link
Member

I think what he meant is that if all four bindings are tried and none is found, then qtpy should print a message saying precisely that.

If that happens right now, then we're printing a message about the lack of PySide (the last binding we look for its presence), which confuses users because they think they need to install PySide (to fulfill Spyder requirements, for example).

@ccordoba12 ccordoba12 modified the milestones: v1.4.3, v2.0 Jun 11, 2018
@dpizetta
Copy link
Contributor Author

Any date for this milestone?

@goanpeca
Copy link
Member

goanpeca commented May 5, 2019

@ccordoba12 do we have an estimated date, or is this the next major one?

@ccordoba12
Copy link
Member

As soon as someone reviews PR #156. @goanpeca, can you take care of that?

@goanpeca
Copy link
Member

goanpeca commented May 5, 2019

Sure will do :-)

@goanpeca goanpeca added the v2.0 label Feb 19, 2020
@goanpeca goanpeca removed this from the v2.0 milestone Feb 19, 2020
@ccordoba12 ccordoba12 added this to the v2.0.0 milestone Aug 10, 2021
@ccordoba12 ccordoba12 removed the v2.0 label Aug 10, 2021
@dalthviz dalthviz removed this from the v2.0.0 milestone Nov 11, 2021
@dalthviz dalthviz added this to the v2.2.0 milestone Apr 28, 2022
@dalthviz dalthviz modified the milestones: v2.2.0, v2.3.0 Jun 23, 2022
@dalthviz dalthviz modified the milestones: v2.3.0, v3.0.0 Sep 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants