Re: [PyKDE] Status of new PyKDE snapshot

2006-02-21 Thread Andreas Pakulat
On 21.02.06 02:02:01, Danny Pansters wrote:
 On Tuesday 21 February 2006 00:56, Andreas Pakulat wrote:
  Hi,
 
  sorry but I have to ask: What is the status of a new PyKDE snapshot that
  works with the recent sip changes? I don't want to put any pressure on
  Jim, just a short note of his time plans for it would be really nice...
 
  Andreas
 
 My guess: see you in a year. And that's ok, any PyKDE4 can only take a 
 useful shape if there's any kde4 available.

As Izmail already said: I was asking about PyKDE3, as the 0122-snapshot
doesn't build with current sip's, due to some major changes...

As Jim already answered it'll be only a few days more...

BTW: If I have a look at the progress of KDE4 I'd say that it's still
quite more than a year until that is available in terms of a
half-stable beta... And then somebody has to take this huge job of
creating PyKDE4...

Andreas

-- 
You'll be called to a post requiring ability in handling groups of people.

___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] sender() in PyQt4 returns wrong object

2006-02-21 Thread Phil Thompson
On Tuesday 31 January 2006 11:41 pm, Andreas Pakulat wrote:
 Hi,

 I tried to use sender() in a slot connected to a signal of a QWidget
 derived class, however sender() always returns a QObject instance
 instead of the original QWidget-derived one.

 Is this by purpose and thus sender() is practically not usable in PyQt4
 or am I just missing something?

If this is still a problem can you send me a test case?

Thanks,
Phil

___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] SIP and unsigned int

2006-02-21 Thread Phil Thompson
On Tuesday 24 January 2006 4:12 pm, Ulrich Berning wrote:
 Hi,

 SIP (tested with snapshot-20060120) doesn't handle unsigned int
 correctly. SIP treats unsigned int the same as signed int and I think,
 this is wrong.
 While 4294967295 (0x) is a legal unsigned int value (on machines
 where the size of int is 32 bit of course), it is not a legal signed int
 value. The maximum legal signed int value is 2147483647 (0x7fff).

 How should I wrap a function/method, that takes/returns unsigned int's
 in the full range?
 I could replace every occurence of unsigned int with unsigned long, but
 if you are wrapping a large number of functions/methods, this is
 annoying. If you have functions/methods that take pointers to unsigned
 int, you have lost. Changing unsigned int* to unsigned long* gives me
 compiler errors.

 See the attached code:

 uinttest.h contains the definition of the class Test containing two
 member functions.
 uinttest.cpp contains the implementation
 uinttest.sip is the SIP file (look at the comments there)
 test.py is a test script

 I think unsigned int should be handled like unsigned long, but I can't
 say, if this would break existing code.

Implemented in tonight's snapshots - but untested.

Phil

___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] sender() in PyQt4 returns wrong object

2006-02-21 Thread Andreas Pakulat
On 21.02.06 15:31:29, Phil Thompson wrote:
 On Tuesday 31 January 2006 11:41 pm, Andreas Pakulat wrote:
  Hi,
 
  I tried to use sender() in a slot connected to a signal of a QWidget
  derived class, however sender() always returns a QObject instance
  instead of the original QWidget-derived one.
 
  Is this by purpose and thus sender() is practically not usable in PyQt4
  or am I just missing something?
 
 If this is still a problem can you send me a test case?

See attached file, sender() works for a QPushButton but not for the
QWidget derived class.

Andreas

-- 
Don't look now, but there is a multi-legged creature on your shoulder.
from PyQt4 import QtGui,QtCore
import sys
from PyQt4.QtCore import SIGNAL,SLOT,pyqtSignature

class widget1(QtGui.QWidget):
	def __init__(self, parent = None):
		QtGui.QWidget.__init__(self, parent)
	
	def myslot(self):
		print self.sender(), type(self.sender())

