[PyQt] show dialog

[Phil]

Thank you for reading this.

I think my previous post went unanswered because it was too cluttered 
with unnecessary code, so I'll reduce it to the minimum.


I'm trying to have a dialog displayed from a menu item on the main window.

The dialog is defined as;

class SatelliteListDialog(QDialog, Ui_Dialog):

And this is the menu function within mainwindow;

def on_actionList_triggered(self):
self.dialog = SatelliteListDialog()
self.dialog.show()

This is the error message;

"global name 'SatelliteListDialog' is not defined"

I've played with this hours and not discovered the answer. By the way, 
I've imported the file where SatelliteListDialog is defined. There 
aren't error messages related to that but could there still be a problem 
with the import, a path perhaps?


--
Regards,
Phil
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] PyQt4 original example “dbus” bugged

[Tomas Neverdauskas]

Some say, it's possible: http://www.lothlorien.com/kf6gpe/?p=141


2013/4/3 Hans-Peter Jansen 

> On Mittwoch, 3. April 2013 18:17:46 Pietro Moras wrote:
> > Hi Andreas,   I've not
> > misunderstood, you have. In the sense that “\example\dbus” here
> > considered is an original example provided into the original PyQt4
> > package and, therefore, as such supposed to work as a model from
> > which to learn how to use it. If not working into the target platform
> > (probably there “forgotten” from other packages aimed at other
> > platforms) it means it is misleading.
>
> Feel free to port the dbus stuff to Windows, and you will quickly realize,
> why
> it was left out by the Qt developers in the first place...
>
> Since PyQt is multi platform by definition, all its examples should be
> provided everywhere.
>
> If you really like to contribute something easy, send over a patch for that
> example, that shows a QDialog noting "DBus is not supported on this
> platform"
> and exits, if importing QtDBus fails.
>
> Cheers,
> Pete
>
> ___
> PyQt mailing listPyQt@riverbankcomputing.com
> http://www.riverbankcomputing.com/mailman/listinfo/pyqt




-- 

T.N.
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] PyQt4 original example “dbus” bugged

[Hans-Peter Jansen]

On Mittwoch, 3. April 2013 18:17:46 Pietro Moras wrote:
> Hi Andreas,   I've not
> misunderstood, you have. In the sense that “\example\dbus” here
> considered is an original example provided into the original PyQt4
> package and, therefore, as such supposed to work as a model from
> which to learn how to use it. If not working into the target platform
> (probably there “forgotten” from other packages aimed at other
> platforms) it means it is misleading.

Feel free to port the dbus stuff to Windows, and you will quickly realize, why 
it was left out by the Qt developers in the first place...

Since PyQt is multi platform by definition, all its examples should be 
provided everywhere.

If you really like to contribute something easy, send over a patch for that 
example, that shows a QDialog noting "DBus is not supported on this platform" 
and exits, if importing QtDBus fails.

Cheers,
Pete

___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] PyQt4 original example “dbus” bugged

[Pietro Moras]

Hi Andreas,   I've not
misunderstood, you have. In the sense that “\example\dbus” here
considered is an original example provided into the original PyQt4
package and, therefore, as such supposed to work as a model from
which to learn how to use it. If not working into the target platform
(probably there “forgotten” from other packages aimed at other
platforms) it means it is misleading. 


Nothing serious, of
course (once you know it), therefore just a little perplexity.- P.M.
Date: Wed, 3 Apr 2013 17:16:08 +0200Subject: Re: [PyQt] PyQt4 original example 
“dbus” buggedFrom: ap...@gmx.deto: studio-pm@hotmail.comCC: 
pyqt@riverbankcomputing.comHi,On Wed, Apr 3, 2013 at 4:16 PM, Pietro Moras 
 wrote:



>  [QtDBus] it's
not supported on Windows.   Thank you Phil
for this info: bug “dissolved”.
Just a mild
perplexity, as the package:“PyQt-Py3.3-x86-gpl-4.9.6-1.exe
Windows 32 bit installer”I've downloaded from: 
http://www.riverbankcomputing.co.uk/software/pyqt/download
is precisely labeled
as a “Windows installer”.You misunderstand, PyQt is supported on Windows just 
fine, however the QtDBus module does not exist there because Qt does not 
provide it either on Windows (usually)Andreas   
   ___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] QGraphicsView very slow under Linux and Mac OS X

[Hans-Peter Jansen]

On Mittwoch, 3. April 2013 17:28:28 Clemens Brunner wrote:
> On 04/03/2013 04:23 PM, Hans-Peter Jansen wrote:
> > What you see is possibly related to the default Qt graphics engine:
> > 
> > when using:
> > QT_GRAPHICSSYSTEM=opengl python graphicsviewtest.py
> > 
> > the values are oscillating around 150 here. With "native" and "raster",
> > it's back to 25: openSUSE 12.2/x86_64, 2560x1600x32, nvidia proprietary
> > graphics,
> That's what I suspected initially. However, my graphics engine was set
> to native by default. I just tried all three engines:
> * native: around 100ms
> * raster: around 100ms
> * opengl: greater than 300ms
> 
> I tested it on Arch Linux x86_64, 1920x1080, python2 2.7.3-4, sip
> 4.14.5-1, qt4 4.8.4-16, python2-pyqt 4.10-1.

Which graphic driver do you use? (that doesn't tell us much, since the C++ 
version behave with the same driver, just for the record..)

> That's really weird... I will try to set up an openSUSE box in my
> VirtualBox to see if that works.

Might be worth to compare the C++ version (that you should publish here¹) 
and the Python versions with perf. Of course, they differ...

python versions, perf running for about 10 sec.

QT_GRAPHICSSYSTEM=raster perf record -f python graphicsviewtest.py 

 21,06%  python  libc-2.15.so [.] __memmove_ssse3_back
  3,34%  python  libc-2.15.so [.] __strcmp_sse42
  2,97%  python  libpython2.7.so.1.0  [.] PyEval_EvalFrameEx
  2,67%  python  libpython2.7.so.1.0  [.] lookdict_string
  2,65%  python  libQtGui.so.4.8.4[.] QWidget::qt_metacast(char const*)
  2,42%  python  libGL.so.304.64  [.] 0x000a01ed
  1,50%  python  libnvidia-tls.so.304.64  [.] 0x1c70
  1,27%  python  libpython2.7.so.1.0  [.] PyDict_GetItem
  1,12%  python  libpthread-2.15.so   [.] pthread_mutex_lock
  1,07%  python  sip.so   [.] parsePass1
  1,04%  python  libpthread-2.15.so   [.] __pthread_mutex_unlock_usercnt
  1,03%  python  libQtCore.so.4.8.4   [.] QObject::qt_metacast(char const*)
  1,00%  python  libpython2.7.so.1.0  [.] _init


QT_GRAPHICSSYSTEM=opengl perf record -f python graphicsviewtest.py

 10,12%  python  libpython2.7.so.1.0 [.] PyEval_EvalFrameEx
  4,94%  python  libpython2.7.so.1.0 [.] lookdict_string
  4,63%  python  libnvidia-glcore.so.304.64  [.] 0x013aed80
  3,53%  python  sip.so  [.] parsePass1
  3,26%  python  libpython2.7.so.1.0 [.] PyDict_GetItem
  2,68%  python  libpython2.7.so.1.0 [.] _PyType_Lookup
  1,91%  python  libm-2.15.so[.] __sin_sse2
  1,72%  python  libQtGui.so.4.8.4   [.] QBrush::~QBrush()
  1,69%  python  libQtOpenGL.so.4.8.4[.] 
QTriangulatingStroker::process(QVectorPath const&, QPen const&, QRectF
  1,51%  python  libpython2.7.so.1.0 [.] _init
  1,39%  python  libpython2.7.so.1.0 [.] binary_op1
  1,29%  python  libpython2.7.so.1.0 [.] 
_PyObject_GenericGetAttrWithDict
  1,27%  python  sip.so  [.] parsePass2
  1,21%  python  libGL.so.304.64 [.] 0x000a19c6
  1,16%  python  libQtOpenGL.so.4.8.4[.] 
QTriangulatingStroker::moveTo(double const*)
  1,15%  python  libpython2.7.so.1.0 [.] PyErr_Restore
  1,11%  python  libc-2.15.so[.] _int_free
  1,09%  python  libc-2.15.so[.] malloc
  1,08%  python  libQtGui.so.4.8.4   [.] QPainter::drawLines(QLine 
const*, int)
  1,00%  python  libQtOpenGL.so.4.8.4[.] 
QGL2PaintEngineExPrivate::updateMatrix()


The former looks nice, it's a great example, why PyQt rocks. The hottest
areas are there, where they should be: down under, moving bits. Great.

But the latter looks strange indeed. 

Phil, do you have any idea, why PyEval_EvalFrameEx is the top sucker in 
this scenario? This looks, like in opengl mode, it is evaluating some 
python expression in its hottest path (data type conversions or the like?). 
BTW: the opengl version crashes always on exit for me:

Program received signal SIGSEGV, Segmentation fault.
XQueryExtension (dpy=dpy@entry=0x0, name=name@entry=0x70a374b4 "GLX", 
major_opcode=major_opcode@entry=
0x7fffd104, first_event=first_event@entry=0x7fffd108, 
first_error=first_error@entry=0x7fffd10c)
at QuExt.c:57


#0  XQueryExtension (dpy=dpy@entry=0x0, name=name@entry=0x70a374b4 "GLX", 
major_opcode=major_opcode@entry=
0x7fffd104, first_event=first_event@entry=0x7fffd108, 
first_error=first_error@entry=0x7fffd10c)
at QuExt.c:57
rep = {type = 0 '\000', pad1 = 0 '\000', sequenceNumber = 0, length = 
0, present = 0 '\000', major_opcode = 
0 '\000', first_event = 0 '\000', first_error = 0 '\000', pad3 = 1, pad4 = 
0, pad5 = 0, pad6 = 4036989387, pad7 = 
32767}
req = 
#1  0x72813492 in XInitExtension (dpy=dpy@entry=0x0, 
name=name@entry=0x70a374b4 "GLX") at InitExt.c:47
codes = {

Re: [PyQt] QGraphicsView very slow under Linux and Mac OS X

[Vincent Vande Vyvre]

Le 03/04/13 17:28, Clemens Brunner a écrit :
> On 04/03/2013 04:23 PM, Hans-Peter Jansen wrote:
>
>> What you see is possibly related to the default Qt graphics engine:
>> when using:
>>
>> QT_GRAPHICSSYSTEM=opengl python graphicsviewtest.py
>>
>> the values are oscillating around 150 here. With "native" and
>> "raster", it's
>> back to 25: openSUSE 12.2/x86_64, 2560x1600x32, nvidia proprietary
>> graphics,
>
> That's what I suspected initially. However, my graphics engine was set
> to native by default. I just tried all three engines:
> * native: around 100ms
> * raster: around 100ms
> * opengl: greater than 300ms
>
> I tested it on Arch Linux x86_64, 1920x1080, python2 2.7.3-4, sip
> 4.14.5-1, qt4 4.8.4-16, python2-pyqt 4.10-1.
>
> That's really weird... I will try to set up an openSUSE box in my
> VirtualBox to see if that works.
>
> Clemens
> ___
> PyQt mailing listPyQt@riverbankcomputing.com
> http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>
Tested on Ubuntu, after removed the unusued import QtOpenGL.

-
On a 32 bytes machine screen 1600x900
Python 2.6.5  on a 32 bytes machine
Qt 4.6.2
PyQt 4.7.2
 27 23 26 24 25 25 25 25 25 25 25 25 25 25 25 25 27 23 25 25 25 25
25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 26 24 26 24 26 24 26 24 26
24 26 24 26 24 25 26 24 25 25 25 25
-
On a 64 bytes machine screen 1600x900
Python 2.7.3
Qt 4.8.1
PyQt 4.9.1

 25 25 25 25 25 25 25 25 25 25 25 25 25 25 26 24 25 25 25 25 25 25
25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25
25 25 25 25 25 25 25 25 25 25

Python 3.2.3
Qt 4.8.1
PyQt 4.9.1

 24 25 26 25 25 24 26 25 25 24 26 25 25 25 25 25 25 24 26 25 25 24
26 25 25 24 26 25 25 25 25 25 25 25 25 25 25 25 25 25


All three test in full screen of course.
-- 
Vincent V.V.
Oqapy  . Qarte
 . PaQager 
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] QGraphicsView very slow under Linux and Mac OS X

[Clemens Brunner]

On 04/03/2013 04:23 PM, Hans-Peter Jansen wrote:


What you see is possibly related to the default Qt graphics engine:
when using:

QT_GRAPHICSSYSTEM=opengl python graphicsviewtest.py

the values are oscillating around 150 here. With "native" and "raster", it's
back to 25: openSUSE 12.2/x86_64, 2560x1600x32, nvidia proprietary graphics,


That's what I suspected initially. However, my graphics engine was set 
to native by default. I just tried all three engines:

* native: around 100ms
* raster: around 100ms
* opengl: greater than 300ms

I tested it on Arch Linux x86_64, 1920x1080, python2 2.7.3-4, sip 
4.14.5-1, qt4 4.8.4-16, python2-pyqt 4.10-1.


That's really weird... I will try to set up an openSUSE box in my 
VirtualBox to see if that works.


Clemens
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] PyQt4 original example “dbus” bugged

[Andreas Pakulat]

Hi,


On Wed, Apr 3, 2013 at 4:16 PM, Pietro Moras  wrote:

> > [QtDBus] it's not supported on Windows.
>
>Thank you Phil for this info: bug “dissolved”.
>
> Just a mild perplexity, as the package:
>
> “PyQt-Py3.3-x86-gpl-4.9.6-1.exe Windows 32 bit installer”
>
> I've downloaded from:
> http://www.riverbankcomputing.co.uk/software/pyqt/download
>
> is precisely labeled as a “Windows installer”.
>
You misunderstand, PyQt is supported on Windows just fine, however the
QtDBus module does not exist there because Qt does not provide it either on
Windows (usually)

Andreas
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] QGraphicsView very slow under Linux and Mac OS X

[Andreas Pakulat]

Hi


On Wed, Apr 3, 2013 at 3:50 PM, Clemens Brunner
wrote:

> On 04/03/2013 03:24 PM, Andreas Pakulat wrote:
>
 That being said, here with Qt4.8 even a full-screen window will not
>> cause a significant slowdown, except during the resize phase.  Once the
>> resize is done the timer fires every 25 ms again. So I guess the
>> calculation inside the paint function simply take some time and once the
>> widget doesn't resize anymore the paint function is not called anymore.
>>
>
> OK, but (1) I was not referring to the resize phase, and (2) this only
> works well on Windows. On Mac OS X and Linux, the timer depends on the size
> of the window being updated -- for a full screen window, the timer fires
> every 100ms (not during the resize) because QGraphicsView cannot handle the
> computations within a time frame less than 100ms anymore.


As I said, with Qt4.8 I don't see this here on Linux at all, once the
window is at a certain size the timer fires every 25 ms again. This is on a
somewhat new system with Debians standard Qt/PyQt packages. So its not
necessarily a general problem with Linux/PyQt, but might be limited to the
systems you've used so far to reproduce this or a configuration thing etc.


>  If you need high precision timers then you'll need to write
>> platform-specific code. QTimer is not meant for that.
>>
>> Why this works better on Windows with Py(Qt/Side) can have many reasons,
>> the whole graphicsstack is different there, the QTimer might be
>> implemented differently there. Maybe windows delays the painting during
>> resize somewhat more so that there are less repaint-events given to Qt
>> or maybe the functions used in your paint() are more optimized on Windows.
>>
>
> Well, the fact that it does work equally well on all three platforms when
> I use Qt directly from a C++ program indicates that this is an issue with
> the Python wrapper


It could also be the fact that the various helpers inside your paint are
slower in Python on *nix for whatever reason. Did you try further
simplifying the paint function, for example simply painting 1 line across
the whole rect in multiple steps? Or try out a single step? That way you'd
be able to get rid of all the math which could affect the result too.


> , and not a different implementation within the Qt framework. Furthermore,
> since PyQt and PySide produce a Python wrapper that does work just like its
> C++ counterpart under Windows makes me think that it must be an
> implementation detail of PyQt/PySide that could probably be fixed.


I doubt there's much difference in the PyQt/PySide code between Windows and
*nix, after all the C API of CPython is the same on both platforms. One
difference though is the compiler being used for both - at least usually it
is a different one - and of course the platform itself. Does a fixed-length
sleep instead of the paint() function produce a different result on Linux?
Meaning, does it matter what exactly happens in paint or that its just not
a noop?

Andreas
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Qscintilla api location in PyQt4

[William Kyngesburye]

On Apr 3, 2013, at 4:24 AM, Phil Thompson wrote:

>> Again, at least for OS X, still a problem.  The "standard" binary Qt
>> install has no root, QTDIR is not defined as far as I can see, and parts
>> are scattered around the system.  "qmake -query QTDIR" returns
> **Unknown**.
>> In PyQt I get '/' for qt_dir in pyqtconfig.py.
> 
> You are still missing the point that QTDIR is just how configure.py refers
> to the Qt root directory in its help text (before it's able to report the
> actual value that will be used).
> 
>> As installed, frameworks are in /Library/Frameworks.  Plugins,
> development
>> apps, language files, ... are in /Developer/Applications/Qt.  Command
> line
>> tools are in /usr/bin.  dev libraries & headers (clucene & uitools) in
>> /usr/lib & /usr/include.  mkspecs are in /usr/local/Qt4.8.
> 
> That is that particular binary installer. A standard installation will put
> everything under a single directory. Creators of binary installers are free
> to put things anywhere they want. configure.py should have enough flags to
> allow the locations of the different components to be specified explicitly.
> 
Well, it IS the "official" binary distribution.  I haven't had the need to 
compile Qt from source on OS X, so I don't know if that's the way it normally 
compiles for OS X.

>> qmake -query QT_INSTALL_DATA
>> 
>> returns /usr/local/Qt4.8, same place as the mkspecs.
>> 
>> No real root other than the root of the HD, so QTDIR/qsci misses
>> /usr/local/Qt4.8/qsci completely.
> 
> I think using QT_INSTALL_DATA/qsci in the help message rather than
> QTDIR/qsci would avoid your confusion.
> 
If the Qt data dir is what it uses, then this will certainly help the average 
user.  I'm reading "QTDIR" as something specific when I see it, and something 
not the same as other software uses, so I didn't even think to try letting it 
do its thing which might have been correct.  


-
William Kyngesburye 
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole.  Now what does that 
remind me of?  Ah, yes - life."

- Marvin


___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] QGraphicsView very slow under Linux and Mac OS X

[Hans-Peter Jansen]

On Mittwoch, 3. April 2013 15:50:46 Clemens Brunner wrote:
> On 04/03/2013 03:24 PM, Andreas Pakulat wrote:
> > first of all, QTimer gives you no guarantee that it'll fire exactly
> > after the given amount of time. In particular not with such small
> > timeouts and when having non-trivial paint functions like yours. QTimer
> > is bound to the event loop, hence cannot fire if the loop is being
> > blocked by something. If you simplify the paint function the effect will
> > be much less dramatic.
> 
> Yes, I know that QTimer is not a high-precision timer. This is also not
> a problem in my example, since I can live with a bit of jitter.
> 
> > That being said, here with Qt4.8 even a full-screen window will not
> > cause a significant slowdown, except during the resize phase.  Once the
> > resize is done the timer fires every 25 ms again. So I guess the
> > calculation inside the paint function simply take some time and once the
> > widget doesn't resize anymore the paint function is not called anymore.
> 
> OK, but (1) I was not referring to the resize phase, and (2) this only
> works well on Windows. On Mac OS X and Linux, the timer depends on the
> size of the window being updated -- for a full screen window, the timer
> fires every 100ms (not during the resize) because QGraphicsView cannot
> handle the computations within a time frame less than 100ms anymore.
> 
> > If you need high precision timers then you'll need to write
> > platform-specific code. QTimer is not meant for that.
> > 
> > Why this works better on Windows with Py(Qt/Side) can have many reasons,
> > the whole graphicsstack is different there, the QTimer might be
> > implemented differently there. Maybe windows delays the painting during
> > resize somewhat more so that there are less repaint-events given to Qt
> > or maybe the functions used in your paint() are more optimized on Windows.
> 
> Well, the fact that it does work equally well on all three platforms
> when I use Qt directly from a C++ program indicates that this is an
> issue with the Python wrapper, and not a different implementation within
> the Qt framework. Furthermore, since PyQt and PySide produce a Python
> wrapper that does work just like its C++ counterpart under Windows makes
> me think that it must be an implementation detail of PyQt/PySide that
> could probably be fixed.

What you see is possibly related to the default Qt graphics engine:
when using: 

QT_GRAPHICSSYSTEM=opengl python graphicsviewtest.py

the values are oscillating around 150 here. With "native" and "raster", it's 
back to 25: openSUSE 12.2/x86_64, 2560x1600x32, nvidia proprietary graphics,

python: 2.7.3
sip: 4.14.5-snapshot-054f1676c300
qt4: 4.8.4
pyqt4: snapshot-4.10.1-3ade65901e3e

Cheers,
Pete
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Win 7, 64 bit, latest PyQt installer: importing QtGui fails

[Sibylle Koczian]

Am 02.04.2013 10:31, schrieb Phil Thompson:


As I have said, I (and presumably most other people) cannot reproduce the
problem. One possibility is a missing DLL - try installing a DLL dependency
checker to see if that identifies it.



Thank you, yes, it did. Installing the DirectX9 end user runtime helped. 
So this time it wasn't that ctypes bug.


Sibylle



___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] PyQt4 original example “dbus” bugged

[Pietro Moras]

>  [QtDBus] it's
not supported on Windows.   Thank you Phil
for this info: bug “dissolved”.

Just a mild
perplexity, as the package:“PyQt-Py3.3-x86-gpl-4.9.6-1.exe
Windows 32 bit installer”I've downloaded from: 
http://www.riverbankcomputing.co.uk/software/pyqt/download
is precisely labeled
as a “Windows installer”. - P.M.  ___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] QGraphicsView very slow under Linux and Mac OS X

[Clemens Brunner]

On 04/03/2013 03:24 PM, Andreas Pakulat wrote:


first of all, QTimer gives you no guarantee that it'll fire exactly
after the given amount of time. In particular not with such small
timeouts and when having non-trivial paint functions like yours. QTimer
is bound to the event loop, hence cannot fire if the loop is being
blocked by something. If you simplify the paint function the effect will
be much less dramatic.


Yes, I know that QTimer is not a high-precision timer. This is also not 
a problem in my example, since I can live with a bit of jitter.



That being said, here with Qt4.8 even a full-screen window will not
cause a significant slowdown, except during the resize phase.  Once the
resize is done the timer fires every 25 ms again. So I guess the
calculation inside the paint function simply take some time and once the
widget doesn't resize anymore the paint function is not called anymore.


OK, but (1) I was not referring to the resize phase, and (2) this only 
works well on Windows. On Mac OS X and Linux, the timer depends on the 
size of the window being updated -- for a full screen window, the timer 
fires every 100ms (not during the resize) because QGraphicsView cannot 
handle the computations within a time frame less than 100ms anymore.



If you need high precision timers then you'll need to write
platform-specific code. QTimer is not meant for that.

Why this works better on Windows with Py(Qt/Side) can have many reasons,
the whole graphicsstack is different there, the QTimer might be
implemented differently there. Maybe windows delays the painting during
resize somewhat more so that there are less repaint-events given to Qt
or maybe the functions used in your paint() are more optimized on Windows.


Well, the fact that it does work equally well on all three platforms 
when I use Qt directly from a C++ program indicates that this is an 
issue with the Python wrapper, and not a different implementation within 
the Qt framework. Furthermore, since PyQt and PySide produce a Python 
wrapper that does work just like its C++ counterpart under Windows makes 
me think that it must be an implementation detail of PyQt/PySide that 
could probably be fixed.


Clemens
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] QGraphicsView very slow under Linux and Mac OS X

[Andreas Pakulat]

Hi,

On Wed, Apr 3, 2013 at 2:15 PM, Clemens Brunner
wrote:

> Hi,
>
> I've also posted this question as a bug report at qt-project.org (
> https://bugreports.qt-project.org/browse/PYSIDE-151), but this is also a
> PyQt issue.
>
> QGraphicsView is apparently very slow under Linux and Mac OS X. I've
> attached an example program (runs with PySide or PyQt). The signals should
> be updated every 25ms; the actual timer intervals are displayed on the
> console. Now under Linux and Mac OS X, the graphics get slower with
> increasing window size. In full screen, the timer intervals are around
> 100ms instead of 25ms on my machines.
>
> This problem does not exist under Windows. Here, the intervals are not
> affected by window size, and the intervals stay at the given values.
> Interestingly, the program runs perfectly fast even in a Windows inside a
> VM.
>
> Furthermore, this problem is PySide (or PyQt) specific, because this
> behavior does not occur when I use Qt from C+. In C+, the program works as
> expected on all three platforms.
>

first of all, QTimer gives you no guarantee that it'll fire exactly after
the given amount of time. In particular not with such small timeouts and
when having non-trivial paint functions like yours. QTimer is bound to the
event loop, hence cannot fire if the loop is being blocked by something. If
you simplify the paint function the effect will be much less dramatic.

That being said, here with Qt4.8 even a full-screen window will not cause a
significant slowdown, except during the resize phase.  Once the resize is
done the timer fires every 25 ms again. So I guess the calculation inside
the paint function simply take some time and once the widget doesn't resize
anymore the paint function is not called anymore.

If you need high precision timers then you'll need to write
platform-specific code. QTimer is not meant for that.

Why this works better on Windows with Py(Qt/Side) can have many reasons,
the whole graphicsstack is different there, the QTimer might be implemented
differently there. Maybe windows delays the painting during resize somewhat
more so that there are less repaint-events given to Qt or maybe the
functions used in your paint() are more optimized on Windows.

Andreas
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

[PyQt] QGraphicsView very slow under Linux and Mac OS X

[Clemens Brunner]

Hi,

I've also posted this question as a bug report at qt-project.org 
(https://bugreports.qt-project.org/browse/PYSIDE-151), but this is also a PyQt 
issue.

QGraphicsView is apparently very slow under Linux and Mac OS X. I've attached 
an example program (runs with PySide or PyQt). The signals should be updated 
every 25ms; the actual timer intervals are displayed on the console. Now under 
Linux and Mac OS X, the graphics get slower with increasing window size. In 
full screen, the timer intervals are around 100ms instead of 25ms on my 
machines.

This problem does not exist under Windows. Here, the intervals are not affected 
by window size, and the intervals stay at the given values. Interestingly, the 
program runs perfectly fast even in a Windows inside a VM.

Furthermore, this problem is PySide (or PyQt) specific, because this behavior 
does not occur when I use Qt from C+. In C+, the program works as expected on 
all three platforms.

Thanks,
Clemens

import sys
from PyQt4 import QtGui, QtCore, QtOpenGL

import random
import math

class SignalItem(QtGui.QGraphicsItem):
def __init__(self, nr):
super(SignalItem, self).__init__()
self.setFlags(QtGui.QGraphicsItem.ItemUsesExtendedStyleOption)

self.nr = nr
self.fr = random.randint(3, 50)
self.bg = QtGui.QColor(random.randint(200,255),random.randint(200,255),random.randint(200,255))

def boundingRect(self):
return QtCore.QRectF(0, self.nr*50, 1, 50)

def paint(self, painter, option, widget):
painter.fillRect(option.exposedRect, self.bg)
self.prevY = math.sin((int(option.exposedRect.left()) - 1)/float(self.fr))*10 + 25 + self.nr*50
for x in range(int(option.exposedRect.left()), int(option.exposedRect.right())):
y = math.sin(x/float(self.fr))*10 + 25 + self.nr*50 
painter.drawLine(x-1, self.prevY, x, y)
self.prevY = y


class Dummy(QtCore.QObject):
def __init__(self):
super(Dummy, self).__init__()
self.scene = QtGui.QGraphicsScene()

for i in range(40):
item = SignalItem(i)
self.scene.addItem(item)

self.view = QtGui.QGraphicsView(self.scene)
self.view.show()

self.startTimer(25)
self.x = 0
self.lastTimerEvent = None

def timerEvent(self,event):
self.x += 1
self.view.horizontalScrollBar().setValue(self.x)
currentTime = QtCore.QTime.currentTime()
if self.lastTimerEvent:
print self.lastTimerEvent.msecsTo(currentTime)
self.lastTimerEvent = currentTime


if __name__ == '__main__':
app = QtGui.QApplication(sys.argv)
d = Dummy()
sys.exit(app.exec_())
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] PyQt4 original example “dbus” bugged

[Phil Thompson]

On Wed, 3 Apr 2013 08:44:30 +, Pietro Moras 
wrote:
> Any idea how to fix
> the PyQt4 Python ver. 3 original example “dbus\listanames.pyw”?

The .pyw extension suggests you are on Windows...

> Trying to use it I
> got an:  “ImportError cannot import name QtDBus”. Thanks.
>  - P.M.

...because it's not supported on Windows.

Phil
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Qscintilla api location in PyQt4

[Phil Thompson]

On Tue, 2 Apr 2013 19:45:21 -0500, William Kyngesburye
 wrote:
> On Apr 2, 2013, at 7:23 PM, Phil Thompson wrote:
> 
>> On Tue, 2 Apr 2013 19:04:38 -0500, William Kyngesburye
>>  wrote:
>>> On Apr 2, 2013, at 6:44 PM, Phil Thompson wrote:
>>> 
 On Tue, 2 Apr 2013 12:28:54 -0500, William Kyngesburye
  wrote:
> A bit of a discrepancy in API locations:
> 
> In the Qscintilla source, the default location to place the API
files
>> is
> QT_INSTALL_DATA/qsci, for both the Qscintilla library compilation
and
 the
> Qsci PyQt module compilation.
> 
> In the PyQt source, the default location for the API files is
>> QTDIR/qsci
> (that's what "configure.py --help" tells me).
> 
> On OS X, at least, QT_INSTALL_DATA is defined in qmake, QTDIR is not
 (and
> it's not something most OS X users will think to define in the
shell,
>> if
> they even know what the QTDIR should be because the OS X Qt
>> installation
 is
> weird), so PyQt API files could end up at the root /qsci, unless
it's
> configured with the -n flag to set the location.
> 
> If QTDIR is something like an install prefix, QTDIR/qsci is probably
>> not
> right on other systems with a defined QTDIR anyways.
 
 QTDIR is shorthand for the root of your Qt installation - it's not an
 environment variable.
 
 Suggestions welcome for a clearer way of expressing this.
 
>>> So, the problem still stands - QTDIR/qsci is not the proper default
>> place
>>> to put the Qsci API files - it doesn't agree with the default used in
>>> Qscintilla itself.
>> 
>> In a standard Qt installation these resolve to the same directory. The
>> different ways of referring to it reflect the different ways that the
>> scripts determine it.
>> 
> Again, at least for OS X, still a problem.  The "standard" binary Qt
> install has no root, QTDIR is not defined as far as I can see, and parts
> are scattered around the system.  "qmake -query QTDIR" returns
**Unknown**.
> In PyQt I get '/' for qt_dir in pyqtconfig.py.

You are still missing the point that QTDIR is just how configure.py refers
to the Qt root directory in its help text (before it's able to report the
actual value that will be used).
 
> As installed, frameworks are in /Library/Frameworks.  Plugins,
development
> apps, language files, ... are in /Developer/Applications/Qt.  Command
line
> tools are in /usr/bin.  dev libraries & headers (clucene & uitools) in
> /usr/lib & /usr/include.  mkspecs are in /usr/local/Qt4.8.

That is that particular binary installer. A standard installation will put
everything under a single directory. Creators of binary installers are free
to put things anywhere they want. configure.py should have enough flags to
allow the locations of the different components to be specified explicitly.

> qmake -query QT_INSTALL_DATA
> 
> returns /usr/local/Qt4.8, same place as the mkspecs.
> 
> No real root other than the root of the HD, so QTDIR/qsci misses
> /usr/local/Qt4.8/qsci completely.

I think using QT_INSTALL_DATA/qsci in the help message rather than
QTDIR/qsci would avoid your confusion.

Phil
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] QAxBase.dynamicCall - calling convention

[Frank Hempel]

Am 29.03.2013 19:12, schrieb Phil Thompson:
> 
> I need a short, complete script that demonstrates the problem.

it is attached to this mail (the threads opener mail has it inlined too).

Thanks for looking at it...

Regards, Frank

> 
> Phil
> 

import sys
from PyQt4 import QAxContainer
from PyQt4.QtCore import QVariant
from PyQt4.QtGui import QMainWindow, QApplication

class MainWindow(QMainWindow):
def __init__(self):
QMainWindow.__init__(self)
axc = QAxContainer.QAxWidget(self)
self.setCentralWidget(axc)
axc.setControl('{8856F961-340A-11D0-A96B-00C04FD705A2}')# Webbrowser

params = [QVariant(x) for x in ("www.google.com", 0, "", "", "")]

if 1:

# this works as "*params" is identical to "params[0], params[1], params[2], params[3], params[4]"

axc.dynamicCall("Navigate(QString, QVariant&, QVariant&, QVariant&, QVariant&)", *params)

else:

# this does not work; the browser control only shows the typical "site cannot be displayed" message

axc.dynamicCall("Navigate(QString, QVariant&, QVariant&, QVariant&, QVariant&)", params)

app = QApplication(sys.argv)

window = MainWindow()
window.show()

app.exec_()
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

[PyQt] PyQt4 original example “dbus” bugged

[Pietro Moras]

Any idea how to fix
the PyQt4 Python ver. 3 original example “dbus\listanames.pyw”?

Trying to use it I
got an:  “ImportError cannot import name QtDBus”. Thanks.
 - P.M.
  ___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt