[PyKDE] PyQt book from Boudewijn Rempt?
Hello, as this book has been published some time ago, I wanted to ask how much of it is still relevant for Qt 4? TIA, Sincerely, Wolfgang Keller ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Auto-connecting Slots
Gerard Vermeulen [EMAIL PROTECTED] wrote: I understand that you like to take an unrecommended shortcut and pollute the global namespace (Q-, q-prefix or not), but it is no reason to make life harder for people who don't. The Q prefix *is* a namespace. It's the way namespaces have always worked way before we were using languages with explicit syntax for namespaces, and the way it works in C++ for Qt. Then, if you want to double your namespace by prefixing an unneeded QtCore in front of it, and making your source code harder and slower to read, that's your choice. The fact that in Python modules are namespaces doesn't mean that one has to blindly use them as namespaces even when not necessary. Again, I have *never* seen Python code using PyOpenGL with the module as a namespace (GL.glBegin), so I just can't see why it should be any different for Qt. After from import PyQt4.QtCore import * hex and oct from QtCore are in the global namespace hiding two Python builtins. Nobody ever complained. Why single out the rather harmless signature? There are more than 20 names without a Q or q prefix in QtCore (TT's decision). Shouldn't they all get a prefix? I don't think so. Nobody ever complained because PyQt4 is pretty preliminar, it hasn't yet seen a single public release. I don't have a recent PyQt4 snapshot around, can you post a list of those names? Some could be skipped when using the star import (using __all__). It pretty much depends on what they are. hex() and oct() looks like another serious problem that needs a solution, to me. Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Auto-connecting Slots
Patrick K. O'Brien [EMAIL PROTECTED] wrote: If we're going to use other large projects as examples then surely wxPython is a better one. They spent the past year or two moving from this: from wx import * button = wxButton(...) [...] to: import wx button = wx.Button(...) In fact, I'd be *perfectly* fine with Q.String, Q.Widget and Q.Label (from PyQt4 import QtCore as Q). What I deeply dislike is the verbose QtCore.QWidget. Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] new PyQt4 signal mechanism
On Sunday 29 January 2006 4:33 pm, Detlev Offenbach wrote: Hi, I have a signal, that should be emitted from a Python method with a list of integers. I declared it like self.emit(SIGNAL(dataChanged(int *)), [index]) However, when it triggers, I get a TypeError exception saying, that argument 1 is of the wrong type. What would be the correct signal definition? That's a very good question. A requirement of the new handling is that all signals are implemented in C++ under the covers (so that queued and inter-thread connections work). That means the signature has to be something that PyQt can convert the Python arguments to - which it can't in this case. There are a number of options... 1. Revert to old-style connections in such a case. I don't like this because you lose the queued and inter-thread connections. 2. Treat PyObject * (or something similar) as a special case in code that parses the signature to allow any arbitrary Python object to be passed. This would have the side-effect of bypassing all the marshalling/de-marshalling that is going on when sending a Python signal to a Python slot. 3. Implicitly treat any such types as PyObject * as described above. The declaration you used would then work unchanged. I need to think about this a bit more. Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Auto-connecting Slots
Giovanni Bajo wrote: Patrick K. O'Brien [EMAIL PROTECTED] wrote: If we're going to use other large projects as examples then surely wxPython is a better one. They spent the past year or two moving from this: from wx import * button = wxButton(...) [...] to: import wx button = wx.Button(...) In fact, I'd be *perfectly* fine with Q.String, Q.Widget and Q.Label (from PyQt4 import QtCore as Q). What I deeply dislike is the verbose QtCore.QWidget. I agree, although my preference would be qt.String, qt.Widget, etc. -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevohttp://www.schevo.org Louie http://louie.berlios.de ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Auto-connecting Slots
Patrick K. O'Brien [EMAIL PROTECTED] wrote: If we're going to use other large projects as examples then surely wxPython is a better one. They spent the past year or two moving from this: from wx import * button = wxButton(...) [...] to: import wx button = wx.Button(...) In fact, I'd be *perfectly* fine with Q.String, Q.Widget and Q.Label (from PyQt4 import QtCore as Q). What I deeply dislike is the verbose QtCore.QWidget. I agree, although my preference would be qt.String, qt.Widget, etc. That too, though I prefer Q. as it's more similar to the C++ counterpart. Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