class mainwidget(QtGui.QWidget):
	def __init__(self, parent = None):
		QtGui.QWidget.__init__(self, parent)
		self.button = QtGui.QPushButton(self)
		self.button.setText(Test Signal)
		self.test = widget1(self)
		self.connect(self.button, SIGNAL(clicked()), self.on_button_clicked)
		self.connect(self, SIGNAL(test()), self.test.myslot)
	
	@pyqtSignature(on_button_clicked())
	def on_button_clicked(self):
		print self.sender(), type(self.sender())
		self.emit(SIGNAL(test()))

def main():
app = QtGui.QApplication(sys.argv)

main = mainwidget()
main.show()
return app.exec_()

if __name__ == __main__:
sys.exit(main())
___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] sender() in PyQt4 returns wrong object

2006-02-21 Thread Phil Thompson
On Tuesday 21 February 2006 4:14 pm, Andreas Pakulat wrote:
 On 21.02.06 15:31:29, Phil Thompson wrote:
  On Tuesday 31 January 2006 11:41 pm, Andreas Pakulat wrote:
   Hi,
  
   I tried to use sender() in a slot connected to a signal of a QWidget
   derived class, however sender() always returns a QObject instance
   instead of the original QWidget-derived one.
  
   Is this by purpose and thus sender() is practically not usable in PyQt4
   or am I just missing something?
 
  If this is still a problem can you send me a test case?

 See attached file, sender() works for a QPushButton but not for the
 QWidget derived class.

Thanks - fixed in tonight's snapshot.

Phil

___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


[PyKDE] noob: QtabWidget

2006-02-21 Thread Tina Isaksen

I'm still having some problems understanding the QT-assistant it seems.
I have a tab widget and need to check what tab is the active one, so I 
have tried (among other things):



def doSaveMain(self):
   if self.isTabEnabled(self.mainTabWidget  * sources):
   self.doSaveSources


mainTabWidget is of course my Qtab widget and source is the name of 
the tab.

The tab widget section of the GUI file made by pyuic is:



   self.mainTabWidget = 
QTabWidget(self.centralWidget(),mainTabWidget)

   self.mainTabWidget.setGeometry(QRect(10,40,570,120))

   self.sources = QWidget(self.mainTabWidget,sources)



But this dosen't work so it would be really helpfull if someone could 
show me how to do it right. Then I'll probably get a good clue on how to 
understand the assistant too :)


Thanks
Tina


___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] noob: QtabWidget

2006-02-21 Thread Andreas Pakulat
On 21.02.06 20:16:49, Tina Isaksen wrote:
 I'm still having some problems understanding the QT-assistant it seems.

To me it seems you have some problems translating the C++-docs to Python
;-)

 I have a tab widget and need to check what tab is the active one, so I have 
 tried (among other things):

What exactly does that mean?

 def doSaveMain(self):
if self.isTabEnabled(self.mainTabWidget  * sources):

This would call isTabEnabled on self which doesn't seems to be the
QTabWidget. Thats the first problem, now the second is: You try to
multiply the QTabWidget with the value of the variable sources. 

 mainTabWidget is of course my Qtab widget and source is the name of the 
 tab.

So you want to check wether the widget with the label source is
enabled? You could do:

if self.mainTabWidget.label(self.mainTabWidget.currentPageIndex()) == source:
  do whatever you want.

self.mainTabWidget = QTabWidget(self.centralWidget(),mainTabWidget)
self.mainTabWidget.setGeometry(QRect(10,40,570,120))
 
self.sources = QWidget(self.mainTabWidget,sources)

If self.sources points to the widget it's even easier:

if self.mainTabWidget.currentPage() == self.sources:

The Qt docs are for C++, there QWidget* w means: The variable w has
the type pointer to QWidget. So the isTabEnabled function wants a
QWidget instance as parameter and as it belongs to QTabWidget needs to
be called on a QTabWidget instance (your mainTabWidget).

HTH
Andreas Pakulat

-- 
Give thought to your reputation.  Consider changing name and moving to
a new town.

___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


[PyKDE] Special-case handling for default argument of NULL vs 0?

2006-02-21 Thread Nigel Stewart

Hi all,

We're observing some issues with methods such as:

(a)void foo(const QString * = NULL);
(b)void bar(const QString * = 0);

We're using Sip 4.3.2, it appears that Sip doesn't
support (a), PyQt 3.15.1 doesn't use (a) and the
yacc parser that sip uses is confusing NULL for
a C++ identifier that the address can be taken of:

static PyObject *meth_MyClass_foo(PyObject *sipSelf,PyObject *sipArgs)
...
const QString * a0 = NULL;   // Can't compile this!

static PyObject *meth_MyClass_bar(PyObject *sipSelf,PyObject *sipArgs)
...
const QString * a0 = NULL;

So, the lesson seems to be that = 0 is good, = NULL is
to be avoided, when it comes to sip bindings.

But, it would be nice if sip could recogise NULL as a special
case, since that is what we encourage in our C++ API, rather than
0.

Any thoughts?

Cheers,

Nigel Stewart

___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] Special-case handling for default argument of NULL vs 0?

2006-02-21 Thread Phil Thompson
On Tuesday 21 February 2006 9:14 pm, Nigel Stewart wrote:
 Hi all,

 We're observing some issues with methods such as:

 (a)void foo(const QString * = NULL);
 (b)void bar(const QString * = 0);

 We're using Sip 4.3.2, it appears that Sip doesn't
 support (a), PyQt 3.15.1 doesn't use (a) and the
 yacc parser that sip uses is confusing NULL for
 a C++ identifier that the address can be taken of:

 static PyObject *meth_MyClass_foo(PyObject *sipSelf,PyObject *sipArgs)
 ...
   const QString * a0 = NULL;   // Can't compile this!

 static PyObject *meth_MyClass_bar(PyObject *sipSelf,PyObject *sipArgs)
 ...
   const QString * a0 = NULL;

 So, the lesson seems to be that = 0 is good, = NULL is
 to be avoided, when it comes to sip bindings.

And when it comes to C++ according to Stroustrup.

 But, it would be nice if sip could recogise NULL as a special
 case, since that is what we encourage in our C++ API, rather than
 0.

 Any thoughts?

No problem with adding this.

Phil

___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] Special-case handling for default argument of NULL vs 0?

2006-02-21 Thread Nigel Stewart



We're observing some issues with methods such as:

(a)void foo(const QString * = NULL);
(b)void bar(const QString * = 0);



So, the lesson seems to be that = 0 is good, = NULL is
to be avoided, when it comes to sip bindings.


And when it comes to C++ according to Stroustrup.



No problem with adding this.


Thanks Phil, one less little gotcha to worry about
in future... :-)

Nigel

___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] noob: QtabWidget

2006-02-21 Thread Tina Isaksen

Andreas Pakulat wrote:


To me it seems you have some problems translating the C++-docs to Python
;-)
 


Very much so! I know next to nothing about C++

 

I have a tab widget and need to check what tab is the active one, so I have 
tried (among other things):
   



What exactly does that mean?
 

I have a QtabWidget with three pages (tabs) and needs to check what page 
is the active one.


 


def doSaveMain(self):
  if self.isTabEnabled(self.mainTabWidget  * sources):
   



This would call isTabEnabled on self which doesn't seems to be the
QTabWidget. Thats the first problem, now the second is: You try to
multiply the QTabWidget with the value of the variable sources. 
 

Heh... trying with the '*' was a last desperate attempt because I could 
not understand why one would need to multiply.




If self.sources points to the widget it's even easier:

if self.mainTabWidget.currentPage() == self.sources:
 

Thanks! Worked like a charm.  And what's even better; after looking it 
up in the assistant I actually understand it ;)



The Qt docs are for C++, there QWidget* w means: The variable w has
the type pointer to QWidget. So the isTabEnabled function wants a
QWidget instance as parameter and as it belongs to QTabWidget needs to
be called on a QTabWidget instance (your mainTabWidget).
 

Thanks for the explanation. I'm having a hard time catching the C++ to 
Python 'conversion' so this really helps. I really apreciate it.


Tina


___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde