Re: [PyQt] debug builds under windows

2012-04-14 Thread Nathan Weston

On 04/14/2012 05:16 AM, Erik Janssens wrote:

Hi,

How are debug builds supposed to work under windows ?

I'm observing a segfault that I can only reproduce on
windows, and would like to create a stackstrace.

I've build Qt in debug mode.  But when building sip
with --debug, it appears that the dll is named sip_d
instead of sip, making the dll unimportable.

On a side note : I tried to build python itself in debug
mode, resulting in a python_d.exe.  however this exe even
fails to import things like os or sys.

Thanks,

Erik


I was in a similar situation a few months ago, and I eventually got it 
to work, but it took me a couple days of struggling with it.


You have to rebuild everything in debug mode -- Python, Qt, SIP, and 
PyQt. The python build went smoothly for me and I didn't run into a 
problem like you describe -- maybe you need to adjust your PATH?


In case it helps, here are the notes I wrote myself at the time:

 1. Build a debug version of Python. This was pretty straightforward, 
just used the Visual Studio project in PC/VS8.0 (for VS2005 -- I didn't 
see any support for later versions).

 2. Build Qt.
  * Download the zip file of the source distribution -- the tarball has 
a configure shell script, but not the configure.exe which you need for a 
windows build.

  * Open up a Visual Studio command prompt
  * Run configure
  * Build with nmake
 3. Build SIP.
  * Set LIB to point to your python build
  * Run configure with your debug python
  * Build with nmake install
 4. Build PyQt
  * Make sure that qmake from your Qt build is in the path.
  * Configure and build as above
  * I had to edit Makefile.release in the designer subdir to link the 
Python/Qt debug libs. There's also Makefile.debug but my build didn't 
use it.
  * After all that, I kept getting a link error about python26.lib -- 
which doesn't exist b/c the debug build has python26_d.lib. I couldn't 
find the problem anywhere in the Makefiles, so I just copied the lib 
from my regular Python 2.6 install. The build finished and it seems to work.

 5. Put the debug version of Qt in your PATH

I had one more weird problem when I actually ran this in the debugger: 
the DLLs in $QTDIR/bin don't give me any stack traces, b/c there are no 
PDBs there. So I had to point the path at $QTDIR/lib instead -- which 
contains another set of the DLLs (not sure if they're identical or not) 
as well as corresponding PDBs. Then it works fine.



--
. . . . . . . . . . . . . . . . . . . . . . . . .
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


[PyQt] Bug in QWidget.geometry()?

2012-02-29 Thread Nathan Weston
According to the Qt docs, QWidget.geometry() should return the geometry 
of the widget itself, not including the window border. But I'm finding 
that's not the case -- geometry() is including the borders and returning 
the same value as frameGeometry().


However, setGeometry() behaves as documented, which has the interesting 
side effect that window.setGeometry(window.geometry()) moves the window!


I'm using Qt 4.8.0 and PyQt 4.9 on Windows 7.

The attached test program demonstrates the problem. I use move() (which 
*does* account for window borders) to position the window at the upper 
left of the screen. But then a call to self.setGeometry(self.geometry()) 
moves the window off screen.


Interestingly, the value of geometry() is the same before and after the 
call to setGeometry(), despite the fact that the window has moved on screen.


--
. . . . . . . . . . . . . . . . . . . . . . . . .
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
from PyQt4.QtGui import QApplication
from PyQt4.QtGui import QWidget
import PyQt4.pyqtconfig

class MyWindow(QWidget):
def __init__(self):
super(QWidget, self).__init__()

self.move(0,0)
print self.geometry()
self.setGeometry(self.geometry())
print self.geometry()

app = QApplication([])
w = MyWindow()
w.show()
app.exec_()
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

[PyQt] Strange problem with item in QTreeView

2012-01-05 Thread Nathan Weston
I'm using a QTreeView with a custom model. In my application I have a 
menu item that adds a new element to the model, fills it with default 
data (e.g. New Item), then edits it in the tree view so the user can 
type in the value they want.


This all works fine except that 1-2 seconds after I call edit(), 
something calls setData() on my model (with role=Qt.EditRole), and sets 
the data back to New Item. This happens independently of any action by 
the user -- if they have started typing something, it will be overwritten.


My application isn't calling setData() directly anywhere, nor connection 
it to any signals. If I throw an exception or print a traceback in 
setData(), it doesn't show any caller, so I guess it's coming from the 
C++ side somehow. Is it possible to trace the call any further than this?


Does anyone have an idea where this setData call might be coming from?

- Nathan

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


[PyQt] Bug: QComboBox popup doesn't account for different font sizes

2011-09-12 Thread Nathan Weston
If I create a QComboBox, use a stylesheet to increase or decrease the 
font size, and put it within a QGridLayout, then the popup menu of the 
combo box draws incorrectly.


With smaller fonts, it's too small vertically, and even if there are 
only 2-3 items, the last item is cut off and a vertical scrollbar 
appears. With larger fonts, the popup is tall enough but the items 
overlap each other, leaving empty space at the bottom. Only 14px fonts 
seem to work correctly.


I'm using Qt 4.7.3 and PyQt 4.7.2. The problem occurs on Windows and 
Mac, but not Linux (though I may have different versions installed 
there, I didn't have a chance to check).


Attached is a small program which demonstrates the problem.

I imagine this is really a Qt bug, but I don't do Qt C++ development so 
I haven't had a chance to test it in that environment.


import sip
sip.setapi('QString', 2)# Map QStrings to Python strings
sip.setapi('QVariant', 2)   # Auto-convert QVariants to/from Python types
from PyQt4.QtCore import *
from PyQt4.QtGui import *
import droid

css = 
QComboBox {
  font: 10px;
}


app = QApplication([])
w = QWidget()
g = QGridLayout(w)
c = QComboBox()
c.setStyleSheet(css)
for i in ['foo', 'bar', 'baz']:
c.addItem(i)
g.addWidget(c)

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

Re: [PyQt] QColorDialog: saving custom colors on Mac

2011-08-08 Thread Nathan Weston

On 7/29/2011 1:12 PM, Phil Thompson wrote:

On Mon, 18 Jul 2011 12:06:05 -0400, Nathan Westonnat...@genarts.com
wrote:

I'm trying to save the custom colors of QColorDialog using QSettings. On



Windows this is working correctly, but on Mac I'm having some problems:

1. QColorDialog.customColor() returns a long instead of an int
2. When I save that long using QSettings, it comes back as an int with a



value of -1

This seems like a bug in Qt or PyQt to me. Am I missing something?


It's the usual problem with QSettings not being able to restore the value
exactly because it doesn't retain sufficient type information. In this case
the fact that the value is unsigned and not signed (the bit pattern is the
same).

You should always use the 'type' keyword argument to QSettings.value() to
explicitly state what you are expecting back. As Python doesn't have an
unsigned type you have to specify a C++ type...

 settings.value('color', type='uint')

...should work.



What if I'm retrieving a list of unsigned ints? What's the correct type 
signature?


I'm using the v2 QVariant API so I just collected all the custom colors 
into a python list and saved that.


--
. . . . . . . . . . . . . . . . . . . . . . . . .
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


[PyQt] QColorDialog: saving custom colors on Mac

2011-07-22 Thread Nathan Weston
I'm trying to save the custom colors of QColorDialog using QSettings. On 
Windows this is working correctly, but on Mac I'm having some problems:


1. QColorDialog.customColor() returns a long instead of an int
2. When I save that long using QSettings, it comes back as an int with a 
value of -1


This seems like a bug in Qt or PyQt to me. Am I missing something?


Related to this, when you pass a negative int to 
QColorDialog.setCustomColor(), it throws this rather baffling exception:
  TypeError: QColorDialog.setCustomColor(int, int): argument 2 has 
unexpected type 'int'


It seems like ValueError would be more appropriate. At the very least, a 
more accurate error message would have saved me about 20 minutes of 
scratching my head. :)



Here's my complete code. I'm using the v2 QVariant API, but I get 
similar results with the v1 API.


import sip
sip.setapi('QVariant', 2)
from PyQt4.QtCore import *
from PyQt4.QtGui import *

settings = QSettings()
settings.beginGroup('colordialog')
c = QColorDialog.customColor(0)
print 'Original color:', c, type(c)
settings.setValue('color', c)
settings.endGroup()


settings = QSettings()
settings.beginGroup('colordialog')
c = settings.value('color')
print 'Restored color:', c, type(c)
QColorDialog.setCustomColor(0, settings.value('color'))
settings.endGroup()

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


Re: [PyQt] QLineEdit vs. menu keyboard shortcuts

2011-06-30 Thread Nathan Weston

On 6/29/2011 6:16 PM, Baz Walter wrote:

On 29/06/11 18:57, Nathan Weston wrote:

On 6/29/2011 1:32 PM, Baz Walter wrote:

going back to your earlier example of dragging in the line-edit to
change its value: all you need to do is clearFocus() when the drag
starts and setFocus() when the drag ends. that way, whilst the drag is
in progress, the line-edit's shortcuts won't work, but your global
shortcuts will.

if that's not what you want, please try to make it clear what you do
want (i.e. with a working example).

[snip]

Now, when the widget is in its non-editable state, and the user hits
Ctrl-Z, I want it to trigger the Undo action on the Edit menu.
Unfortunately, QLineEdit intercepts the Ctrl-Z keystroke and does
nothing (because it's not editable).


the example you posted earlier works (i.e. Ctrl+Z prints 'action') if
the Foo widget has been set as read-only.

(nb: the setShortcutContext line also needs to be commented out)



Interesting... it works as you say on my Linux machine at home, but not 
on my Windows machine at work. The Windows machine has Qt 4.6.2, I don't 
know about the Linux machine off the top of my head. What platform/Qt 
version are you testing on?



I can't call clearFocus() at the end of the drag, because this would
break the Up/Down arrow shortcuts.


call clearFocus() at the *start* of the drag, setFocus() at the *end*.


I don't see how that would help... after the drag, the line-edit will 
have focus again, and will eat the Ctrl-Z shortcut.


--
. . . . . . . . . . . . . . . . . . . . . . . . .
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] QLineEdit vs. menu keyboard shortcuts

2011-06-30 Thread Nathan Weston

On 6/30/2011 10:44 AM, Nathan Weston wrote:

On 6/29/2011 6:16 PM, Baz Walter wrote:

On 29/06/11 18:57, Nathan Weston wrote:

On 6/29/2011 1:32 PM, Baz Walter wrote:

going back to your earlier example of dragging in the line-edit to
change its value: all you need to do is clearFocus() when the drag
starts and setFocus() when the drag ends. that way, whilst the drag is
in progress, the line-edit's shortcuts won't work, but your global
shortcuts will.

if that's not what you want, please try to make it clear what you do
want (i.e. with a working example).

[snip]

Now, when the widget is in its non-editable state, and the user hits
Ctrl-Z, I want it to trigger the Undo action on the Edit menu.
Unfortunately, QLineEdit intercepts the Ctrl-Z keystroke and does
nothing (because it's not editable).


the example you posted earlier works (i.e. Ctrl+Z prints 'action') if
the Foo widget has been set as read-only.

(nb: the setShortcutContext line also needs to be commented out)



Interesting... it works as you say on my Linux machine at home, but not
on my Windows machine at work. The Windows machine has Qt 4.6.2, I don't
know about the Linux machine off the top of my head. What platform/Qt
version are you testing on?



I updated to the latest Qt/PyQt and it's working now. My original 
application is working correctly as well.



--
. . . . . . . . . . . . . . . . . . . . . . . . .
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] safely closing QThread when application exits.

2011-06-30 Thread Nathan Weston
It looks like you're relying on the _del_ method of your worker thread 
to shut it down. I'm not sure if that's a good idea -- Python doesn't 
provide very strong guarantees about when objects will be destroyed.


You might try shutting down your worker (and waiting on it) from the 
main thread instead -- maybe in your window closeEvent.


On 6/27/2011 7:44 PM, Yaşar Arabacı wrote:

hi,

I am pyqt beginner and followed tutorials on the internet to learn it
until recently. Then I have wanted to develop my own application. I am
developing a simple chat application.

I want to have 2 windows running independently (in other words two
separate applications), one for server and one for client. When server
starts to run, it is going to wait for client to run, and they will
chat. So far, I could only start doing server side. I am using QThread,
which is a subject rather unclear to me. I am getting this error when I
close my application from X button:

QThread: Destroyed while thread is still running

I am guessing that this occurs because I am not closing the thread
safely before application exists. I was wondering how I can make my
thread respond to application exist so that it can close itself. Here is
my code:


chat_server.py


import sys
from PyQt4 import QtCore,QtGui
from chat_ui import Ui_MainWindow
import socket

class Server(QtGui.QMainWindow):

 def __init__(self,parent=None):
 super(Server,self).__init__()
 self.ui = Ui_MainWindow()
 self.ui.setupUi(self)

 self.ui.textEdit.append(Waiting for inbound connections)
 self.netconnector = NetConnectWorker(self)
 self.netconnector.attemptConnect()


self.connect(self.netconnector,QtCore.SIGNAL(Connected()),self.connected)

self.connect(self.netconnector,QtCore.SIGNAL(dataRecieved(QString)),self.messageRecieved)

self.connect(self.netconnector,QtCore.SIGNAL(socketError(QString)),self.socketError)

 def connected(self):
 self.ui.textEdit.append(Connected)

 def messageRecieved(self,data):
 self.ui.textEdit.append(data)

 def socketError(self,msg):
 print msg
 self.ui.textEdit.append(Encountered a socket error:\n %s % msg)


class NetConnectWorker(QtCore.QThread):

 def __init__(self,parent=None):
 super(NetConnectWorker,self).__init__(parent)
 self.exiting = False
 self.socket = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
 self.host = ''
 self.port = 5
 self.backlog = 5
 self.address = 
 self.client = 

 def __del__(self):
 self.exiting = True
 self.wait()
 if self.client:
 self.client.close()

 def attemptConnect(self):
 self.start()

 def run(self):
 try:
 self.socket.bind((self.host,self.port))
 except socket.error,error:
 print dir(error)
 self.emit(QtCore.SIGNAL(socketError(QString)),error.message)
 self.exit()
 self.socket.listen(self.backlog)

 self.client , self.address = self.socket.accept()

 if self.client:
 self.emit(QtCore.SIGNAL(Connected()))

 while not self.exiting:
 data = self.client.recv(1024)
 if data:
 self.emit(QtCore.SIGNAL(dataRecieved(QString)),data)



if __name__ == __main__:
 app = QtGui.QApplication(sys.argv)
 ex=Server()
 ex.show()
 sys.exit(app.exec_())



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


--
. . . . . . . . . . . . . . . . . . . . . . . . .
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] QLineEdit vs. menu keyboard shortcuts

2011-06-29 Thread Nathan Weston

from PyQt4.QtCore import *
from PyQt4.QtGui import *
import sys

class Foo(QLineEdit):
 def keyPressEvent(self, event):
 print 'Foo keyPress', event.key(); sys.stdout.flush()
 QLineEdit.keyPressEvent(self, event)

app = QApplication([])
window = QMainWindow()
f = Foo()
window.setCentralWidget(f)
window.show()

def do_action():
 print 'action'; sys.stdout.flush()
action1 = QAction('Action 1', f, triggered=do_action)
action1.setShortcut(Qt.CTRL + Qt.Key_Z)
action1.setShortcutContext(Qt.WidgetShortcut)


For actions that should work all over the mainwindow, you should use
Qt.WidgetWithChildren here.



Oops, that line was an artifact of an earlier experiment. I actually 
tried every possible value for shortcutContext, none of them seem to 
make a difference.

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


Re: [PyQt] QLineEdit vs. menu keyboard shortcuts

2011-06-29 Thread Nathan Weston

On 6/29/2011 1:32 PM, Baz Walter wrote:

On 29/06/11 18:21, Nathan Weston wrote:

On 6/29/2011 1:07 PM, Baz Walter wrote:

as was suggested earlier in this thread, if the line-edit doesn't have
the keyboard focus, it can't trigger its own shortcuts. if it *does*
have the focus, but the shortcut sequence is not one it handles, the
keypress event will be re-propagated (as happens with 'Ctrl+R' in your
example).

the simplest way to control the focus is to use clearFocus() and
setFocus().



Unfortunately, I need the line-edit to have keyboard focus (and respond
to some keyboard shortcuts), without bashing my global menu shortcuts.
It seems like there *should* be a clean way to do this by mucking around
with the keyPressEvent, but so far nobody seems to know of one.


did you actually try what was suggested?

going back to your earlier example of dragging in the line-edit to
change its value: all you need to do is clearFocus() when the drag
starts and setFocus() when the drag ends. that way, whilst the drag is
in progress, the line-edit's shortcuts won't work, but your global
shortcuts will.

if that's not what you want, please try to make it clear what you do
want (i.e. with a working example).



Short answer: focus tricks won't work for me. I need the widget to be 
able to accept keyboard focus and respond to some keyboard shortcuts.


Long answer:
I guess this will require a complete specification of how my widget works.

The widget appears to the user somewhat like a label displaying a 
number. If the user clicks and drags, the value will increase or 
decrease as the mouse is moved. By holding down modifier keys the user 
can adjust the speed with which the value changes.


If the user clicks (but doesn't drag), the number is highlighted and a 
text editing cursor appears. The widget at this point behaves exactly 
like a QLineEdit (with a validator to force numeric values). When the 
user presses Enter or the widget loses focus, it reverts to its default 
appearance.


If the widget has keyboard focus, but isn't in edit mode, the Up/Down 
arrow keys will nudge the value a small amount in either direction.


I am implementing this as a subclass of QLineEdit, overriding mouse and 
keyboard events and throwing in some CSS to make it look nice. When the 
widget is in edit mode it's set to editable, otherwise it's set to 
non-editable.


Now, when the widget is in its non-editable state, and the user hits 
Ctrl-Z, I want it to trigger the Undo action on the Edit menu. 
Unfortunately, QLineEdit intercepts the Ctrl-Z keystroke and does 
nothing (because it's not editable).


I can't call clearFocus() at the end of the drag, because this would 
break the Up/Down arrow shortcuts.


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


[PyQt] QLineEdit vs. menu keyboard shortcuts

2011-06-28 Thread Nathan Weston
QLineEdit has some keyboard shortcuts (e.g. Ctrl+Z for Undo) that clash 
with the shortcuts for QActions in my application menus. When a 
QLineEdit has keyboard focus, it intercepts these shortcuts and my 
QActions are never triggered.


I'd like to give application-level shortcuts precedence over QLineEdit's 
shortcuts, but I can't seem to find a clean and general way to do this.


Alternatively, is there a way to customize the keyboard shortcuts in 
QLineEdit? If I could disable some of the problematic shortcuts that 
would be a reasonable workaround.


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


Re: [PyQt] QLineEdit vs. menu keyboard shortcuts

2011-06-28 Thread Nathan Weston

On 6/28/2011 1:48 PM, Baz Walter wrote:

On 28/06/11 16:50, Nathan Weston wrote:

QLineEdit has some keyboard shortcuts (e.g. Ctrl+Z for Undo) that clash
with the shortcuts for QActions in my application menus. When a
QLineEdit has keyboard focus, it intercepts these shortcuts and my
QActions are never triggered.

I'd like to give application-level shortcuts precedence over QLineEdit's
shortcuts, but I can't seem to find a clean and general way to do this.

Alternatively, is there a way to customize the keyboard shortcuts in
QLineEdit? If I could disable some of the problematic shortcuts that
would be a reasonable workaround.


the default key bindings for QLineEdit are hard-coded, but the actual
key sequences used are platform-dependent (and the same goes for most
(all?) other widgets which have them).

but what is your reason for wanting to change the default behaviour?

as a user, i would expect all the 'normal' shortcuts to work when typing
in a line edit. if Ctrl+Z undid something in some other widget that i
wasn't looking at, it could become very confusing. (IIRC this was how
things used to work with qt3 - and good riddance to that!).


I have a subclass of QLineEdit for entering numbers. The user can either 
type in a number, or drag the mouse to increase/decrease the value, like 
a slider (similar widgets are often found in After Effects and other 
video editing software).


In the latter mode, the widget is temporarily set as non-editable, so 
its built-in Undo behavior doesn't work at all (but it still eats the 
keyboard event!).


--
. . . . . . . . . . . . . . . . . . . . . . . . .
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] Drag-and-drop editing in QListWidget or QListView

2011-06-22 Thread 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] Drag-and-drop editing in QListWidget or QListView

2011-06-07 Thread Nathan Weston



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?


--
. . . . . . . . . . . . . . . . . . . . . . . . .
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


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

2011-06-02 Thread Nathan Weston
I have a QListWidget with dragDropMode set to InternalMove, and I can 
move rows around by dragging as expected. But I also want to know when 
items are moved so I can update other data in my application, and I 
can't find any way to do this.


Would it help if I switched to QListView and implemented a model? I 
looked into this a bit but couldn't figure out how to do what I want.


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


[PyQt] Bug in sip.voidptr?

2010-12-10 Thread Nathan Weston
I think I've found a bug when constructing sip.voidptr from an integer. 
This statement:

sip.voidptr(2**31)

raises an exception: TypeError: a single integer, Capsule, CObject, None 
or another voidptr is required


The problem appears to be at voidptr.c:568
ptr = (void *)PyInt_AsLong(arg)

Python integers are signed, so 2**31 isn't a valid int (even though it's 
a valid 32-bit pointer), thus the cast fails. Values smaller than 2**31 
work fine. I was able to fix the problem by changing the cast to this:


ptr = (void *)PyLong_AsUnsignedLong(arg);

I'm not sure if this handles all overflows correctly (since a Python 
long can be larger than 2**32), but it works for me.



Versions:
Centos 5  (64-bit)
Python 2.6.6 (32-bit)
sip 4.11.1

--
. . . . . . . . . . . . . . . . . . . . . . . . .
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] Python 3 import error

2010-12-02 Thread Nathan Weston

On 12/2/2010 5:11 PM, Thorsten Kampe wrote:

* Hans-Peter Jansen (Thu, 2 Dec 2010 20:16:13 +0100)

sip.setapi('QVariant', 2)


Unfortunately, when I set sip.setapi('QVariant', 2) then I can't run
the application as stand-alone Pyinstaller[1] executable (neither under
Windows nor Linux):
ValueError: API 'QVariant' has already been set to version 1



PyInstaller somehow ends up importing PyQt before your code runs, so the 
API version is implicitly set to 1. You can work around this by editing 
support/rthooks/pyi_rth_qt4plugins.py and adding these lines before the 
import of QtCore:


import sip
sip.setapi('QVariant', 2)

--
. . . . . . . . . . . . . . . . . . . . . . . . .
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


[PyQt] QFileOpenEvent and double-clicking files

2010-10-29 Thread Nathan Weston
I'm trying to use QFileOpenEvent on Mac to make files open in my 
application when they're double-clicked. It very nearly works -- if my 
application is already running and I double-click an associated file (or 
drag a file onto the dock icon), it receives a QFileOpenEvent as expected.


If my application isn't running, then double-clicking a file launches 
the application -- but it never receives the QFileOpenEvent.


Is it possible that the OS is sending the open Apple Event before 
QApplication is initialized in order to receive it? Does anyone know of 
a workaround?

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