Re: [PyQt] Can't get keyboard shortcuts to work

2012-01-22 Thread David Townshend
Thanks for the reply.  I just realised that the example I sent does
actually work (once I sort out the focus).  After about an hour of testing
I discovered that in my actual scenario I never called widget.addAction().
 I've got quite a bit of abstraction around the QActions and I somehow
missed it!

On Sun, Jan 22, 2012 at 2:16 PM, Hans-Peter Jansen  wrote:

> On Thursday 19 January 2012, 10:53:31 David Townshend wrote:
> > I can't get keyboard shortcuts to work with Qt.WidgetShortcut
> > or Qt.WidgetWithChildrenShortcut context.  It seems that nothing I do
> > will trigger the action. Below is a sample class which is giving the
> > problem. Can anyone point out where I am going wrong?
> >
> > class Widget(QtGui.QWidget):
> > def __init__(self):
> > super().__init__()
> > self.act = QtGui.QAction('test', self)
> >
> > self.act.setShortcut(QtGui.QKeySequence(QtGui.QKeySequence.Copy))
> > self.act.setShortcutContext(Qt.WidgetWithChildrenShortcut)
> > self.addAction(self.act)
> > self.act.triggered.connect(self.slot)
> >
> > def slot(self):
> > print('triggered')
>
> Check out FocusPolicy in the fine manual..
>
> Pete
>
>
> ___
> PyQt mailing listPyQt@riverbankcomputing.com
> http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

[PyQt] Can't get keyboard shortcuts to work

2012-01-19 Thread David Townshend
I can't get keyboard shortcuts to work with Qt.WidgetShortcut
or Qt.WidgetWithChildrenShortcut context.  It seems that nothing I do will
trigger the action. Below is a sample class which is giving the problem.
 Can anyone point out where I am going wrong?

class Widget(QtGui.QWidget):
def __init__(self):
super().__init__()
self.act = QtGui.QAction('test', self)
self.act.setShortcut(QtGui.QKeySequence(QtGui.QKeySequence.Copy))
self.act.setShortcutContext(Qt.WidgetWithChildrenShortcut)
self.addAction(self.act)
self.act.triggered.connect(self.slot)

def slot(self):
print('triggered')

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

[PyQt] Odd sorting behaviour in QSortProxyModel

2012-01-10 Thread David Townshend
Hi

I've found something rather odd that happens when sorting in a
QSortFilterProxyModel with datetime.date datatypes.  If I call sort()
on a column containing datetime.date values, it doesn't appear to do
anything.  If I then call sort on another column, then on the first
column again, it works.  I am using python 3.2 and PyQt 4.8.3 on
Windows XP. I haven't tried this on any other platform.  Does anyone
else get this behaviour?

The following code shows illustrates the problem:

from datetime import date
from PyQt4.QtCore import QAbstractTableModel, Qt, QDate
from PyQt4.QtGui import QSortFilterProxyModel

class Model(QAbstractTableModel):

    def rowCount(self, parent=None):
        return 4

    def columnCount(self, parent=None):
        return 2

    def data(self, index, role):
        if role != Qt.DisplayRole:
            return super().data(index, role)
        values = [(11, date(2011, 1, 1)),
                  (10, date(2010, 1, 1)),
                  (14, date(2014, 1, 1)),
                  (5, date(2005, 1, 1))]
        return values[index.row()][index.column()]

model = Model()
sortModel = QSortFilterProxyModel()
sortModel.setSourceModel(model)

col = 1

print("These should be sorted, but aren't")
sortModel.sort(col)
for row in range(4):
    print(sortModel.data(sortModel.index(row, col), Qt.DisplayRole))

print("Now they are sorted")
sortModel.sort(0)
sortModel.sort(col)
for row in range(4):
    print(sortModel.data(sortModel.index(row, col), Qt.DisplayRole))
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt


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

2011-06-22 Thread David Townshend
If it vanishes, it implies a segfault which you will probably see if you run
idle form the command line. You should be able to get a backtrace by running
idle through gdb, i.e, from the command line, run "gdb idle". Then in gdb
type "run". Idle should start as usual, so get it to crash.  Then within gdb
type "bt". This will give a backtrace which will hopefully at least point to
whether its python, pyqt or qt.

David

On Thu, Jun 23, 2011 at 8:16 AM, Algis Kabaila  wrote:

> On Thu, 23 Jun 2011 03:23:36 PM David Townshend wrote:
> > On Thu, Jun 23, 2011 at 6:14 AM, Algis Kabaila 
> 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 Walter
>  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, 

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

2011-06-22 Thread David Townshend
On Thu, Jun 23, 2011 at 6:14 AM, Algis Kabaila  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 Walter  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

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

2011-06-22 Thread David Townshend
On Wed, Jun 22, 2011 at 2:34 PM, Baz Walter  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/pyqt<http://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

2011-06-22 Thread David Townshend
On Tue, Jun 21, 2011 at 11:21 PM, Algis Kabaila wrote:

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

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

2011-06-21 Thread David Townshend
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
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt