[PyQt] licensing

[KONTRA, Gergely]

Hi all!

Maybe a bit offtopic and theoretical question:

Suppose I'd like to write an app in python and Qt. I evaluate the
possibilities, and see, that pyqt is more stable now, so I decide to
begin coding with it (with the free version). When I make this
decision, I already think to wait for a more complete/stable PySide
binding and distribute my code which uses PySide (with a less
restrictive license). Or I first release it with PyQt, but later on I
find PySide, which has a less restrictive license.
Is any of the above cases the violation of the License Terms? So is it
legal? Is it fair?

And consider another case: I begin to write my app with Pyside, and
later release a version with pyqt at some point. Can I later release a
newer PySide based version with license compatible with PySide (which
is not compatible with pyqt's license)?

Yet another case: I do a prototype with PyQt, and than hand-convert it
to Qt/C++.

Thanks
Gergo



+-[ Gergely Kontra pihent...@gmail.com ]--+
|   |
| Mobile:(+36 20)356 9656   |
|   |
+- Olyan lángész vagyok, hogy poroltóval kellene járnom! -+
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Passing image using SIP

[Jarosław Białas]

On 21.06.2011 20:02, David Boddie wrote:

On Mon Jun 20 23:46:27 BST 2011, Jarosław Białas wrote:


I wanted to create code fragment that will pass an object containg image
or pointer to this object from Python to C++ function.
I tried to create function:
void loadImage(QImage* image);
Then I created sip file, and after compiling and linking everything
looks fine until I tried to import shared library in python:
ImportError: ./test.so: undefined symbol: _ZTI6QImage


It looks like QtGui wasn't linked in when your shared library was created.
How was the linker run? What command line options and arguments were passed
to it?

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


You were absolutely right. QtGui wasn't linked. But SIP still throw an 
error - sip: Q_PID is undefined. So i add SIP platform tag -t WS_X11.
It wasn't working too - sip: QFileIconProvider is undefined, but after 
extra modification:


$ /usr/bin/sip -c . -I/usr/share/sip -t WS_X11 -t Qt_4_7_2  -b hello.sbf 
hello.sip
$ g++ -c -pipe -fPIC -O2 -Wall -W -DNDEBUG -I. -I/usr/include/python2.7 
-I/usr/include/QtGui -I/usr/include/QtCore -o siphellocmodule.o 
siphellocmodule.cpp
$ g++ -c -pipe -fPIC -O2 -Wall -W -DNDEBUG -I. -I/usr/include/python2.7 
-I/usr/include/QtGui -I/usr/include/QtCore -o siphellohello.o 
siphellohello.cpp
$ g++ -Wl,--hash-style=gnu -Wl,--as-needed -shared 
-Wl,--version-script=hello.exp -o hello.so siphellocmodule.o 
siphellohello.o


I've got: undefined symbol: _ZN5hello9loadImageEP6QImage.I found out 
that I've only declared loadImage. So after all it works fine. Thank you 
for help.

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

Re: [PyQt] Bug report: multiple QApplication instances cause a segfault

[David Townshend]

On Tue, Jun 21, 2011 at 11:21 PM, Algis Kabaila akaba...@pcug.org.auwrote:

 On Wed, 22 Jun 2011 02:04:25 AM David Townshend wrote:
  Hi
 
  I'm not sure of the appropriate place to file a PyQt bug report, so I
 hope
  its ok to send it to this mailing list.
 
  The problem is that creating (and quitting) multiple QApplications in
  succession causes a segfault.  This situation tends to occur in unit
 tests,
  particularly in testing subclasses of QApplication.
 
  The following snippet illustrates the problem:
   from PyQt4 import QtGui
   app = QtGui.QApplication([])
   app.quit()
   app = QtGui.QApplication([])
   app.quit()
   app = QtGui.QApplication([])
 
  Segmentation fault
 
  Here is my python info:
  Python 3.2 (r32:88445, Apr 15 2011, 11:09:05)
  [GCC 4.5.2 20110127 (prerelease)] on linux2
 
  I'm using PyQt 4.8.4 on Arch Linux.  I have tried it on Windows XP, but
 the
  segfault does not occur there.  I haven't tried other linux
 distributions.
 
  David

 David,

 There is a bug tracker for bug reports where the bugs should be reported. I
 do
 not remember its URL, however.

 On my  kubuntu natty OS  the results are somewhat different:

 Using GUI Bash Shell:

 ak@supremo:~$ python3
 Python 3.2 (r32:88445, Mar 25 2011, 19:56:22)
 [GCC 4.5.2] on linux2
 Type help, copyright, credits or license for more information.
  from PyQt4 import QtGui
  app = QtGui.QApplication([])
  app.quit()
  app = QtGui.QApplication([])
  app.quit()
  app = QtGui.QApplication([])
  app.quit()
  app = QtGui.QApplication([])
  app.quit()
  app = QtGui.QApplication([])
  app.quit()
[--- ctrl+D pressed to quit python3.2]
 Segmentation fault
 ak@supremo:~$

 Segmentation fault occured when quitting Python3.2, not when repeatedly
 creating and quitting app.

 Using IDLE things go strange sooner:

 Python 3.2 (r32:88445, Mar 25 2011, 19:56:22)
 [GCC 4.5.2] on linux2
 Type copyright, credits or license() for more information.
  No Subprocess 
  from PyQt4 import QtGui
  app = QtGui.QApplication([])
  app.quit()
  app = QtGui.QApplication([])
  app.quit()

 Python 3.2 IDLE shell vanishes from the screen without warning. No Return
 pressed after typing app.quit() !

 My Linux OS:
 ak@supremo:~$ lsb_release -a
 No LSB modules are available.
 Distributor ID: Ubuntu
 Description:Ubuntu 11.04
 Release:11.04
 Codename:   natty
 ak@supremo:~$

 PyQt4 and Qt versions:

 Python 3.2 (r32:88445, Mar 25 2011, 19:56:22)
 [GCC 4.5.2] on linux2
 Type help, copyright, credits or license for more information.
  from PyQt4.QtCore import (PYQT_VERSION_STR, QT_VERSION_STR)
  PYQT_VERSION_STR
 '4.8.4'
  QT_VERSION_STR
 '4.7.2'
 

 I've encountered similar problems in PySide.  I think it was considered to
 be
 a Python IDLE fault.  I know it does not shed much light on your problem,
 only
 some additional information.

 OldAl.


Thanks for the info.  If this doesn't happen in Kubuntu then perhaps it is
specific to my distro (I was working in a terminal, not idle, so its not
that).  Either way, I think I'll dig a little deeper and see if I can get a
useful traceback.

I did look around for a bug report website for quite a while, but didn't
find anything. If anyone knows where I can report a pyqt bug, please let me
know.

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

Re: [PyQt] Bug report: multiple QApplication instances cause a segfault

[Baz Walter]

On 21/06/11 17:04, David Townshend wrote:

The problem is that creating (and quitting) multiple QApplications in
succession causes a segfault.  This situation tends to occur in unit tests,
particularly in testing subclasses of QApplication.

The following snippet illustrates the problem:


 from PyQt4 import QtGui
 app = QtGui.QApplication([])
 app.quit()
 app = QtGui.QApplication([])
 app.quit()
 app = QtGui.QApplication([])

Segmentation fault


according to the qt docs, only one application object should be created 
at a time, and there is a global qApp pointer which refers to the 
current instance.


this suggests that, in pyqt, something like the following should work:

from PyQt4 import QtGui
QtGui.qApp = app = QtGui.QApplication([])
app.quit()
QtGui.qApp = app = None
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Drag-and-drop editing in QListWidget or QListView

[Nathan Weston]

On 6/7/2011 7:53 AM, Nathan Weston wrote:



On 06/02/2011 07:42 PM, David Boddie wrote:

The draganddrop/puzzle example provided with PyQt uses a QListWidget to
display a collection of puzzle pieces that can be dropped inside or
outside
the list, though it's not exactly the most user friendly interface you
could imagine.

The itemviews/puzzle example is more or less the same, but uses QListView
instead of QListWidget. It implements support for drag and drop in a
custom model, which is based on QAbstractListModel to make it as
simple as
possible. Strangely, the piece movement is quite a bit more intuitive
than
in the other example.



Thanks, that got me started in the right direction. It seems that I
basically have to reimplement the InternalMove behavior myself -- it has
some nice visual touches that aren't duplicated in the examples.

This leaves me wondering, though -- if InternalMove doesn't give you any
way to find out when things move, what's the point?



Update: after going around in circles with this for quite some time, I 
came to the conclusion that I really want to stick with the default drag 
and drop implementation using InternalMove. As soon as I override any 
part of that, I have to reimplement a ton of stuff (the pixmap for the 
QDrag(), the target indicators in the ListWidget, etc).


In case anyone is interested, this is the solution I came up with. It 
overrides startDrag and dropEvent in QListWidget in order to get the 
dragged item along with its old/new indices, but calls the superclass 
methods to do all the actual work.


It seems a little hacked-up to me, but it works.

It might be slightly cleaner to decode the the mime data in dropEvent -- 
I think this can hypothetically be decoded back into a QListWidgetItem. 
But I couldn't quite figure out how to do it.



class DragAndDropList(QListWidget):
itemMoved = pyqtSignal(int, int, QListWidgetItem) # Old index, new 
index, item


def __init__(self, parent=None, **args):
super(DragAndDropList, self).__init__(parent, **args)

self.setAcceptDrops(True)
self.setDragEnabled(True)
self.setDragDropMode(QAbstractItemView.InternalMove)
self.drag_item = None
self.drag_row = None

def dropEvent(self, event):
super(DragAndDropList, self).dropEvent(event)
self.itemMoved.emit(self.drag_row, self.row(self.drag_item), 
self.drag_item)

self.drag_item = None

def startDrag(self, supportedActions):
self.drag_item = self.currentItem()
self.drag_row = self.row(self.drag_item)
super(DragAndDropList, self).startDrag(supportedActions)


--
. . . . . . . . . . . . . . . . . . . . . . . . .
Nathan Weston   nat...@genarts.com
GenArts, Inc.   Tel: 617-492-2888
955 Mass. Ave   Fax: 617-492-2852
Cambridge, MA 02139 USA www.genarts.com
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Bug report: multiple QApplication instances cause a segfault

[David Townshend]

On Wed, Jun 22, 2011 at 2:34 PM, Baz Walter baz...@ftml.net wrote:

 On 21/06/11 17:04, David Townshend wrote:

 The problem is that creating (and quitting) multiple QApplications in
 succession causes a segfault.  This situation tends to occur in unit
 tests,
 particularly in testing subclasses of QApplication.

 The following snippet illustrates the problem:

   from PyQt4 import QtGui
  app = QtGui.QApplication([])
  app.quit()
  app = QtGui.QApplication([])
  app.quit()
  app = QtGui.QApplication([])

 Segmentation fault


 according to the qt docs, only one application object should be created at
 a time, and there is a global qApp pointer which refers to the current
 instance.

 this suggests that, in pyqt, something like the following should work:

 from PyQt4 import QtGui
 QtGui.qApp = app = QtGui.QApplication([])
 app.quit()
 QtGui.qApp = app = None
 __**_
 PyQt mailing listPyQt@riverbankcomputing.com
 http://www.riverbankcomputing.**com/mailman/listinfo/pyqthttp://www.riverbankcomputing.com/mailman/listinfo/pyqt


I've investigated further and found that its caused by the gtk style which I
am using, since I am running gnome. Simply changing the qt style avoids the
problem. I recall reading about similar issues before with the gtk-qt style,
so I think that this is a know problem.  However, I noticed that after
changing the style, python still segfaults on exit.  gdb indicates that it
is something in the QApplication destructor, and it seems that deleting the
instance after quitting solves this, e.g.:

 from PyQt4.QtGui import QApplication
 for i in range(10):
... app = QApplication([])
... app.quit()
... del app
...
 exit()

I experimented a bit with setting qApp = None, but it didn't make a
difference.
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Bug report: multiple QApplication instances cause a segfault

[Baz Walter]

On 22/06/11 20:49, David Townshend wrote:

On Wed, Jun 22, 2011 at 2:34 PM, Baz Walterbaz...@ftml.net  wrote:

according to the qt docs, only one application object should be created at
a time, and there is a global qApp pointer which refers to the current
instance.

this suggests that, in pyqt, something like the following should work:

from PyQt4 import QtGui
QtGui.qApp = app = QtGui.QApplication([])
app.quit()
QtGui.qApp = app = None

[snip]

I've investigated further and found that its caused by the gtk style which I
am using, since I am running gnome. Simply changing the qt style avoids the
problem. I recall reading about similar issues before with the gtk-qt style,
so I think that this is a know problem.  However, I noticed that after
changing the style, python still segfaults on exit.  gdb indicates that it
is something in the QApplication destructor, and it seems that deleting the
instance after quitting solves this, e.g.:


from PyQt4.QtGui import QApplication
for i in range(10):

... app = QApplication([])
... app.quit()
... del app
...

exit()


I experimented a bit with setting qApp = None, but it didn't make a
difference.


my point was simply that you need to make sure you remove all references 
to the current qpplication instance before creating a new one.


in general, setting qApp to the instance of qapplication isn't 
necessary. but it's worth noting that qApp won't refer to the same 
*pyqt* object unless it's explicitly over-written. this may become 
relevant when working with subclasses of qapplication. of course, if you 
don't use qApp, it won't make any difference, as you say ;-)

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

Re: [PyQt] Bug report: multiple QApplication instances cause a segfault

[Algis Kabaila]

On Thu, 23 Jun 2011 08:17:04 AM Baz Walter wrote:
 On 22/06/11 20:49, David Townshend wrote:
  On Wed, Jun 22, 2011 at 2:34 PM, Baz Walterbaz...@ftml.net  wrote:
  according to the qt docs, only one application object should be created
  at a time, and there is a global qApp pointer which refers to the
  current instance.
  
  this suggests that, in pyqt, something like the following should work:
  
  from PyQt4 import QtGui
  QtGui.qApp = app = QtGui.QApplication([])
  app.quit()
  QtGui.qApp = app = None
 
 [snip]
 
  I've investigated further and found that its caused by the gtk style
  which I am using, since I am running gnome. Simply changing the qt style
  avoids the problem. I recall reading about similar issues before with
  the gtk-qt style, so I think that this is a know problem.  However, I
  noticed that after changing the style, python still segfaults on exit. 
  gdb indicates that it is something in the QApplication destructor, and
  it seems that deleting the
  
  instance after quitting solves this, e.g.:
  from PyQt4.QtGui import QApplication
  
  for i in range(10):
  ... app = QApplication([])
  ... app.quit()
  ... del app
  ...
  
  exit()
  
  I experimented a bit with setting qApp = None, but it didn't make a
  difference.
 
 my point was simply that you need to make sure you remove all references
 to the current qpplication instance before creating a new one.
 
 in general, setting qApp to the instance of qapplication isn't
 necessary. but it's worth noting that qApp won't refer to the same
 *pyqt* object unless it's explicitly over-written. this may become
 relevant when working with subclasses of qapplication. of course, if you
 don't use qApp, it won't make any difference, as you say ;-)

Baz,

This does not explain why the IDLE quits so early in the test, even before CR 
is pressed... Actually, in python3.2 if one programs in IDLE, one finds that 
IDLE is useless with PyQt as it quits (just vanishes from the screen...) if 
one tries to run a script after modifying it.  Basically, IDLE works only if 
it is invoked from scratch each time one wants to run a program.

I suggest that because of such misbehaviour it is not useful to look for 
faults in the test case - there is a fault, either in Python3 IDLE, Python 3, 
PyQt, Qt itself.

As for the PyQt bug tracker - I was not able to find it, though I saw bug 
reports in several places, though I said earlier that I did see it somewhere.  

I would write it down to my aging memory

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

Re: [PyQt] Bug report: multiple QApplication instances cause a segfault

[David Townshend]

On Thu, Jun 23, 2011 at 6:14 AM, Algis Kabaila akaba...@pcug.org.au wrote:

 On Thu, 23 Jun 2011 08:17:04 AM Baz Walter wrote:
  On 22/06/11 20:49, David Townshend wrote:
   On Wed, Jun 22, 2011 at 2:34 PM, Baz Walterbaz...@ftml.net  wrote:
   according to the qt docs, only one application object should be
 created
   at a time, and there is a global qApp pointer which refers to the
   current instance.
  
   this suggests that, in pyqt, something like the following should work:
  
   from PyQt4 import QtGui
   QtGui.qApp = app = QtGui.QApplication([])
   app.quit()
   QtGui.qApp = app = None
 
  [snip]
 
   I've investigated further and found that its caused by the gtk style
   which I am using, since I am running gnome. Simply changing the qt
 style
   avoids the problem. I recall reading about similar issues before with
   the gtk-qt style, so I think that this is a know problem.  However, I
   noticed that after changing the style, python still segfaults on exit.
   gdb indicates that it is something in the QApplication destructor, and
   it seems that deleting the
  
   instance after quitting solves this, e.g.:
   from PyQt4.QtGui import QApplication
  
   for i in range(10):
   ... app = QApplication([])
   ... app.quit()
   ... del app
   ...
  
   exit()
  
   I experimented a bit with setting qApp = None, but it didn't make a
   difference.
 
  my point was simply that you need to make sure you remove all references
  to the current qpplication instance before creating a new one.
 
  in general, setting qApp to the instance of qapplication isn't
  necessary. but it's worth noting that qApp won't refer to the same
  *pyqt* object unless it's explicitly over-written. this may become
  relevant when working with subclasses of qapplication. of course, if you
  don't use qApp, it won't make any difference, as you say ;-)

 Baz,

 This does not explain why the IDLE quits so early in the test, even before
 CR
 is pressed... Actually, in python3.2 if one programs in IDLE, one finds
 that
 IDLE is useless with PyQt as it quits (just vanishes from the screen...) if
 one tries to run a script after modifying it.  Basically, IDLE works only
 if
 it is invoked from scratch each time one wants to run a program.

 I suggest that because of such misbehaviour it is not useful to look for
 faults in the test case - there is a fault, either in Python3 IDLE, Python
 3,
 PyQt, Qt itself.

 As for the PyQt bug tracker - I was not able to find it, though I saw bug
 reports in several places, though I said earlier that I did see it
 somewhere.

 I would write it down to my aging memory

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


Baz - Sorry, I think I misunderstood you slightly, but I reached the same
conclusion - to delete all references to the instance.  I don't think that
omitting this should cause a segfault though, so it does look like a bug,
but at least its easy to work around.

OldAl - I don't get that behaviour.  Is this is linux or windows, have you
tried to get a backtrace to see where the problem is?  I have to admit I
never use IDLE, I much prefer the console interface, so I haven't had much
opportunity to see if this happens to me.

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