[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dcoppython vs. python-pyqt



On Fri, Jul 13, 2001 at 02:59:40AM -0600, Bruce Sass wrote:
> Hi,
> 
> Who gets this bug...
> 
> $ dpkg -S /usr/lib/python1.5/qt.py
> dcoppython: /usr/lib/python1.5/qt.py
> $ dpkg -S /usr/lib/python1.5/site-packages/qt.py
> python-pyqt: /usr/lib/python1.5/site-packages/qt.py
> 
> ...which results in...
> 
> /usr/share/doc/python-pyqt/examples$ ./tut1.py
> Traceback (innermost last):
>   File "./tut1.py", line 9, in ?
>     a = QApplication(sys.argv)
> NameError: QApplication

I seems that dcoppython's Qt binding, which have it's interface module
at '/usr/lib/python1.5/qt.py' is fooling PyQt-based scripts, which need
instead to load '/usr/lib/python1.5/site-packages/qt.py'

I've been looking at the code of "pcop.so", which is the only needing
Qt bindings (pcop is imported by dcop), but it relies on "pyqt.so".
I moved dcoppython's "qt.py" out of the python1.5 lib directory, and
dcoppython tests seemed to work fine (well... they really doesn't work
fine any way, because '/usr/lib/python1.5/site-packages/pyqt.so' doesn't
load when imported by pcop).

Is really /usr/lib/python1.5/qt.py a need? If it got removed from
dcoppython package, probably no one would miss it :-), and maybe
python-pyqt, more complete qt.py, works for everyone (I need some
working python script that uses DCOP and Qt to prove it :-?)

I'll try to work in a solution :-/



Reply to: