-
Notifications
You must be signed in to change notification settings - Fork 5
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
PyQt4 still being used in some meqtrees scripts. #59
Comments
It's also getting pulled in by meqtree-pipeliner.py:
|
Hi as discussed with @Athanaseus we will try backport and ship PyQt4 for Ubuntu 20.04. I don't think we have the capacity on our side to rewrite the Meqtrees gui in Qt 5 with all the new form event handling system, since it is no longer actively used in our team - it is being replaced by Dask based commandline tools. I think we can try isolate it from the pipeliner. That should be do-able. Note there is another upstream issue in the new astropy which makes the pipeliner fail @bmerry. It only triggers under some special import conditions and I'm yet to isolate it. I think the kludge for now would be to downgrade Astropy to a version prior to the introduction of the bug. |
Actually, I've done much of the coding to make things work with PyQt5 (including modification of a lot of python scripts originally written by @o-smirnov but I'm not sure which version/branch of MeqTrees to check out to test if things are working. I was actually held up by some octopussy script which @Athanaseus was going to fix - has that been done? The pyqt4toqt5 (sic?) script that's available on the net will do most of the signal/event handling conversion for you - the only issue is what to to do if the signal is caught by a separate script which you are importing. |
I have decoupled some of the pyqt4 dependency in the scripts - if it is not installed the pipeliner will still run. This solves @bmerry's issue on ubuntu 20.04. @twillis449 if you can make a PR with your pyqt5 changes I can have a look and see how much there is left to do |
@bennahugo OK - will work on this. |
Still working on this but making progress. I'm starting to hate Qt and PyQt - why can't they provide interfaces for backward compatibility - I guess they want to create jobs for life - grrrr! And of course, these ancillary packages kittens and cattery, etc also need to be upgraded. grrrr +++ |
An example of inconsistencies in signals/slots in our code. We have pyqtSIGNAL, SIGNAL, pyqtsignal, and Signal at the moment being imported from various sources. I'm trying to straighten things out ... There are also a few scripts that are proving difficult to upgrade to PyQt5. And thank the good Lord for the existence of Stackoverflow and StackExchange websites :) |
Thanks a lot Tony. I think it is a massive undertaking. Sorry I can't help
with this for the moment, but feel free to assign me to review as you go
along.
There is also the issue of keeping the pipeliner working and detangled from
all the qt requirements...
…On Fri, Jan 29, 2021 at 7:38 PM Tony Willis ***@***.***> wrote:
An example of inconsistencies in signals/slots in our code. We have
pyqtSIGNAL, SIGNAL, pyqtsignal, and Signal at the moment being imported
from various sources. I'm trying to straighten things out ... There are
also a few scripts that are proving difficult to upgrade to PyQt5. And
thank the good Lord for the existence of Stackoverflow and StackExchange
websites :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#59 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4RE6WRXMFWW4FGLPAAYZ3S4LXCHANCNFSM4SMAPM3A>
.
--
--
Benjamin Hugo
PhD. student,
Centre for Radio Astronomy Techniques and Technologies
Department of Physics and Electronics
Rhodes University
Junior software developer
Radio Astronomy Research Group
South African Radio Astronomy Observatory
Black River Business Park
Observatory
Cape Town
|
Do note there is qwt5 bug that I have fixed on my repository of it. The
owner of the original project hasn't yet accepted my PR for it, but I know
it caused issues
for me when I did the porting to py3.
https://github.com/bennahugo/PythonQwt
Maybe he has since fixed it in another way. It is worth checking because I
hope the qwt5 project remains supported.
…On Fri, Jan 29, 2021 at 8:09 PM Benna Hugo ***@***.***> wrote:
Thanks a lot Tony. I think it is a massive undertaking. Sorry I can't help
with this for the moment, but feel free to assign me to review as you go
along.
There is also the issue of keeping the pipeliner working and detangled
from all the qt requirements...
On Fri, Jan 29, 2021 at 7:38 PM Tony Willis ***@***.***>
wrote:
> An example of inconsistencies in signals/slots in our code. We have
> pyqtSIGNAL, SIGNAL, pyqtsignal, and Signal at the moment being imported
> from various sources. I'm trying to straighten things out ... There are
> also a few scripts that are proving difficult to upgrade to PyQt5. And
> thank the good Lord for the existence of Stackoverflow and StackExchange
> websites :)
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#59 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AB4RE6WRXMFWW4FGLPAAYZ3S4LXCHANCNFSM4SMAPM3A>
> .
>
--
--
Benjamin Hugo
PhD. student,
Centre for Radio Astronomy Techniques and Technologies
Department of Physics and Electronics
Rhodes University
Junior software developer
Radio Astronomy Research Group
South African Radio Astronomy Observatory
Black River Business Park
Observatory
Cape Town
--
--
Benjamin Hugo
PhD. student,
Centre for Radio Astronomy Techniques and Technologies
Department of Physics and Electronics
Rhodes University
Junior software developer
Radio Astronomy Research Group
South African Radio Astronomy Observatory
Black River Business Park
Observatory
Cape Town
|
I found an annoyance in the latest PythonQwt (v0.8) - the owner added a test so that you cannot have X data of say type float32 and the y-data of type float64 and somewhere deep in my system (I can't figure out where) I can at some stage send in y-data of type float64 while the x data remains at type float 32. Anyway, since I have the actual code, I've just commented out that test. Unfortunately, the owner only seems to surface about once every three years to do bug fixes or changes. |
Yes I noticed that too - I hope this package doesn't disappear into the
vaults of abandonware. Ultimately we need a stable
pypi released package to actually build debian dependencies for MT and to
make sure we don't start clashing between packages.
If we need to start doing multiple custom versions of packages we land up
in CASA land - I'm still convinced if I put a bootloader into that
monolithic 800MB blob of custom stuff it will boot into an interferometric
data reduction operating system.
It seems to me Qt is very quickly losing a lot of support - probably
because things are moving to web based UIs everywhere in
favour of classical desktop application WYSIWYG guis. Even Microsoft's
Visual Studio is losing traction against
more lightweight applications like Visual Studio Code. Same for
Embarcadero's classic suite including Delphi where I
had my start back in the early 2000s.
Maybe @razman has some good insights into this. I have been monitoring
Tigger and there is a lot of good stuff going on there.
…On Fri, Jan 29, 2021 at 8:52 PM Tony Willis ***@***.***> wrote:
I found an annoyance in the latest PythonQwt (v0.8) - the owner added a
test so that you cannot have X data of say type float32 and the y-data of
type float64 and somewhere deep in my system (I can't figure out where) I
can at some stage send in y-data of type float64 while the x data remains
at type float 32. Anyway, since I have the actual code, I've just commented
out that test.
Unfortunately, the owner only seems to surface about once every three
years to do bug fixes or changes.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#59 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4RE6U4W2JM5ZOBOL4R3CTS4L7V3ANCNFSM4SMAPM3A>
.
--
--
Benjamin Hugo
PhD. student,
Centre for Radio Astronomy Techniques and Technologies
Department of Physics and Electronics
Rhodes University
Junior software developer
Radio Astronomy Research Group
South African Radio Astronomy Observatory
Black River Business Park
Observatory
Cape Town
|
I'm fed up with Qt because it started out as a nice system for developing GUI interfaces but has now become some sort of gigantic multi-tentacled octopus(sy). I tried to compute Qt5 a week or two ago and the compilation ate up some 45 Gb of disk space before it crashed as I had run out of disk space. :( Anyway @o-smirnov I'm now completely stumped as I get the error: This happens in PyApps/src/GUI/browser.py .... init for HierBrowserdef init(self,parent,name,name1='',udi_root=None,caption=None,prec=(None,'g'),maxwidth=None): The DataDraggableTreeWidget is defined in PyApps/src/GUI/widgets.py |
I had a similar issue when looking at PythonQwt amongst others for updating Tigger from PyQt4 to 5. I concluded that QWT is quite feature rich but was lacking a maintainer; like most of the other Py-based solutions. Once QWT had a new maintainer and seemed active once more, I found the Python wrapper (PyQt-Qwt) to be the most feature rich interface to provide a bridging solution that was most similar to the old Tigger version. Also, PyQt-Qwt’s inclusion in an LTS distro does provide some comfort.
I use a recommended alternative to the PyQt-Qwt/QWT mix in other code, namely PyQtGraph, which is pypi installable. However at the beginning of this journey, I was not sure if it would actually be a feasible replacement solution for Tigger; a paper-based study mixed with my previous experience of PyQtGraph, predicted that it is a possible alternative, but the cost of porting is not known as yet. Therefore and for the near future, I found the most reliable and effective bridging solution to be the PyQt-Qwt wrapper, for facilitating the upgrade from PyQt4 to 5.
In other code I don’t use PyQt directly either, instead I use PySide2 (the open source and official Python module), which seems pretty active; there are pros and cons to using PySide2. Qt for me is like C-based Java and I actually quite like it when hooked up to Python - it’s a powerful combination, despite the debugging difficulties. Qt does webassembly et al, but I don’t think it is the main focus of a C++ developer generally, and with things like KDE, Unity and a whole bunch of Linux desktop GUI’s made with Qt, I don’t think it will be going anywhere soon; I find it to be one of those cyclic computing trends.
Tigger is coming along with its porting, hit me up with any queries or questions and I’m happy to share the Tigger porting repo with Tony if it is useful?
Cheers,
Raz
… On 29 Jan 2021, at 19:19, Benjamin Hugo ***@***.***> wrote:
Yes I noticed that too - I hope this package doesn't disappear into the
vaults of abandonware. Ultimately we need a stable
pypi released package to actually build debian dependencies for MT and to
make sure we don't start clashing between packages.
If we need to start doing multiple custom versions of packages we land up
in CASA land - I'm still convinced if I put a bootloader into that
monolithic 800MB blob of custom stuff it will boot into an interferometric
data reduction operating system.
It seems to me Qt is very quickly losing a lot of support - probably
because things are moving to web based UIs everywhere in
favour of classical desktop application WYSIWYG guis. Even Microsoft's
Visual Studio is losing traction against
more lightweight applications like Visual Studio Code. Same for
Embarcadero's classic suite including Delphi where I
had my start back in the early 2000s.
Maybe @razman has some good insights into this. I have been monitoring
Tigger and there is a lot of good stuff going on there.
On Fri, Jan 29, 2021 at 8:52 PM Tony Willis ***@***.***>
wrote:
> I found an annoyance in the latest PythonQwt (v0.8) - the owner added a
> test so that you cannot have X data of say type float32 and the y-data of
> type float64 and somewhere deep in my system (I can't figure out where) I
> can at some stage send in y-data of type float64 while the x data remains
> at type float 32. Anyway, since I have the actual code, I've just commented
> out that test.
>
> Unfortunately, the owner only seems to surface about once every three
> years to do bug fixes or changes.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#59 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AB4RE6U4W2JM5ZOBOL4R3CTS4L7V3ANCNFSM4SMAPM3A>
> .
>
--
--
Benjamin Hugo
PhD. student,
Centre for Radio Astronomy Techniques and Technologies
Department of Physics and Electronics
Rhodes University
Junior software developer
Radio Astronomy Research Group
South African Radio Astronomy Observatory
Black River Business Park
Observatory
Cape Town
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
I completely agree and sympathise.
Compiling Qt is a bit of a monster, but apparently it’s ‘Cute’… try doing it on a Mac… enough said there I think. Thankfully, Gentoo takes the pain away for me. Although, I have a slight reverse on the situation of going from PyQt4 to 5, as I know PyQt 5 and feel like I’m kind of porting backwards, from the strange to the norm.
Hopefully, I am correct in thinking that the code below is now running PyQt5 instead of 4, as the error “AttributeError: 'QHeaderView' object has no attribute 'setResizeMode’” does lead me that way, setResizeMode was replaced with QHeaderView.setSectionResizeMode. Try something like:
self._tw.header().setSectionResizeMode(0, QHeaderView.ResizeToContents)
I hope that it is helpful to know that there is someone else that also feels these Qt pains you are facing, along with a lot of head banging may I add.
Cheers,
Raz
… On 29 Jan 2021, at 21:59, Tony Willis ***@***.***> wrote:
I'm fed up with Qt because it started out as a nice system for developing GUI interfaces but has now become some sort of gigantic multi-tentacled octopus(sy). I tried to compute Qt5 a week or two ago and the compilation ate up some 45 Gb of disk space before it crashed as I had run out of disk space. :(
Anyway @o-smirnov I'm now completely stumped as I get the error:
File "/usr/local/lib/python3.8/dist-packages/Timba/GUI/app_proxy_gui.py", line 158, in init
HierBrowser.init(self,self._vbox,name,udi_root=udi_root);
File "/usr/local/lib/python3.8/dist-packages/Timba/GUI/browsers.py", line 425, in init
self._tw.header().setResizeMode(0,QHeaderView.ResizeToContents);
AttributeError: 'QHeaderView' object has no attribute 'setResizeMode'
This happens in PyApps/src/GUI/browser.py ....
init for HierBrowser
def init(self,parent,name,name1='',udi_root=None,caption=None,prec=(None,'g'),maxwidth=None):
self._tw = DataDraggableTreeWidget(ClickableTreeWidget)(parent);
self._tw.setHeaderLabels([name1,'',name]);
self._tw.setRootIsDecorated(True);
self._tw.setSortingEnabled(False);
self._tw.header().setResizeMode(0,QHeaderView.ResizeToContents); # <------ note my line number will be from the PyQt4 version
self._tw.header().setResizeMode(1,QHeaderView.ResizeToContents);
self._tw.header().setResizeMode(2,QHeaderView.ResizeToContents);
self._tw.header().setStretchLastSection(False);
self._tw.header().setResizeMode(QHeaderView.ResizeToContents);
The DataDraggableTreeWidget is defined in PyApps/src/GUI/widgets.py
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Thanks a lot Raz. Do let me know when I should review your work. Tigger
still fills that gap between science publication quality figures (which can
really be made very well within the astropy / aplpy realm and quickly
blinking through a set of images on the same frame (which would be four or
5 individual steps in something like ds9, taking difference maps (which
would require actually entering ipython with only ds9 - no such capacity)
and doing fancy things like looking at the places in the uv plane RFI stems
from (which again would require entering ipython - hit ctrl-m and watch the
black magic of numexpr on something like
fft.ifftshift(fft.fft2(fft.fftshift(..)))). So this porting effort is much
appreciated.
Yes I also looked at https://github.com/GauiStori/PyQt-Qwt before I
embarked on my python3 porting adventures in 2019. At the time
I was very hesitant of it because there is no standardized compilation and
installation system here - it seems it is a make and sudo install
system(?) which always sets off all the alarm bells for me - I strongly
prefer pip wheel compliant packages for python requirements so it can be
installed off PyPI into a virtual environment with a single command for the
user. Perhaps this was a mistake on my part. If there is a maintained LTS
deb package for it then perhaps it is not as bad as it looks.
…On Sat, Jan 30, 2021 at 3:13 AM Raz ***@***.***> wrote:
I completely agree and sympathise.
Compiling Qt is a bit of a monster, but apparently it’s ‘Cute’… try doing
it on a Mac… enough said there I think. Thankfully, Gentoo takes the pain
away for me. Although, I have a slight reverse on the situation of going
from PyQt4 to 5, as I know PyQt 5 and feel like I’m kind of porting
backwards, from the strange to the norm.
Hopefully, I am correct in thinking that the code below is now running
PyQt5 instead of 4, as the error “AttributeError: 'QHeaderView' object has
no attribute 'setResizeMode’” does lead me that way, setResizeMode was
replaced with QHeaderView.setSectionResizeMode. Try something like:
self._tw.header().setSectionResizeMode(0, QHeaderView.ResizeToContents)
I hope that it is helpful to know that there is someone else that also
feels these Qt pains you are facing, along with a lot of head banging may I
add.
Cheers,
Raz
> On 29 Jan 2021, at 21:59, Tony Willis ***@***.***> wrote:
>
>
> I'm fed up with Qt because it started out as a nice system for
developing GUI interfaces but has now become some sort of gigantic
multi-tentacled octopus(sy). I tried to compute Qt5 a week or two ago and
the compilation ate up some 45 Gb of disk space before it crashed as I had
run out of disk space. :(
>
> Anyway @o-smirnov I'm now completely stumped as I get the error:
> File
"/usr/local/lib/python3.8/dist-packages/Timba/GUI/app_proxy_gui.py", line
158, in init
> HierBrowser.init(self,self._vbox,name,udi_root=udi_root);
> File "/usr/local/lib/python3.8/dist-packages/Timba/GUI/browsers.py",
line 425, in init
> self._tw.header().setResizeMode(0,QHeaderView.ResizeToContents);
> AttributeError: 'QHeaderView' object has no attribute 'setResizeMode'
>
> This happens in PyApps/src/GUI/browser.py ....
>
> init for HierBrowser
>
> def
init(self,parent,name,name1='',udi_root=None,caption=None,prec=(None,'g'),maxwidth=None):
> self._tw = DataDraggableTreeWidget(ClickableTreeWidget)(parent);
> self._tw.setHeaderLabels([name1,'',name]);
> self._tw.setRootIsDecorated(True);
> self._tw.setSortingEnabled(False);
> self._tw.header().setResizeMode(0,QHeaderView.ResizeToContents); #
<------ note my line number will be from the PyQt4 version
> self._tw.header().setResizeMode(1,QHeaderView.ResizeToContents);
> self._tw.header().setResizeMode(2,QHeaderView.ResizeToContents);
> self._tw.header().setStretchLastSection(False);
> self._tw.header().setResizeMode(QHeaderView.ResizeToContents);
>
> The DataDraggableTreeWidget is defined in PyApps/src/GUI/widgets.py
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or unsubscribe.
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#59 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4RE6R3G33IVMHWROKPWBTS4NMM7ANCNFSM4SMAPM3A>
.
--
--
Benjamin Hugo
PhD. student,
Centre for Radio Astronomy Techniques and Technologies
Department of Physics and Electronics
Rhodes University
Junior software developer
Radio Astronomy Research Group
South African Radio Astronomy Observatory
Black River Business Park
Observatory
Cape Town
|
Will do! At the moment I’m still watching your Tigger video to work our what’s not working properly - debugging via video, lol. Hopefully, I can make the fancy functionality a bit more slick and give it a fresh feel.
It is reassuring that there is a deb package for it, but I do find translating C++ docs into Python and debugging it quite a pain. I do quite like PyQtGraph (http://www.pyqtgraph.org) if it is suitable for Tigger, which will fulfil the pypi installation requirement, but I feel there will be some custom code needed to replicate some of the widgets provided by QWT.
:)
…Sent from my iPhone
On 30 Jan 2021, at 05:04, Benjamin Hugo ***@***.***> wrote:
Thanks a lot Raz. Do let me know when I should review your work. Tigger
still fills that gap between science publication quality figures (which can
really be made very well within the astropy / aplpy realm and quickly
blinking through a set of images on the same frame (which would be four or
5 individual steps in something like ds9, taking difference maps (which
would require actually entering ipython with only ds9 - no such capacity)
and doing fancy things like looking at the places in the uv plane RFI stems
from (which again would require entering ipython - hit ctrl-m and watch the
black magic of numexpr on something like
fft.ifftshift(fft.fft2(fft.fftshift(..)))). So this porting effort is much
appreciated.
Yes I also looked at https://github.com/GauiStori/PyQt-Qwt before I
embarked on my python3 porting adventures in 2019. At the time
I was very hesitant of it because there is no standardized compilation and
installation system here - it seems it is a make and sudo install
system(?) which always sets off all the alarm bells for me - I strongly
prefer pip wheel compliant packages for python requirements so it can be
installed off PyPI into a virtual environment with a single command for the
user. Perhaps this was a mistake on my part. If there is a maintained LTS
deb package for it then perhaps it is not as bad as it looks.
On Sat, Jan 30, 2021 at 3:13 AM Raz ***@***.***> wrote:
> I completely agree and sympathise.
>
> Compiling Qt is a bit of a monster, but apparently it’s ‘Cute’… try doing
> it on a Mac… enough said there I think. Thankfully, Gentoo takes the pain
> away for me. Although, I have a slight reverse on the situation of going
> from PyQt4 to 5, as I know PyQt 5 and feel like I’m kind of porting
> backwards, from the strange to the norm.
>
> Hopefully, I am correct in thinking that the code below is now running
> PyQt5 instead of 4, as the error “AttributeError: 'QHeaderView' object has
> no attribute 'setResizeMode’” does lead me that way, setResizeMode was
> replaced with QHeaderView.setSectionResizeMode. Try something like:
>
> self._tw.header().setSectionResizeMode(0, QHeaderView.ResizeToContents)
>
> I hope that it is helpful to know that there is someone else that also
> feels these Qt pains you are facing, along with a lot of head banging may I
> add.
>
> Cheers,
> Raz
>
>
> > On 29 Jan 2021, at 21:59, Tony Willis ***@***.***> wrote:
> >
> >
> > I'm fed up with Qt because it started out as a nice system for
> developing GUI interfaces but has now become some sort of gigantic
> multi-tentacled octopus(sy). I tried to compute Qt5 a week or two ago and
> the compilation ate up some 45 Gb of disk space before it crashed as I had
> run out of disk space. :(
> >
> > Anyway @o-smirnov I'm now completely stumped as I get the error:
> > File
> "/usr/local/lib/python3.8/dist-packages/Timba/GUI/app_proxy_gui.py", line
> 158, in init
> > HierBrowser.init(self,self._vbox,name,udi_root=udi_root);
> > File "/usr/local/lib/python3.8/dist-packages/Timba/GUI/browsers.py",
> line 425, in init
> > self._tw.header().setResizeMode(0,QHeaderView.ResizeToContents);
> > AttributeError: 'QHeaderView' object has no attribute 'setResizeMode'
> >
> > This happens in PyApps/src/GUI/browser.py ....
> >
> > init for HierBrowser
> >
> > def
> init(self,parent,name,name1='',udi_root=None,caption=None,prec=(None,'g'),maxwidth=None):
> > self._tw = DataDraggableTreeWidget(ClickableTreeWidget)(parent);
> > self._tw.setHeaderLabels([name1,'',name]);
> > self._tw.setRootIsDecorated(True);
> > self._tw.setSortingEnabled(False);
> > self._tw.header().setResizeMode(0,QHeaderView.ResizeToContents); #
> <------ note my line number will be from the PyQt4 version
> > self._tw.header().setResizeMode(1,QHeaderView.ResizeToContents);
> > self._tw.header().setResizeMode(2,QHeaderView.ResizeToContents);
> > self._tw.header().setStretchLastSection(False);
> > self._tw.header().setResizeMode(QHeaderView.ResizeToContents);
> >
> > The DataDraggableTreeWidget is defined in PyApps/src/GUI/widgets.py
> >
> > —
> > You are receiving this because you are subscribed to this thread.
> > Reply to this email directly, view it on GitHub, or unsubscribe.
> >
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#59 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AB4RE6R3G33IVMHWROKPWBTS4NMM7ANCNFSM4SMAPM3A>
> .
>
--
--
Benjamin Hugo
PhD. student,
Centre for Radio Astronomy Techniques and Technologies
Department of Physics and Electronics
Rhodes University
Junior software developer
Radio Astronomy Research Group
South African Radio Astronomy Observatory
Black River Business Park
Observatory
Cape Town
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Thanks for your various comments guys. some responses - both PyQt-qwt (author GauiStori) and python-qwt (author Raybaut) are available as packages on Ubuntu 2.04 LTS. Unfortunately, the python-qwt package is still at release 0.5.5 and doesn't seem to work properly (at least not for me) whereas the current github code does seem to work, so that's what I'm currently using. Also, interestingly the current version introduced me to the qtpy package. Qtpy is a wrapper which (at least in theory) allows your 'base' interface to Qt to be either PyQt or Pyside. so you import stuff as e.g. from qtpy.QtGui import QBrush, QPen, QColor, QImage, qRgba, QFont, QFontInfo and it 'should just work' to get the correct python package, either PyQt or Pyside. So I've been using these calls in all my updated code. As you correctly surmise @razman786 I'm porting from PyQt4 to PyQt5, and thanks for the suggested bug fix that you provided above. I will look at that. I actually ported all my visualization stuff in the timba PyApps/src/Plugins directory to PyQt5 and python-qwt last July and that's provided me with some foreknowledge of the headaches I would get. :) PyQtGraph is also available as a standard Ubuntu package. It claims to be very fast (which is something I could use if I want to plot data for 20000 SKA baselines) but that's something I'm leaving for another day. @razman786 if you do successfully port some code to pyqtgraph let me know :) |
Ah, QtPy, I tried this some time ago but it did not gel well when trying to freeze Python code into a standalone binary, so I just went with PySide2, and for sure, yes it should just work. Funny enough I have had times where having both PySide and PyQt installed at the same time caused strange errors.
Headaches indeed!
Will defo let you know if something arises from the PyQtGraph porting!
:)
… On 30 Jan 2021, at 22:55, Tony Willis ***@***.***> wrote:
Thanks for your various comments guys. some responses - both PyQt-qwt (author GauiStori) and python-qwt (author Raybaut) are available as packages on Ubuntu 2.04 LTS. Unfortunately, the python-qwt package is still at release 0.5.5 and doesn't seem to work properly (at least not for me) whereas the current github code does seem to work, so that's what I'm currently using. Also, interestingly the current version introduced me to the qtpy package. Qtpy is a wrapper which (at least in theory) allows your 'base' interface to Qt to be either PyQt or Pyside. so you import stuff as e.g.
from qtpy.QtGui import QBrush, QPen, QColor, QImage, qRgba, QFont, QFontInfo
from qtpy.QtCore import Qt, QSize, QObject, QTimer, QPoint, Signal
and it 'should just work' to get the correct python package, either PyQt or Pyside. So I've been using these calls in all my updated code.
As you correctly surmise @razman786 I'm porting from PyQt4 to PyQt5, and thanks for the suggested bug fix that you provided above. I will look at that. I actually ported all my visualization stuff in the timba PyApps/src/Plugins directory to PyQt5 and python-qwt last July and that's provided me with some foreknowledge of the headaches I would get. :)
PyQtGraph is also available as a standard Ubuntu package. It claims to be very fast (which is something I could use if I want to plot data for 20000 SKA baselines) but that's something I'm leaving for another day. @rasman786 if you do successfully port some code to pyqtgraph let me know :)
Cheers
Tony
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Some scripts, such as meqbrowser.py, are still using PyQy4 . At a minimum I suggest transiting to PyQt5, as python-land will be migrating to PyQt6 in the not-too-distant future. I'm suspicious that this use of PyQt4 may be causing some of the problems I've had getting a working MeqTrees system up and running recently.
The text was updated successfully, but these errors were encountered: