Re: [PyKDE] PyQt compile problems
Hi Randall, Sometimes, it's helpful to look into the list first. Especially if someone asked for the same problem the day before! Phils answer: Upgrade to the snapshot version of PyQt or wait for PyQt v3.6. Pete On Friday 28 March 2003 05:21, Randall wrote: I'm trying to install PyQt on Gentoo, but I keep getting an error during installation. I have sip 3.5 installed and qt 3.1.2. I posted on the gentoo list and I was referred here. ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] [PATCH] new build.py options for lib64 and cat split
Hi Phil, next attempt for $subject. They're all separate lowercase options now. Let me know, if this is acceptable for you. I've thought some time on how to make the path handling simpler without loosing flexibility nor functionality, but don't wanted to risk breaking stuff in obscure environments, which I cannot test here. I think, that stability has higher priority by now shortly before the 3.6 release. This approach has the advantange to be easily adopted by current build systems, too. One possible alternative would be changing -d to specify a relative dir, e.g. site-packages, and let the new -t option specify the python base, but this leads to the afore mentioned disadvantage. The lib64 stuff is logically chacked against 64 bit package listings from SuSE. Here is something (hopefully) suitable for your ChangeLog: Added -r flag to the build system to specify the Qt library directory. This is useful for 64 bit systems, where the libs are placed in a lib64 directory. Same goes for the new -t flag, which specify the python lib directory. Both options defaults to lib in order to keep the current behaviour, and should be specified as lib64 on such systems. Added -j # flag to the build system for splitting huge modules, consisting of more then 100 single c++ modules, into # of pieces, when concatenated (-c). This is useful in SMP environments, combined with make -j #, where # should correspond. It's also useful for troubling c++ compilers, which fail on such big sources otherwise. Pete--- build.py.orig 2003-03-24 02:51:15.0 +0100 +++ build.py 2003-03-26 12:50:18.0 +0100 @@ -21,16 +21,18 @@ # Define the globals. progName = None qtDir = None qtIncDir = None +qtLibDir = lib qtVersion = 0 qtLib = None platPyScriptDir = None platPyDLLDir = None platPySiteDir = None platPyIncDir = None +platPyLibDir = lib platPyLib = None sipModuleDir = None sipIncDir = None sipBin = None sipVersion = 3 @@ -57,38 +59,42 @@ debugMode = release catCppFiles = 0 qpeTag = None licType = None gccFlags = [] +catSplit = 0 def usage(rcode = 2): Display a usage message and exit. rcode is the return code passed back to the calling process. -global progName, platBinDir, platMake, modDir, platQTDIRName, sipIncDir +global progName, platBinDir, platMake, modDir, platQTDIRName, platPyLibDir, sipIncDir, qtLibDir print Usage: -print %s [-h] [-a version] [-b dir] [-c] [-d dir] [-e dir] [-f gccflag] [-g prog] [-i dir] [-l Qt-library] [-m prog] [-n dir] [-o dir] [-p dir] [-q dir] [-s dir] [-u] [-w] % (progName) +print %s [-h] [-a version] [-b dir] [-c] [-d dir] [-e dir] [-f gccflag] [-g prog] [-i dir] [-j #] [-l Qt-library] [-m prog] [-n dir] [-o dir] [-p dir] [-q dir] [-r dir] [-s dir] [-t dir] [-u] [-w] % (progName) print where: print -h display this help message print -a tag explicitly enable the qtpe module print -b dir where pyuic and pylupdate will be installed [default %s] % (platBinDir) print -c concatenate each module's C++ source files print -d dir where PyQt will be installed [default %s] % (modDir) print -e dir the directory containing the SIP header files [default %s] % (sipIncDir) print -f gccflag additional GCC flag, eg. -fno-exceptions print -g progthe name of the Makefile generator print -i dir the directory containing the Qt header files [default %s%sinclude] % (platQTDIRName,os.sep) +print -j # split huge concatenated modules in # pieces print -l Qt-library explicitly specify the type of Qt library, either qt, qt-mt or qte print -m progthe name of the Make program [default %s] % (platMake) print -n dir the directory containing the QScintilla header files [default %s%sinclude] % (platQTDIRName, os.sep) print -o dir the directory containing the QScintilla library [default %s%slib] % (platQTDIRName, os.sep) print -p dir the name of the SIP code generator [default sip] print -q dir the Qt base directory [default %s] % (platQTDIRName) +print -r dir the Qt lib directory [default %s] % (qtLibDir) print -s dir the directory containing the SIP module +print -t dir Python lib directory [default %s] % (platPyLibDir) print -u build with debugging symbols print -w enable the use of Python 1.5.x under Windows sys.exit(rcode) @@ -152,12 +158,12 @@ def initGlobals(): Sets the values of globals that need more than a simple assignment. global platMake, platCopy, platPyScriptDir, platPyDLLDir, platPySiteDir -global platPyIncDir, platPyLib, platQTDIRName, platBinDir, platMkdir -global platRmdir, modDir, pyFullVers, pyVersNr, sipIncDir +global
Re: [PyKDE] [PATCH] new build.py options for lib64 and cat split
On Wednesday 26 March 2003 14:59, Phil Thompson wrote: Sorry, I think you've misunderstood. The -r flag should define the full path of the Qt library directory - not just a component of it - like the -i flag for the header files. This is more flexible because it allows any arbitary directory to be specified. Same for -t - or does the -d flag already do it? Phil I understood your concerns, but hesitated to make such deep changes. Attached is what you asked for ;-) Hopefully all is well, especially the win32 changes, which I haven't tested. Here is something (hopefully) suitable for the ChangeLog: Added -r flag to the build system to explicitly specify the Qt library directory. This is useful for 64 bit systems, where the libs are placed in $QTDIR/lib64, unlike the default $QTDIR/lib. Same goes for the new -t flag, which specify the python base directory, which is /usr/lib64/python#.# on such systems. This option takes priority over -d. For concatenated builds (-c), a -j # flag was added to the build system for splitting huge modules, consisting of more then 100 single c++ modules, into # of pieces. This is useful in SMP environments, combined with make -j #, where # should correspond, to saturate the CPUs. It's also helpful for troubling c++ compilers and memory constraint systems, which may fail on such big sources otherwise. Pete--- build.py.orig 2003-03-24 02:51:15.0 +0100 +++ build.py 2003-03-26 16:34:09.0 +0100 @@ -21,12 +21,14 @@ # Define the globals. progName = None qtDir = None qtIncDir = None +qtLibDir = None qtVersion = 0 qtLib = None +platPyBaseDir = None platPyScriptDir = None platPyDLLDir = None platPySiteDir = None platPyIncDir = None platPyLib = None @@ -57,38 +59,42 @@ debugMode = release catCppFiles = 0 qpeTag = None licType = None gccFlags = [] +catSplit = 0 def usage(rcode = 2): Display a usage message and exit. rcode is the return code passed back to the calling process. -global progName, platBinDir, platMake, modDir, platQTDIRName, sipIncDir +global progName, platBinDir, platMake, modDir, platQTDIRName, platPyBaseDir, sipIncDir print Usage: -print %s [-h] [-a version] [-b dir] [-c] [-d dir] [-e dir] [-f gccflag] [-g prog] [-i dir] [-l Qt-library] [-m prog] [-n dir] [-o dir] [-p dir] [-q dir] [-s dir] [-u] [-w] % (progName) +print %s [-h] [-a version] [-b dir] [-c] [-d dir] [-e dir] [-f gccflag] [-g prog] [-i dir] [-j #] [-l Qt-library] [-m prog] [-n dir] [-o dir] [-p dir] [-q dir] [-r dir] [-s dir] [-t dir] [-u] [-w] % (progName) print where: print -h display this help message print -a tag explicitly enable the qtpe module print -b dir where pyuic and pylupdate will be installed [default %s] % (platBinDir) print -c concatenate each module's C++ source files print -d dir where PyQt will be installed [default %s] % (modDir) print -e dir the directory containing the SIP header files [default %s] % (sipIncDir) print -f gccflag additional GCC flag, eg. -fno-exceptions print -g progthe name of the Makefile generator print -i dir the directory containing the Qt header files [default %s%sinclude] % (platQTDIRName,os.sep) +print -j # split huge concatenated modules in # pieces print -l Qt-library explicitly specify the type of Qt library, either qt, qt-mt or qte print -m progthe name of the Make program [default %s] % (platMake) print -n dir the directory containing the QScintilla header files [default %s%sinclude] % (platQTDIRName, os.sep) print -o dir the directory containing the QScintilla library [default %s%slib] % (platQTDIRName, os.sep) print -p dir the name of the SIP code generator [default sip] print -q dir the Qt base directory [default %s] % (platQTDIRName) +print -r dir the Qt lib directory [default %s%slib] % (platQTDIRName, os.sep) print -s dir the directory containing the SIP module +print -t dir Python base directory [default %s] % (platPyBaseDir) print -u build with debugging symbols print -w enable the use of Python 1.5.x under Windows sys.exit(rcode) @@ -151,11 +157,11 @@ def initGlobals(): Sets the values of globals that need more than a simple assignment. -global platMake, platCopy, platPyScriptDir, platPyDLLDir, platPySiteDir +global platMake, platCopy, platPyBaseDir, platPyScriptDir, platPyDLLDir, platPySiteDir global platPyIncDir, platPyLib, platQTDIRName, platBinDir, platMkdir global platRmdir, modDir, pyFullVers, pyVersNr, sipIncDir pyFullVers = string.split(sys.version)[0] @@ -169,35 +175,39 @@ if sys.platform == win32: platMake = nmake
[PyKDE] [PATCH] PyQt build.py option for lib dir
Hi Phil, the attached patch is meant to obsolete an ugly hack found in SuSE rpm specs to support 64 bit architectures. They simply patch the offending pathes, which will break often. Therefore I've added a new command line option (-L dir), to specify the lib base directory, which defaults to lib. Hopefully, by using -L lib64, build.py is able to build on such archs, but unfortunately I cannot test it, since I don't have access to such a system by now. If you're going to accept it, I will create a similar patch for sip, too. Thanks, Pete--- build.py.orig 2003-03-24 02:51:15.0 +0100 +++ build.py 2003-03-24 03:35:04.0 +0100 @@ -57,21 +57,22 @@ debugMode = release catCppFiles = 0 qpeTag = None licType = None gccFlags = [] +libDir = lib def usage(rcode = 2): Display a usage message and exit. rcode is the return code passed back to the calling process. -global progName, platBinDir, platMake, modDir, platQTDIRName, sipIncDir +global progName, platBinDir, platMake, modDir, platQTDIRName, sipIncDir, libDir print Usage: -print %s [-h] [-a version] [-b dir] [-c] [-d dir] [-e dir] [-f gccflag] [-g prog] [-i dir] [-l Qt-library] [-m prog] [-n dir] [-o dir] [-p dir] [-q dir] [-s dir] [-u] [-w] % (progName) +print %s [-h] [-a version] [-b dir] [-c] [-d dir] [-e dir] [-f gccflag] [-g prog] [-i dir] [-l Qt-library] [-L lib-base-dir] [-m prog] [-n dir] [-o dir] [-p dir] [-q dir] [-s dir] [-u] [-w] % (progName) print where: print -h display this help message print -a tag explicitly enable the qtpe module print -b dir where pyuic and pylupdate will be installed [default %s] % (platBinDir) print -c concatenate each module's C++ source files @@ -79,10 +80,11 @@ print -e dir the directory containing the SIP header files [default %s] % (sipIncDir) print -f gccflag additional GCC flag, eg. -fno-exceptions print -g progthe name of the Makefile generator print -i dir the directory containing the Qt header files [default %s%sinclude] % (platQTDIRName,os.sep) print -l Qt-library explicitly specify the type of Qt library, either qt, qt-mt or qte +print -L dir Python and Qt lib base directory [default %s] % (libDir) print -m progthe name of the Make program [default %s] % (platMake) print -n dir the directory containing the QScintilla header files [default %s%sinclude] % (platQTDIRName, os.sep) print -o dir the directory containing the QScintilla library [default %s%slib] % (platQTDIRName, os.sep) print -p dir the name of the SIP code generator [default sip] print -q dir the Qt base directory [default %s] % (platQTDIRName) @@ -153,11 +155,11 @@ def initGlobals(): Sets the values of globals that need more than a simple assignment. global platMake, platCopy, platPyScriptDir, platPyDLLDir, platPySiteDir global platPyIncDir, platPyLib, platQTDIRName, platBinDir, platMkdir -global platRmdir, modDir, pyFullVers, pyVersNr, sipIncDir +global platRmdir, modDir, pyFullVers, pyVersNr, sipIncDir, libDir pyFullVers = string.split(sys.version)[0] vl = string.split(re.findall([0-9.]*,pyFullVers)[0],.) major = vl[0] @@ -187,17 +189,18 @@ else: platMake = make platCopy = cp platMkdir = mkdir platRmdir = rm -rf -platPyScriptDir = sys.prefix + /lib/python + pyVers -platPyDLLDir = sys.prefix + /lib/python + pyVers + /lib-dynload +pylib = sys.prefix + / + libDir + /python + pyVers +platPyScriptDir = pylib +platPyDLLDir = pylib + /lib-dynload if pyVersNr 20: -platPySiteDir = sys.prefix + /lib/python + pyVers +platPySiteDir = pylib else: -platPySiteDir = sys.prefix + /lib/python + pyVers + /site-packages +platPySiteDir = pylib + /site-packages platPyIncDir = sys.prefix + /include/python + pyVers platQTDIRName = $QTDIR platBinDir = /usr/local/bin @@ -566,13 +569,13 @@ def checkQtLibrary(): Check which Qt library is to be used. -global qtDir, qtLib +global qtDir, qtLib, libDir -qtlibdir = qtDir + os.sep + lib +qtlibdir = qtDir + os.sep + libDir if qtLib is None: mtlib = isQtLibrary(qtlibdir,qt-mt) stlib = isQtLibrary(qtlibdir,qt) emlib = isQtLibrary(qtlibdir,qte) @@ -765,13 +768,13 @@ f.close() # Check the SIP module can be found. if sipModuleDir is None: - global platPyScriptDir, platPyDLLDir, platPySiteDir +global platPyScriptDir, platPyDLLDir, platPySiteDir - dirlist = [platPyDLLDir, platPyScriptDir, platPySiteDir] +dirlist = [platPyDLLDir, platPyScriptDir, platPySiteDir] else:
[PyKDE] [PATCH] reduce PyQt concatenated build time on SMP
Hi Phil, in order to saturate multiple CPUs on SMP systems, I've created the attached patch. The problem is, that the qt module consists of 228 single modules, and build of its concatenated module outlasts all others by a few minutes here. With it applied, I was able to reduce the rpm build time from 16:15 to 13.30 on my Dual P3/1000. Since it is created on top of my former patch, it will apply with offsets, if applied first. Thanks, Pete--- build.py.new 2003-03-24 11:40:11.0 +0100 +++ build.py 2003-03-24 12:11:55.0 +0100 @@ -1282,23 +1282,42 @@ srclist = buf[match.start(0):match.end(0)] srclist = srclist[13:-1] srclist = string.replace(srclist,\\\n\t,) srclist = string.split(srclist, ) +if len(srclist) 100: +# special case for huge modules: create two modules + +h = len(srclist)/2 +# Concatenate the files. +d = open(mname + huge2.cpp,w) + +for cppfile in srclist[:h]: +f = open(cppfile,r) +d.write(f.read()) +f.close() + +d.close() + +srclist = srclist[h:] + +# Replace the C++ file names in the project file. +buf = re.sub(pat,SOURCES = + mname + huge2.cpp + mname + huge.cpp\n,buf) +else: +# Replace the C++ file names in the project file. +buf = re.sub(pat,SOURCES = + mname + huge.cpp\n,buf) + # Concatenate the files. d = open(mname + huge.cpp,w) for cppfile in srclist: f = open(cppfile,r) d.write(f.read()) f.close() d.close() -# Replace the C++ file names in the project file. -buf = re.sub(pat,SOURCES = + mname + huge.cpp\n,buf) - f = open(pro + .new,w) f.write(buf) f.close() os.remove(pro)
Re: [PyKDE] [PATCH] reduce PyQt concatenated build time on SMP
On Monday 24 March 2003 13:05, Phil Thompson wrote: On Monday 24 March 2003 11:53 am, Hans-Peter Jansen wrote: Hi Phil, in order to saturate multiple CPUs on SMP systems, I've created the attached patch. The problem is, that the qt module consists of 228 single modules, and build of its concatenated module outlasts all others by a few minutes here. With it applied, I was able to reduce the rpm build time from 16:15 to 13.30 on my Dual P3/1000. Since it is created on top of my former patch, it will apply with offsets, if applied first. But doesn't this slow it down for everybody with a UP machine? Phil Well, yes, I have to admit. But the performance hit is less then the improvement, aka 19:53 - 21:29 UP, AMD 2000+ (~8%), 16:15 - 13:30 (~20%). Would you accept a combined cleaned up patch with different lower case options for this and the lib stuff? Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] [PATCH] reduce PyQt concatenated build time on SMP
On Monday 24 March 2003 15:58, Phil Thompson wrote: On Monday 24 March 2003 2:50 pm, Gerard Vermeulen wrote: If you are proposing this, why don't you generalize and code something like the -j switch (parallel build switch) for make. In this case there is no penalty for UP machines (by default one single huge.cpp), and the guys with 4 processors will feel happy, too :-) Yes - I'd be happy with this. It also helps those compilers (aka MSVC) that choke on such a large C++ file but would probably handle... python build.py -c -j 10 One remark: the semantics will differ: while make -j 10 would run 10 build processes in parallel, this command should split large modules into 10 pieces. Is this fine with you? Phil Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Hello and PyKDE for KDE 3.1
Hi Ralph, welcome in this beautiful niche. On Tuesday 18 March 2003 21:47, Ralph Kaiser wrote: Hi Pete, Try this: ftp://ftp.kde.org/pub/kde/unstable/apps/KDE3.x/utils/PyKDE-3.3.2-rha3.1.tar .bz2 Yup, found it, but failed to build it, because it looks like KDE 3.1.1 is a lot more different to 3.1.0 than I've expected. See my next mail, if you like. And while I'm here I'd like to thank you for your excellent SQL tutorial that is included in the PyQT distribution. It made it quite easy (and fun) for this newbie to get started. Thanks a lot. I hoped, someone will find it useful. I plan to write some articles in german journals about PyQt and friends. Peace, Ralph Far-to-many-weapons-in-circulation-to-make-this-happen-soon-ly y'rs, Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] Problems with PyKDE 3.3.2 on KDE 3.1.1
Hi Jim and friends,
motivated by Roberto, I tried to build KyKDE 3.3.2 on top of KDE 3.1.1,
but failed so far. Robertos version fails in exactly the same way, but
it's hard to say what Roberto has changed without a proper context diff
hint, hint.
The problem boils down to the now private nature of some ctors/dtors
in a few KIO classes. I examined the first one: KService(const KService),
which is used at least in syentrylist.sip and svctypes.sip for some type
conversations.
kservice.h:
class KService : public KSycocaEntry
{
K_SYCOCATYPE( KST_KService, KSycocaEntry )
KService(const KService);
Unfortunately I have not enough insight in the inwards of KDE to rewrite
those by now.
Attached is a patch of what I've done so far. Additionally, I've created
a few symlinks in my RPM spec, as always:
cd extraH
ln -s kde303 kde304
ln -s kde303 kde305
ln -s kde303 kde311
cd ..
cd sip
ln -s kde30 kde31
cd ..
Here is the full error log [Sorry for the long lines]:
make[1]: Entering directory `/usr/src/packages/BUILD/PyKDE-3.3.2/kio'
g++ -c -pipe -w -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -fPIC -DNO_DEBUG
-D_REENTRANT -fPIC -DSIP_MAKE_MODULE_
DLL -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -fno-exceptions -I/usr/lib/qt3/mkspecs/default
-I. -I-I -I../extraH -I. -I../..
/../../../include/python2.2 -I/opt/kde3/include -I-I -I/opt/kde3/include/kio -I-I
-I../kdecore -I../../../../../inclu
de -I/usr/lib/qt3/include -o kiohuge.o kiohuge.cpp
/opt/kde3/include/kservice.h: In function `PyObject* sipConvertFrom_SvcList(SvcList*)':
/opt/kde3/include/kservice.h:47: error: `KService::KService(const KService)' is
private
sip/svctypes.sip:175: error: within this context
/opt/kde3/include/kservice.h: In constructor `sipKService::sipKService(const
KService)':
/opt/kde3/include/kservice.h:47: error: `KService::KService(const KService)' is
private
sipkioKShellCompletion.cpp:1861: error: within this context
/opt/kde3/include/kautomount.h: In constructor `sipKAutoUnmount::sipKAutoUnmount(const
QString, const QString)':
/opt/kde3/include/kautomount.h:108: error: `KAutoUnmount::~KAutoUnmount()' is private
sipkioKDataTool.cpp:733: error: within this context
/opt/kde3/include/kautomount.h: In destructor `virtual
sipKAutoUnmount::~sipKAutoUnmount()':
/opt/kde3/include/kautomount.h:108: error: `KAutoUnmount::~KAutoUnmount()' is private
sipkioKDataTool.cpp:738: error: within this context
/opt/kde3/include/kautomount.h: In function `void
sipDealloc_KAutoUnmount(sipThisType*)':
/opt/kde3/include/kautomount.h:108: error: `virtual KAutoUnmount::~KAutoUnmount()' is
private
sipkioKAutoUnmount.cpp:435: error: within this context
/opt/kde3/include/kautomount.h: In function `PyObject* sipNew_KAutoUnmount(PyObject*,
PyObject*)':
/opt/kde3/include/kautomount.h:108: error: `virtual KAutoUnmount::~KAutoUnmount()' is
private
sipkioKAutoUnmount.cpp:499: error: within this context
/opt/kde3/include/kautomount.h: In constructor `sipKAutoMount::sipKAutoMount(bool,
const QString, const QString, co
nst QString, const QString, bool)':
/opt/kde3/include/kautomount.h:70: error: `KAutoMount::~KAutoMount()' is private
sipkioKAutoUnmount.cpp:607: error: within this context
/opt/kde3/include/kautomount.h: In destructor `virtual
sipKAutoMount::~sipKAutoMount()':
/opt/kde3/include/kautomount.h:70: error: `KAutoMount::~KAutoMount()' is private
sipkioKAutoUnmount.cpp:612: error: within this context
/opt/kde3/include/kautomount.h: In function `void sipDealloc_KAutoMount(sipThisType*)':
/opt/kde3/include/kautomount.h:70: error: `virtual KAutoMount::~KAutoMount()' is
private
sipkioKAutoMount.cpp:435: error: within this context
/opt/kde3/include/kautomount.h: In function `PyObject* sipNew_KAutoMount(PyObject*,
PyObject*)':
/opt/kde3/include/kautomount.h:70: error: `virtual KAutoMount::~KAutoMount()' is
private
sipkioKAutoMount.cpp:511: error: within this context
sipkioKIOMultiGetJob.cpp: In member function `void
sipKIO_DeleteJob::sipProtect_startNextJob()':
sipkioKIOMultiGetJob.cpp:2516: error: 'class KIO::DeleteJob' has no member named
'startNextJob'
/opt/kde3/include/kio/jobclasses.h: In member function `void
sipKIO_DeleteJob::sipProtect_deleteNextFile()':
/opt/kde3/include/kio/jobclasses.h:1067: error: `void
KIO::DeleteJob::deleteNextFile()' is private
sipkioKIOMultiGetJob.cpp:2521: error: within this context
/opt/kde3/include/kio/jobclasses.h: In member function `void
sipKIO_DeleteJob::sipProtect_deleteNextDir()':
/opt/kde3/include/kio/jobclasses.h:1068: error: `void KIO::DeleteJob::deleteNextDir()'
is private
sipkioKIOMultiGetJob.cpp:2526: error: within this context
make[1]: *** [kiohuge.o] Fehler 1
make[1]: Leaving directory `/usr/src/packages/BUILD/PyKDE-3.3.2/kio'
make: *** [sub-kio] Fehler 2
Looks like It's time to wait for your new version, but I will happily
take advises on how to preceed.
Bye,
Petediff -u5 -uNrx '*.[ao]' -x '*~' -x '*,v' -x '*.orig' -x '*.rej' -x tags -x '*.swp' -x '*.new' PyKDE-3.3.2/build.py PyKDE-3.3.2-hp/build.py
Re: [PyKDE] KIO::DeleteJob
On Wednesday 19 March 2003 12:45, Roberto H. Alsina wrote: Ahem, I sent a mail saying things like KIO::DeleteJob is deprecated. Sorry, it's 8AM and I just woke up, and that is completely wrong ;-) So you mean: -ENOCAFFEINE No problem, build is running now with your headers and sips, let's see how far it gets... Jim, it would love to see your next version Makefiles working with export MAKEFLAGS=-j2 Currently, they fail because of missing dependencies between some targets. Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Problems with PyKDE 3.3.2 on KDE 3.1.1
Follow up with Robertos headers/sips: Since Roberto switched off kautomount completely, the problem is reduced to the private KService::KService(const KService). Please can you check, if this is also the case for KDE 3.1.0? g++ -c -pipe -w -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -fPIC -DNO_DEBUG -D_REENTRANT -fPIC -DSIP_MAKE_MODULE_DLL -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -fno-exceptions -I/usr/lib/qt3/mkspecs/default -I. -I-I -I../extraH -I. -I../../../../../include/python2.2 -I/opt/kde3/include -I-I -I/opt/kde3/include/kio -I-I -I../kdecore -I../../../../../include -I/usr/lib/qt3/include -o kiohuge.o kiohuge.cpp /opt/kde3/include/kservice.h: In function `PyObject* sipConvertFrom_SycocaEntryList(SycocaEntryList*)': /opt/kde3/include/kservice.h:47: error: `KService::KService(const KService)' is private sip/syentrylist.sip:60: error: within this context /opt/kde3/include/kservice.h: In function `PyObject* sipConvertFrom_SvcList(SvcList*)': /opt/kde3/include/kservice.h:47: error: `KService::KService(const KService)' is private sip/svctypes.sip:175: error: within this context /opt/kde3/include/kservice.h: In constructor `sipKService::sipKService(const KService)': /opt/kde3/include/kservice.h:47: error: `KService::KService(const KService)' is private sipkioKShellCompletion.cpp:1861: error: within this context I've tried to switch off the kio module, but then kfile cannot be built... BTW: The KDE 3.1.1 is what I have found on SuSEs 8.2 beta 3, their latest release for us beta testers. Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Editable QComboBox in QTable problem ?
Hi David, please have a look into the smalltable.py example, and you will see, what's wrong. Also reading the docs for QTableItem will help you here. Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Editable QComboBox in QTable problem ?
On Wednesday 19 March 2003 17:20, david wrote: Le mer 19/03/2003 à 15:13, Hans-Peter Jansen a écrit : Hi David, please have a look into the smalltable.py example, and you will see, what's wrong. Also reading the docs for QTableItem will help you here. Pete Hello Pete, Thank you for your help. I looked smalltable.py, it's an example for Qt 3.x, with Qt 2.x, there isn't QComboTableItem(). Oups. My fault. Sorry, but Qt2 was before my PyQt era started. With Qt 2.x, I haven't other solution that using setCellWidget(). True or wrong ? Don't know. See above. button, checkBox, comboBox works fine with setCellWidget() but with editable comboBox, when I'm writing, I lose my focus. any ideas ? Does Qt2 has an QTableItem you can subclass from? Testing your example here with Qt3 made the QCombo disappear as soon as I entered some text in this field, independant from, how is was instanced, BTW. Thanks Pete. You're welcome. Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Hello and PyKDE for KDE 3.1
On Tuesday 18 March 2003 02:05, Roberto H. Alsina wrote: First: hello, and congrats on the amazing software :-) Welcome to the club Second, Since I needed to use KHTML on a app I am writing, and also wanted it to work on KDE 3.1, I made a quick hack of PyKDE-3.3.2 to make it work under KDE 3.1. This is just intended as a stopgap thing until the real thing comes out, and to let any KDE 3.0 PyKDE apps work on KDE 3.1 (since the API is exactly the same). If anyone wants it, it still seems to be stuck in ftp://upload.kde.org Sounds interesting, but it seems to be moved somewhere... Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] PyQt QScintilla Status
On Sunday 16 March 2003 17:33, Phil Thompson wrote: FYI... Tonight's snapshots of SIP, PyQt and QScintilla should be treated as release candidates for SIP 3.6, PyQt 3.6 and QScintilla 1.0. I plan to release the final versions as soon as Python 2.3 is released. Now is the time to test if you want the next release to work for you. FYI: I've build and lightly tested those snapshots on SuSE 8.1 and SuSE 8.2 beta 3 (unlike stated before: Qt 3.1.1, KDE 3.1.1, gcc 3.3, python 2.2.2) without problems so far. I'm happily awaiting the release now. Phil Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] PyQt QScintilla Status
Hi Phil, I just built qscintilla snapshot 20030314, sip snapshot 20030312, and PyQt snapshot 20030314 on SuSE 8.1 and 8.2 (Beta 3: Qt 3.1, KDE 3.1, gcc 3.3, python 2.2.2) without problems. At least eric 3.1 runs on top of it... Well done, man. Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] qscintilla fix
Hi Phil,
in order to build this snapshot, I've needed an additional patch,
because this error:
g++ -c -pipe -w -O2 -march=i586 -mcpu=i686 -fno-exceptions -fmessage-length=0
-DNO_DEBUG -D_REENTRANT -fPIC -DQEXTSCINTILLA_MAKE_DLL -DQT -DSCI_LEXER
-DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I. -I../include -I../src
-I/usr/lib/qt3/include -I/usr/lib/qt3/mkspecs/default -o PlatQt.o PlatQt.cxx
PlatQt.cxx: In static member function `static int
Platform::DBCSCharLength(int, const char*)':
PlatQt.cxx:762: `MB_CUR_MAX' undeclared (first use this function)
PlatQt.cxx:762: (Each undeclared identifier is reported only once for each
function it appears in.)
PlatQt.cxx:762: `mblen' undeclared (first use this function)
make: *** [PlatQt.o] Fehler 1
MB_CUR_MAX is defined in stdlib.h here (still SuSE 8.1), which is not listed
in the includes of PlatQt.cxx. Patch attached.
Gerard, thanks for digging into the glitch below. Obviously I needed
your patch, too ;-) Hopefully it does the right thing, too...
BTW, did you advanced in the setup.py/pyqt_support.py tidy up?
Bye,
Pete
On Saturday 01 March 2003 09:58, [EMAIL PROTECTED] wrote:
Phil,
Compiling qscintilla-*-20030227 with Qt-3.0.5 gives the following error:
packer:~/BLFS/bld/qscintilla-1.51-x11-gpl-snapshot-20030227/qt$ make
g++ -c -pipe -w -O2 -D_REENTRANT -fPIC -DQEXTSCINTILLA_MAKE_DLL -DQT
-DSCI_LEXER -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I. -I../include -I../src
-I/usr/lib/qt3/include -I/usr/lib/qt3/mkspecs/default -o SciListBox.o
SciListBox.cxx SciListBox.cxx: In method `int ListBoxX::GetSelection()':
SciListBox.cxx:180: no matching function for call to
`SciListBox::selectedItem ()' make: *** [SciListBox.o] Error 1
packer:~/BLFS/bld/qscintilla-1.51-x11-gpl-snapshot-20030227/qt$
Grepping for selectedItem gives:
packer:~/BLFS/bin$ grep selectedItem /usr/lib/qt3/include/*.h
/usr/lib/qt3/include/qlistview.h:QListViewItem * selectedItem() const;
packer:~/BLFS/bin$
And looking for the base classes of QListBox, gives:
packer:~/BLFS/bin$ grep -3 'QListBox :' /usr/lib/qt3/include/qlistbox.h
class QStringList;
class Q_EXPORT QListBox : public QScrollView
{
friend class QListBoxItem;
friend class QListBoxPrivate;
packer:~/BLFS/bin$
Attached patch fixes the compiler error (I hope it does what you mean)
Gerard
--- qscintilla-1.51-x11-gpl-snapshot-20030227/qt/PlatQt.cxx~ 2003-02-28 02:04:15.0 +0100
+++ qscintilla-1.51-x11-gpl-snapshot-20030227/qt/PlatQt.cxx 2003-03-01 15:20:39.0 +0100
-21,10 +21,11
#include stdio.h
#include stdarg.h
#include string.h
+#include stdlib.h
#include qapplication.h
#include qwidget.h
#include qfont.h
#include qpixmap.h
Re: [PyKDE] qscintilla fix - pyqt_distutils
Hi Gerard, you may have noticed, that I've announced among others things your current PyQwt package. Since I'm a bit tight timewise at the moment (because my girlfriend :), just let me attest, your package builds without a hitch! Therefore I haven't even needed to take a single look into it, thus your rewritten pyqt_* stuff gone by unnoticed ;-) Will do it soon. (For my vindication, this was after my qscintilla build note). Thanks, Pete On Saturday 01 March 2003 17:25, [EMAIL PROTECTED] wrote: Hi Pete, BTW, did you advanced in the setup.py/pyqt_support.py tidy up? Yes, I did and tested it in an already abandoned project: a PyQt wrapper for a Qt-C++ class for VTK (a 3D visualization toolkit). The project was motivated by the fact that the PyQt widgets included with VTK did not work on Windows. In the end, I got into fixing the pure Python PyQt widgets that come with VTK (they are now in the VTK cvs -- a new release VTK-4.2 is imminent). The most interesting widget -- QVTKRenderWindowInteractor.py -- is also available from my web page ( http://gerard.vermeulen.free.fr ). A happy user, who discovered it by accident, reports that it works, but that it needs a little bit of tweaking. QVTKRenderWindowInteractor is compatible with VTK-4.0. The new setup.py/pyqt_support.py will be part of a new PyQwt release. Actually, pyqt_support.py will be replaced by a pyqt_distutils directory, writing a setup.py script will be much simpler, and recompiling minimized (for my own sake). Really cool news. Gerard ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] GUI Programming with Python: QT Edition (was: dialog/mainwindow question)
On Friday 21 February 2003 14:17, Gerard Breiner wrote: Hello, I know this book since yesterday. I found it at http://www.xs4all.nl/~bsarempt/python/tutorial.html and i download it from opendoc. I was surprised to note that the price at opendoc is 49.95 $ whereas in Paris at Le monde en tique the price is 113 ? as about 113 $ I phoned to Le monde en tique, the salesman said the difference in price corresponds to the transport charges of DHL. Do you have another solution to buy this book. While waiting I have the book in form pdf and I printed it too. I think indeed the writing style is very good and the Introduction to Python is good in my case because i have read the tutorial. I like this book. Best greetings Gerard Breiner Institut D'Astrophysique Spatiale Orsay FRANCE Hi Gerard, your bookstore is ridiculous. I bought mine at Lehmann's Fachbuchhandlung here in Berlin for 58.75¤ last summer (when the euro exchange rate was much worser than now, but with an US price of $49.95). IIRC, it took them about 4 weeks for my order and sadfully, they still have at least one copy from that order of 5 (I've spend 100¤ there today [LDAP/OpenSSL/Linux Journal])... Cheers, Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] QThreads
On Wednesday 19 February 2003 21:36, Stuart Bronk wrote: Hi, I'm trying to find a little example app using Qthreads, before I use them for more complex matters. I've search all over the place but can't seem to find one. I don't suppose anyone has a small program or knows where I can find an example? You may have missed examples3/semaphore.py... Hth, Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] QWidgetFactory support
Hi Phil, attached is an implementation of QWidgetFactory based on the PyQt snapshot from 25.01. Since it's my first PyQt module, it would be nice, if you take a look over it, especially into the sip files. Any Transfer* magic missing? The win parts of quimod.sip are definitely wrong, but I don't know better, yet. At least, QWidgetFactory.create(some.ui) seems to work fine on linux. I've kept your copyright, but added myself to it. I hope, this is fine with you. Pete --- build.py.orig 2003-01-26 02:03:04.0 +0100 +++ build.py 2003-01-30 17:58:49.0 +0100 @@ -345,19 +345,20 @@ TARGET = qttest CONFIG = qt @TEST_OPENGL@ console warn_off release @BL_THREAD@ INCLUDEPATH = . @BL_INCLUDEPATH@ DEFINES = @BL_DEFINES@ SOURCES = qttest.cpp -LIBS += @TEST_SCILIBDIR@ +LIBS += @TEST_SCILIBDIR@ @TEST_QUILIBDIR@ win32:LIBS += @BL_PYLIB@ ) -# Disable OpenGL and QScintilla support by default. +# Disable OpenGL, QScintilla and Qui support by default. global proPatches proPatches[TOPENGL] = [re.compile(@TEST_OPENGL@,re.M), ] proPatches[TSCILIBDIR] = [re.compile(@TEST_SCILIBDIR@,re.M), ] +proPatches[TQUILIBDIR] = [re.compile(@TEST_QUILIBDIR@,re.M), ] # Create a dummy source file to suppress a qmake warning. copyToFile(qttest.cpp,) buildMakefile(qttest.pro) @@ -978,10 +979,22 @@ # Put things back. proPatches[TSCILIBDIR] = [re.compile(@TEST_SCILIBDIR@,re.M), ] buildMakefile(qttest.pro) +if qtVersion = 0x03: +quilib = +if sys.platform == win32: +quilib = qui.lib +else: +quilib = -lqui +proPatches[TQUILIBDIR] = [re.compile(@TEST_QUILIBDIR@,re.M), quilib] +buildMakefile(qttest.pro) +tryModule(qui, qwidgetfactory.h, QWidgetFactory()) +# Put things back. +proPatches[TQUILIBDIR] = [re.compile(@TEST_QUILIBDIR@,re.M), ] +buildMakefile(qttest.pro) def generateFeatures(featfile): Generate the header file describing the Qt features that are enabled if it doesn't already exist. (If it already exists then we are probably cross // This is the SIP interface definition for the qui module of PyQt. // // Copyright (c) 2003 // Hans-Peter Jansen [EMAIL PROTECTED] // Riverbank Computing Limited [EMAIL PROTECTED] // // This file is part of PyQt. // // This copy of PyQt is free software; you can redistribute it and/or modify it // under the terms of the GNU General Public License as published by the Free // Software Foundation; either version 2, or (at your option) any later // version. // // PyQt is supplied in the hope that it will be useful, but WITHOUT ANY // WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS // FOR A PARTICULAR PURPOSE. See the GNU General Public License for more // details. // // You should have received a copy of the GNU General Public License along with // PyQt; see the file LICENSE. If not, write to the Free Software Foundation, // Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. %Module qui 0 %Import qtmod.sip %Include copying.sip %Include qwidgetfactory.sip // The project file template. %Makefile qui.pro # The project file for the qui module. # # Copyright (c) 2003 # Riverbank Computing Limited [EMAIL PROTECTED] # # This file is part of PyQt. # # This copy of PyQt is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by the Free # Software Foundation; either version 2, or (at your option) any later # version. # # PyQt is supplied in the hope that it will be useful, but WITHOUT ANY # WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS # FOR A PARTICULAR PURPOSE. See the GNU General Public License for more # details. # # You should have received a copy of the GNU General Public License along with # PyQt; see the file LICENSE. If not, write to the Free Software Foundation, # Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. TEMPLATE = lib TARGET = @BL_TARGET@ DESTDIR = @BL_DESTDIR@ CONFIG += qt warn_off @BL_DEBUG@ @BL_SIP@ @BL_DLL@ @BL_THREAD@ INCLUDEPATH = . ../qt @BL_INCLUDEPATH@ DEFINES = SIP_MAKE_MODULE_DLL @BL_DEFINES@ sip3:unix:LIBS += -L@BL_DESTDIR@ -lqtcmodule -L@BL_SIPMODDIR@ -lsip -lqui sip3:win32:LIBS += @BL_DESTDIR@\libqtc.lib @BL_SIPMODDIR@\libsip.lib @BL_PYLIB@ @BL_QUILIBDIR@\qui.lib sip4:unix:LIBS += -lqui sip4:win32:LIBS += @BL_PYLIB@ @BL_QUILIBDIR@\qui.lib SOURCES = \ $B HEADERS = \ $H %End // This is the SIP interface definition for QWidgetFactory. // // Copyright (c) 2003 // Hans-Peter Jansen [EMAIL PROTECTED] // Riverbank Computing Limited [EMAIL PROTECTED] // // This file is part of PyQt. // // This copy of PyQt is free software; you can redistribute it and/or modify it // under the terms of the GNU
Re: [PyKDE] Now tackle dtor strangeness
On Sunday 26 January 2003 01:16, Phil Thompson wrote: Funny side note: it was enough to fix one of both sub classes this way to prevent attribute errors here. This is pretty undeterministic, and that's exactly the reason, why I don't like this behaviour... Phil, one would expect, that as long as a class exists, its baseclass should exist, either. The same goes for globals in module scope. The class will exist (because the sub-class keeps a reference to it) but that doesn't mean that the reference to the class in (for example) the module's dictionary still exists. The problem is that the order in which a dictionary's elements are deleted isn't very deterministic. In your example qEventDict is being removed from the module dictionary before the qEvent function is removed. By moving qEventDict into the qEvent function you guarantee it will exist whenever qEvent is called. I would guess that the problem would also go away if you played with the names of qEvent and qEventDict so that they had hash values that caused them to appear in the module dictionary in the opposite order so that qEvent was deleted first. I wasn't able to modify this behaviour with name mangling. OTOH, creating a separate startup module solved this for me. For the record: If you suffer from attribute exceptions after calling qApp.quit(), and have defined overloaded event methods in an all in one module, try creating a seperate startup module in order to fix the race between pythons cleanup and Qt events still delivered. Pythons '-v' option may be helpful in this scenario, too. Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] Now tackle dtor strangeness
On Saturday 25 January 2003 17:02, Phil Thompson wrote:
Thanks for putting the effort into this - it was very helpful. The bug is
that qspinbox.sip should say...
bool eventFilter(QObject *,QEvent *);
...instead of...
void eventFilter(QObject *,QEvent *);
It will be fixed in tonight's snapshot.
Thanks. Well done. I feel better now. But please have another look into
these two:
qApp.quit(). Phil, it appears, that the QSpinBox base class disappears
while subclassed SpinBox event() handler is active. This doesn't look
right to me.
While making both versions functional identical, I've rewritten the event
decoder qEvent(), but couldn't believe my eyes: during qApp.quit() the
value of the global defined qEventDict{} in the .py script is replaced
with a None value somewhere under the covers! Please remove the
Something is definitely going wrong here.
I think this is just Python and Qt racing each other to tidy up. As the
behaviour of either isn't formally documented I think it's more a feature
rather than a bug.
Well, I cannot see the feature aspect here. OTOH, this obfuscates the code,
and it defies the principle of least surprise.
I digged into this a bit further and found a way to get around these problems
somehow:
1) The qEventDict does survive, if it is declared inside the qEvent function.
2) just keep a reference of QSpinBox, and call it, instead of the baseclass:
class SpinBox(QSpinBox):
def __init__(self, minValue, maxValue, step = 1, parent = None, name = None):
self.lastval = None
QSpinBox.__init__(self, minValue, maxValue, step, parent, name)
self.QSpinBox = QSpinBox
def event(self, e):
t = e.type()
print SpinBox event:, qEvent(t)
return self.QSpinBox.event(self, e)
Funny side note: it was enough to fix one of both sub classes this way to
prevent attribute errors here. This is pretty undeterministic, and that's
exactly the reason, why I don't like this behaviour...
Phil, one would expect, that as long as a class exists, its baseclass should
exist, either. The same goes for globals in module scope.
Note, that this happens, before dtor of QApplication aka PyQtDisownTopLevelWidgets(),
and even siplib:finalise() is called:
closeEvent
exec_loop: 0
PushButton event: WindowDeactivate
SpinBox event: WindowDeactivate
PushButton event: FocusOut
PushButton focusOutEvent
PushButton event: Hide
SpinBox event: Hide
PyQtDisownTopLevelWidgets
PyQtDisownTopLevelWidgets
finalise begin
finalise done
Is it possible to keep a reference on these internally and throw them away in
finalise()? For reference, current sbtest.py attached.
Phil
Pete
#!/usr/bin/env python
# sbtest v0.1: investigate QSpinBox strangeness
#
# Copyright 2002 Hans-Peter Jansen [EMAIL PROTECTED]
#
# This program is placed under the GNU General Public License V.2
import sys
from qt import *
# Just swap the _ of both qEventDicts to suppress the attribute errors
qEventDict = {
0: None,
1: Timer,
2: MouseButtonPress,
3: MouseButtonRelease,
4: MouseButtonDblClick,
5: MouseMove,
6: KeyPress,
7: KeyRelease,
8: FocusIn,
9: FocusOut,
10: Enter,
11: Leave,
12: Paint,
13: Move,
14: Resize,
15: Create,
16: Destroy,
17: Show,
18: Hide,
19: Close,
20: Quit,
21: Reparent,
22: ShowMinimized,
23: ShowNormal,
24: WindowActivate,
25: WindowDeactivate,
26: ShowToParent,
27: HideToParent,
28: ShowMaximized,
29: ShowFullScreen,
30: Accel,
31: Wheel,
32: AccelAvailable,
33: CaptionChange,
34: IconChange,
35: ParentFontChange,
36: ApplicationFontChange,
37: ParentPaletteChange,
38: ApplicationPaletteChange,
39: PaletteChange,
40: Clipboard,
42: Speech,
50: SockAct,
51: AccelOverride,
52: DeferredDelete,
60: DragEnter,
61: DragMove,
62: DragLeave,
63: Drop,
64: DragResponse,
70: ChildInserted,
71: ChildRemoved,
72: LayoutHint,
73: ShowWindowRequest,
80: ActivateControl,
81: DeactivateControl,
82: ContextMenu,
83: IMStart,
84: IMCompose,
85: IMEnd,
86: Accessibility,
87: Tablet
}
def qEvent(t):
_qEventDict = {
0: None,
1: Timer,
2: MouseButtonPress,
3: MouseButtonRelease,
4: MouseButtonDblClick,
5: MouseMove,
6: KeyPress,
7: KeyRelease,
8: FocusIn,
9: FocusOut,
10: Enter,
11: Leave,
12: Paint,
13: Move,
14: Resize,
15: Create,
16: Destroy,
17: Show,
18: Hide,
19: Close,
20: Quit,
21: Reparent,
22: ShowMinimized,
23: ShowNormal,
24: WindowActivate,
25: WindowDeactivate,
26: ShowToParent,
27: HideToParent,
28: ShowMaximized,
29: ShowFullScreen,
30: Accel,
31: Wheel
Re: [PyKDE] Next attempt to tackle QSpinBox strangeness
On Friday 24 January 2003 01:46, Doug Bell wrote: Hans-Peter Jansen wrote: Hi *, attached, you will find an app to reproduce some strangeness with QSpinBox behaviour. Problem: reimplemented QSpinBox don't get focus events and doesn't behave correctly on up/down cursor key events (value doesn't change). I'm not sure if this is your problem (I haven't gone through your example in detail), but I've also seen unusual behavior with QSpinBox focus events. I no longer remember details, but the problem concerns events being sent to the embedded QLineEdit within a spin box. You can access the embedded editor using the spin box's editor() method and check for events there. Doug, thanks for your answer. Unfortunately accessing editor() isn't always an option, since it would make simple database frontends f.e. effusively complicated, if possible at all. Hopefully we get this fixed, and forget about it again. Hope this helps, Doug. Cheers, Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Next attempt to tackle QSpinBox strangeness
On Thursday 23 January 2003 19:46, me wrote:
Problem: reimplemented QSpinBox don't get focus events and doesn't behave
correctly on up/down cursor key events (value doesn't change).
Also, manually editing the QSpinBox value doesn't generate a valueChanged
signal, nor does it revert invalid values.
Therefore, I'm going to translate this app to c++ in order
to check this behaviour of Qt directly soon.
Done, attached. Looks like the c++ version doesn't generate focus events,
either, but behaves correctly on cursor keys and manual editing. Consequently
both actions generate a valueChanged signal, unlike the py version.
Interesting side note: I needed to prepare the event() handlers not to
call the base class in order to avoid an attribute error during
qApp.quit(). Phil, it appears, that the QSpinBox base class disappears
while subclassed SpinBox event() handler is active. This doesn't look right
to me.
While making both versions functional identical, I've rewritten the event
decoder qEvent(), but couldn't believe my eyes: during qApp.quit() the
value of the global defined qEventDict{} in the .py script is replaced
with a None value somewhere under the covers! Please remove the try/except
statement in qEvent, uncomment the print statement and look yourself:
close app
PushButton event: type 'NoneType'
Traceback (most recent call last):
File sbtest.py, line 121, in event
print PushButton event:, qEvent(t)
File sbtest.py, line 79, in qEvent
if t in qEventDict.keys():
AttributeError: 'NoneType' object has no attribute 'keys'
SpinBox event: type 'NoneType'
Traceback (most recent call last):
File sbtest.py, line 96, in event
print SpinBox event:, qEvent(t)
File sbtest.py, line 79, in qEvent
if t in qEventDict.keys():
Something is definitely going wrong here.
TIA,
Pete
#!/usr/bin/env python
# sbtest v0.1: investigate QSpinBox strangeness
#
# Copyright 2002 Hans-Peter Jansen [EMAIL PROTECTED]
#
# This program is placed under the GNU General Public License V.2
import sys
from qt import *
qEventDict = {
0: None,
1: Timer,
2: MouseButtonPress,
3: MouseButtonRelease,
4: MouseButtonDblClick,
5: MouseMove,
6: KeyPress,
7: KeyRelease,
8: FocusIn,
9: FocusOut,
10: Enter,
11: Leave,
12: Paint,
13: Move,
14: Resize,
15: Create,
16: Destroy,
17: Show,
18: Hide,
19: Close,
20: Quit,
21: Reparent,
22: ShowMinimized,
23: ShowNormal,
24: WindowActivate,
25: WindowDeactivate,
26: ShowToParent,
27: HideToParent,
28: ShowMaximized,
29: ShowFullScreen,
30: Accel,
31: Wheel,
32: AccelAvailable,
33: CaptionChange,
34: IconChange,
35: ParentFontChange,
36: ApplicationFontChange,
37: ParentPaletteChange,
38: ApplicationPaletteChange,
39: PaletteChange,
40: Clipboard,
42: Speech,
50: SockAct,
51: AccelOverride,
52: DeferredDelete,
60: DragEnter,
61: DragMove,
62: DragLeave,
63: Drop,
64: DragResponse,
70: ChildInserted,
71: ChildRemoved,
72: LayoutHint,
73: ShowWindowRequest,
80: ActivateControl,
81: DeactivateControl,
82: ContextMenu,
83: IMStart,
84: IMCompose,
85: IMEnd,
86: Accessibility,
87: Tablet
}
def qEvent(t):
try:
if t in qEventDict.keys():
return qEventDict[t]
except:
pass
return Unknown;
probmsg = \
Problem: reimplemented QSpinBox below
don't get focus events and doesn't behave
correctly on up/down cursor keys!\
class SpinBox(QSpinBox):
def __init__(self, minValue, maxValue, step = 1, parent = None, name = None):
self.lastval = None
QSpinBox.__init__(self, minValue, maxValue, step, parent, name)
def event(self, e):
t = e.type()
print SpinBox event:, qEvent(t)
# this seems to be necessary because of races with qApp.quit()
if QSpinBox:
return QSpinBox.event(self, e)
else:
return 0
def focusInEvent(self, e):
self.lastval = self.value()
print SpinBox focusInEvent, self.lastval
QSpinBox.focusInEvent(self, e)
def focusOutEvent(self, e):
v = self.value()
print SpinBox focusOutEvent, v, self.lastval
if self.lastval != v:
emit(SIGNAL(valueChanged(int)), (v))
QSpinBox.focusOutEvent(self, e)
class PushButton(QPushButton):
def __init__(self, text = None, parent = None, name = None):
QPushButton.__init__(self, text, parent, name)
def event(self, e):
t = e.type()
print PushButton event:, qEvent(t)
# this seems to be necessary because of races with qApp.quit()
if QPushButton:
return QPushButton.event(self, e)
else:
return 0
def focusInEvent(self, e):
print PushButton focusInEvent
return QPushButton.focusInEvent(self, e)
def focusOutEvent
[PyKDE] Next attempt to tackle QSpinBox strangeness
Hi *,
attached, you will find an app to reproduce some strangeness with QSpinBox
behaviour.
Problem: reimplemented QSpinBox don't get focus events and doesn't behave
correctly on up/down cursor key events (value doesn't change).
This happens at least with SuSE-Versions 8.0 and 8.1, with all PyQt-Versions
up to the snapshot from 2003/01/11.
If you have a couple of spare minutes, please run the attached script from
a shell, tabcursor upcursor downtabspace and watch console output.
I get: (# comments added)
# startup
SpinBox event: ChildInserted
SpinBox event: ChildInserted
PushButton event: Move
PushButton event: Resize
PushButton event: Show
SpinBox event: Move
SpinBox event: Resize
SpinBox event: Show
SpinBox event: LayoutHint
PushButton event: Paint
PushButton event: WindowActivate
SpinBox event: WindowActivate
PushButton event: FocusIn
PushButton focusInEvent
PushButton event: Paint
# startup done
# tab
PushButton event: AccelOverride
PushButton event: KeyPress
PushButton event: FocusOut
PushButton focusOutEvent
PushButton event: Paint
SpinBox event: KeyRelease
# PushButton class gets focus event correctly, SpinBox don't
# cursor up
SpinBox event: AccelOverride
SpinBox event: KeyPress
SpinBox event: KeyRelease
# SpinBox doesn't change the value, consequently no valueChanged signal
# cursor down
SpinBox event: AccelOverride
SpinBox event: KeyPress
SpinBox event: KeyRelease
# again..
# tab
SpinBox event: AccelOverride
PushButton event: FocusIn
PushButton focusInEvent
PushButton event: Paint
PushButton event: KeyRelease
# again, PushButton class gets focus event correctly
# space
PushButton event: AccelOverride
PushButton event: KeyPress
PushButton event: Paint
PushButton event: KeyRelease
PushButton event: Paint
close app
PushButton event: WindowDeactivate
SpinBox event: WindowDeactivate
PushButton event: FocusOut
PushButton focusOutEvent
PushButton event: Hide
SpinBox event: Hide
# finished
If your output differs significantly from this log, please give me
a note, mentioning your OS, Qt, and PyQt versions. This is a long
standing problem, I'm suffering from and would like to get solved
somehow. Therefore, I'm going to translate this app to c++ in order
to check this behaviour of Qt directly soon.
Interesting side note: I needed to prepare the event() handlers not to
call the base class in order to avoid an attribute error during qApp.quit().
Phil, it appears, that the QSpinBox base class disappears while subclassed
SpinBox event() handler is active. This doesn't look right to me.
TIA,
Pete
#!/usr/bin/env python
# sbtest v0.1: investigate QSpinBox strangeness
#
# Copyright 2002 Hans-Peter Jansen [EMAIL PROTECTED]
#
# This program is placed under the GNU General Public License V.2
import sys
from qt import *
qEvent = {
0: None,
1: Timer,
2: MouseButtonPress,
3: MouseButtonRelease,
4: MouseButtonDblClick,
5: MouseMove,
6: KeyPress,
7: KeyRelease,
8: FocusIn,
9: FocusOut,
10: Enter,
11: Leave,
12: Paint,
13: Move,
14: Resize,
15: Create,
16: Destroy,
17: Show,
18: Hide,
19: Close,
20: Quit,
21: Reparent,
22: ShowMinimized,
23: ShowNormal,
24: WindowActivate,
25: WindowDeactivate,
26: ShowToParent,
27: HideToParent,
28: ShowMaximized,
29: ShowFullScreen,
30: Accel,
31: Wheel,
32: AccelAvailable,
33: CaptionChange,
34: IconChange,
35: ParentFontChange,
36: ApplicationFontChange,
37: ParentPaletteChange,
38: ApplicationPaletteChange,
39: PaletteChange,
40: Clipboard,
42: Speech,
50: SockAct,
51: AccelOverride,
52: DeferredDelete,
60: DragEnter,
61: DragMove,
62: DragLeave,
63: Drop,
64: DragResponse,
70: ChildInserted,
71: ChildRemoved,
72: LayoutHint,
73: ShowWindowRequest,
80: ActivateControl,
81: DeactivateControl,
82: ContextMenu,
83: IMStart,
84: IMCompose,
85: IMEnd,
86: Accessibility,
87: Tablet
}
probmsg = \
Problem: reimplemented QSpinBox below
don't get focus events and doesn't behave
correctly on up/down cursor keys!\
class SpinBox(QSpinBox):
def __init__(self, minValue, maxValue, step = 1, parent = None, name = None):
self.lastval = None
QSpinBox.__init__(self, minValue, maxValue, step, parent, name)
def event(self, e):
t = e.type()
if t in qEvent.keys():
print SpinBox event:, qEvent[t]
else:
print unknown SpinBox event:, t
# this seems to be necessary because of races with qApp.quit()
if QSpinBox:
return QSpinBox.event(self, e)
else:
return 0
def focusInEvent(self, e):
self.lastval = self.value()
print SpinBox focusInEvent, self.lastval
return QSpinBox.focusInEvent(self, e)
def focusOutEvent(self, e):
v = self.value()
print SpinBox focusOutEvent, v, self.lastval
Re: [PyKDE] pykde.sourceforge.net
On Thursday 16 January 2003 14:13, Michael Lauer wrote: Am Mit, 2003-01-15 um 23.05 schrieb Torsten Marek: What is the future of pyke.sf.net, because I want to know if it is possible to place some little programs I happened to write on that page. By now, I do not have my own page and I wouldn't like to create one. So it would be nice if there was a section of programs with links and/or direct downloads. Yeah, I second this. I have a bunch of (hopefully resuable) PyQt widgets which I could publish and would be interested in seeing other ones. One of the programs I mean is outline.py. It started as a port of the outline example of Qt, but is under development for some time now and has evolved. It keeps a tree of remarks in an XML file, I use it as todolist/notepad/knowledge base/organizer. Sounds interesting. Who is in charge of [EMAIL PROTECTED]? Do possibly mean http://sourceforge.net/project/admin/?group_id=61057 Jonathan and Jim are the project managers there. Jonathan, Jim, what do you think about a contribution package section. If somebody want to upload something, just post the details in this list file name: package name: package version: release notes: changelog (opt.): and upload to anonymous@ftp://upload.sourceforge.net Hopefully some project member picks it up quickly enough, and publish the thing in download section. Comments? Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] SIP Roadmap
Hi Phil friends, On Thursday 02 January 2003 20:10, Phil Thompson wrote: For those interested I've added a SIP Roadmap to the website at http://www.riverbankcomputing.co.uk/sip/roadmap.php which describes the main objectives and features for SIP v4. Comments welcome. This roadmap sounds very nice and reasonable. But what are your plans concerning point 18, 22, 23 and 24 from sip TODO? Phil Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] SIP Roadmap
On Friday 03 January 2003 13:21, Phil Thompson wrote: On Friday 03 January 2003 12:05 pm, Hans-Peter Jansen wrote: This roadmap sounds very nice and reasonable. But what are your plans concerning point 18, 22, 23 and 24 from sip TODO? The Roadmap isn't intended to cover everything - but I don't perceive these to be as important. Of course one purpose of the Roadmap is to enable people to change my perception. Well, while 18, 22, and 23 would allow the user to follow more pythonic approaches (and help also reducing hand written sip code), I do remember some difficulties in advanced QSQL handling without Qt property support, which is on of the big sell arguments for Qt3, IMHO. I can dig into the details again, if you want. Phil Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] QExtScintilla split views
Hi Phil, me again with a totally different topic: What do you think about implementing split views in QExtScintilla. From a quick glance, (Q)Scintilla provides an API for this. How hard it would be to adopt this in QExtScintilla? Since I'm not of big help in sip development, I could look into this one with your blessing. Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] sip wrapping problem [solved]
On Saturday 21 December 2002 02:36, Hans-Peter Jansen wrote: On Saturday 21 December 2002 00:43, Phil Thompson wrote: Where does the keyword code come from? It was PyQwt specific, but not the source of the problem. It was me being stupid (again). Sorry. The class is called QTIFFHandler, and thus python -c from qth import QTIFFHandler succeeds. A fax load succeeded, too, thus the lib is working now. Cool. Will look into getting it displayed later, today. A question remains, why does the wrong call not generate an error, but a loop? Again, it smells PyQwt setup.py related. I finally solved this glitch. It happened, because the way, I used setup.py, which created an identical qth.py and __init__.py in module dir. Using an intermediate build dir got rid of the stray qth.py. Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] sip beginners project pqfaxview-0.1.0
Hi, this is by far the smallest useful fax viewer, I know of. And it's smooth scaling, btw. Based on a small qtiffhandler c++ module, wrapped by sip. HOWTO: install sip and PyQt tar xvzf pqfaxview-0.1.0.tar.gz cd pqfaxview-0.1.0 make tar xvzf qtiffhandler-0.1.0.tar.gz cd qtiffhandler-0.1.0 make make install cd .. ./main.py Read source. Let me know, what do you think. I should mention, that creating this project was pure fun :-) Enjoy, Hans-Peter P.S.: I'm off for a few days. Merry christmas! pqfaxview-0.1.0.tar.gz Description: application/tgz
Re: [PyKDE] sip wrapping problem
On Saturday 21 December 2002 00:43, Phil Thompson wrote: class QTIFFHandler(QObject): def __init__(self,*args,**kwargs): libqthc.sipCallCtor(0,self,args) for key in kwargs.keys(): method = getattr(self, key) if type(kwargs[key]) == types.TupleType: apply(method,kwargs[key]) else: method(kwargs[key]) Where does the keyword code come from? Looks like it's somewhat related to setup.py and pyqt_support.py from PyQwt. Do you know, where i can find some simple setup.py or build.py for this kind of work? I would like to reduce this to a much simpler form (hopefully sip and PyQt version independant, if possible somehow). What do you think about including this in the PyQt examples section, once it works as expected? (with a simple fax viewer frontend). The .sip file looks Ok. Have you tried debugging the generated code to see where it is blocking? Not yet. Phil Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] sip wrapping problem [solved]
On Saturday 21 December 2002 00:43, Phil Thompson wrote: Where does the keyword code come from? It was PyQwt specific, but not the source of the problem. It was me being stupid (again). Sorry. The class is called QTIFFHandler, and thus python -c from qth import QTIFFHandler succeeds. A fax load succeeded, too, thus the lib is working now. Cool. Will look into getting it displayed later, today. A question remains, why does the wrong call not generate an error, but a loop? Again, it smells PyQwt setup.py related. Pete ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Opinions on pyuic Custom Widget Support
On Saturday 14 December 2002 18:34, Phil Thompson wrote: On Saturday 14 December 2002 4:04 pm, Ricardo Javier Cardenes Medina wrote: At first glance, I don't see a better way to do this, but I think you should preserve the current behaviour when no Python: has been provided (for backwards compatibility). You could even provide a Python: @defaults@, or something like that, allowing people to include the current generated imports, along with the other Python: clauses. I want to drop the current method because it is likely to be broken when you want to use both uic and pyuic, ie. when you are using PyQt as a rapid prototyping tool for C++ development. Please go ahead, Phil. Better supporting another sexy development strategy by far outweighs some minor hassle with backward compatibility in this respect. [Some cursory christmas thoughts/wishes, weather is asking for it:)] Since I joined this project on mid of july, I'm pleased to realize the speed of development without big talk. In fact, I would love to see a bit more cummunication on these advances33% wink. The biggest gift seems to be Phils effort in order to wrap Scintilla, which made it possible for Detlev to enhance eric to a very promising IDE in just adding 372 KB Python Source. It has grown to a size of 760 KB of sane an (mostly) easy to understand and i18ned code. I cannot imagine a better demonstration of the raw power from a develop environment. Simply incredible, guys! Phil, I would love to see you tackling some entries from the sip TODO. When browsing through sip's code last time, me badly realizes my knowledge holes on the flex/yacc front, but OTOH, the strong feeling, it would be worth the hassle to fill them. This may reduce the call for that somewhat crazy idea of coupling several c++ wrapper libs for one toolkit in one project. If only we could combine these efforts in order to make out world a bit more pythonic tomorrow ;-) This is by no means intended as an offence against the Boost.People. Please beware! Although PyQt is carried by a comparably small cummunity, it is a very nice place to be. Thanks, guys! [Asking myself: any xx chromosome coded human listening?] Phil I wish you all a nice christmas, Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] help
Consider installing sip and RTFM. On Monday 09 December 2002 17:00, Pantxo Villa wrote: Hi, I'm French, so sorry for my English. I try to install pyqt with python 2.2 and qt 2.3.1 or newer, but the make install give me the following error, and it's the same when I try to run examples... Could you help me please? /bin/sh ../mkinstalldirs /opt/python_222/lib/python2.2/site-packages /usr/bin/install -c -m 644 /qt.py /opt/python_222/lib/python2.2/site-packages/qt.py make install-data-hook make[3]: Entering directory `/usr/local/PyQt-3.2.4/qt' (cd /tmp;PYTHONPATH=/opt/python_222/lib/python2.2/site-packages:/opt/python_ 222/lib/python2.2/site-packages /opt/python_222/bin/python -c import qt) Traceback (most recent call last): File string, line 1, in ? File /opt/python_222/lib/python2.2/site-packages/qt.py, line 46, in ? import libsip ImportError: libqt-mt.so.3: cannot load shared object file: No such file or directory make[3]: *** [install-data-hook] Error 1 make[3]: Leaving directory `/usr/local/PyQt-3.2.4/qt' make[2]: *** [install-data-am] Error 2 make[2]: Leaving directory `/usr/local/PyQt-3.2.4/qt' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/usr/local/PyQt-3.2.4/qt' make: *** [install-recursive] Error 1 _ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagné. Règlement : http://www.ifrance.com/_reloc/sign.sms ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] [ERIC3][PATCH] Just another file could not be opened message
Hi Detlef, while trying to single step through eric3 itself, i got this message: The file /usr/src/packages/BUILD/eric-3.0.0a2/eric/eric/Project.py could not be opened triggered from Editor.py. This path contains one 'eric/' to much, and depends on the path, eric3 is started from. In this case: /usr/src/packages/BUILD/eric-3.0.0a2/eric - open project eric.pro If started from: /usr/src/packages/BUILD/eric-3.0.0a2 - open project eric/eric.pro it can be single stepped just fine, apart from the splash covering the screen. To circumvent this, I suggest applying something like the attached diff ;-) BTW: what about remembering the debugger command lines in project file? Hans-Peter --- /usr/lib/python/site-packages/eric3/eric3.py 2002-11-24 19:47:11.0 +0100 +++ eric/eric3.py 2002-11-30 16:31:50.0 +0100 @@ -53,12 +53,16 @@ ericDir = os.path.dirname(sys.argv[0]) if ericDir == '': ericDir = '.' app = QApplication(sys.argv) -# generate and show a splash window -splash = showSplash() +# generate and show a splash window, if not suppressed +if --nosplash in sys.argv: +del sys.argv[sys.argv.index(--nosplash)] +splash = None +else: +splash = showSplash() # We can only import these after creating the QApplication because they # make Qt calls that need the QApplication to exist. from UserInterface import UserInterface @@ -102,9 +106,10 @@ mw = UserInterface() app.setMainWidget(mw) mw.show() -del splash +if splash: +del splash app.exec_loop()
Re: [PyKDE] Re: eric3 python-site files not found
On Friday 29 November 2002 22:03, Arno Paehler wrote: Hi Detlev, I now tried Hans-Peter's script and the problem goes away. Maybe SuSE need to revise the way they build their rpm. Before I start bugging some people at SuSE, I would like to understand the problem. Phil? As stated before, I see some importance to get this fixed before their next release. I will easily detect this when traffic in suse-beta ML arises again... In the meantime, we already know, how to fix this ;-) Jonathan: I will update sf.net release notes soon... There is another message that I get but that doesn't seem to affect eric3's operation. I just include it here for completeness. Arno - paehler@linux eric3 eric: no translation file 'qt_C'found. Using default. eric: no translation file 'qscintilla_C'found. Using default. eric: no translation file 'eric3_C'found. Using default. Please report to [EMAIL PROTECTED]. Well, this is related to your locale setting and somewhat expected here. Maybe Detlef should handle this special case, as it doesn't make much sense to search for C locale translations in the first place. BTW, Try LC_CTYPE=de_DE@euro eric3 to enable the german translation. (I expect you to be a native german speaker, even if it appears, that you're sitting on the other side of the globe ;-) [...] Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Re: eric3 python-site files not found
Hi Ricardo, I am aware of compileall.py, but it doesn't generate both flavors in one hitch, does it? Which flavor it generates seems to depend on the state of __debug__. Maybe it's enough to modify that, I will check that soonish. On Thursday 28 November 2002 01:21, Ricardo Javier Cardenes Medina wrote: On Thu, Nov 28, 2002 at 12:26:00AM +0100, Hans-Peter Jansen wrote: pycompile -vao Mmmh... Check for /usr/lib/python2.X/compileall.py. That script does the same and I think it's on the standard Python distribution. Thanks, Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] eric3 alt. layout
Hi Detlev, Hi PyQties, here's a patch to top of ericgeom.diff, which implements an _experimental_ alternate layout. If you want your old layout back, set self.layoutstyle = qtdes in UserInterface.py. Expect a restored geometry to be mangled. It separates Browser, Inspector, and Log component on the left pane, in order to get a bigger editing space. Here is a screenshot: http://lisa-gmbh.de/download/eric3alt.jpg (80k) full size: http://lisa-gmbh.de/download/eric3altfull.jpg (165k) Yes, I'm using a uncommon color set. Note also, that this one uses smaller icons 20x18, opposed to the genuine 22x22. [ericIconsShrink1.tar.gz] Detlev: Sorry, the first icon patchset was broken. Please try this one. Comments welcome. eric-hacking-is-fun'ly y'rs, Hans-Peter ericIconsShrink1.tar.gz Description: application/tgz --- UserInterface.py.hp 2002-11-28 22:53:06.0 +0100 +++ UserInterface.py 2002-11-28 22:53:28.0 +0100 @@ -88,43 +88,72 @@ # Generate the debug server object dbs = DebugServer() # Generate an empty project object self.project = Project(self) + +# Create the workspace now so that we can connect QActions to it +self.layoutStyle = alt +if self.layoutStyle == alt: +# alternate layout style +self.hSplitter = QSplitter(self.centralWidget(),hSplitter) +self.hSplitter.setOrientation(QSplitter.Horizontal) + +# Create a splitter for the right hand side +self.vSplitter = QSplitter(self.hSplitter,vSplitter) +self.vSplitter.setOrientation(QSplitter.Vertical) + +# Create the project browser +self.projectBrowser = ProjectBrowser(self.project, self.qtdir, self.vSplitter) +self.projectBrowser.show() + +# Create the shell, browser, variables part of the user interface +self.sbv = SBVviewer(dbs, self.vSplitter) + +# Create the log viewer part of the user interface +self.logViewer = LogView(self.vSplitter) +self.logViewer.setMinimumSize(100,60) + + # Create the view manager depending on the configuration setting +self.viewmanager = ViewManager.factory(self.hSplitter, self, dbs) + +# add the splitter to the main windows layout +appWindowLayout.addWidget(self.hSplitter) + +else: # self.layoutstyle == qtdes +# style to match the appearence of Qt Designer. +self.hSplitter = QSplitter(self.centralWidget(),hSplitter) +self.hSplitter.setOrientation(QSplitter.Horizontal) + +# Create the project browser +self.projectBrowser = ProjectBrowser(self.project, self.qtdir, self.hSplitter) +self.projectBrowser.show() + +# Create the view manager depending on the configuration setting +self.viewmanager = ViewManager.factory(self.hSplitter, self, dbs) + +# Create a splitter for the right hand side +self.vSplitter = QSplitter(self.hSplitter,vSplitter) +self.vSplitter.setOrientation(QSplitter.Vertical) + +# Create the shell, browser, variables part of the user interface +self.sbv = SBVviewer(dbs, self.vSplitter) + +# Create the log viewer part of the user interface +self.logViewer = LogView(self.vSplitter) +self.logViewer.setMinimumSize(100,100) + +# add the splitter to the main windows layout +appWindowLayout.addWidget(self.hSplitter) -# Create the workspace now so that we can connect QActions to it. This -# is done to match the appearence of Qt Designer. -self.hSplitter = QSplitter(self.centralWidget(),hSplitter) -self.hSplitter.setOrientation(QSplitter.Horizontal) - -# Create the project browser -self.projectBrowser = ProjectBrowser(self.project, self.qtdir, self.hSplitter) -self.projectBrowser.show() - -# Create the view manager depending on the configuration setting -self.viewmanager = ViewManager.factory(self.hSplitter, self, dbs) - -# Create a splitter for the right hand side -self.vSplitter = QSplitter(self.hSplitter,vSplitter) -self.vSplitter.setOrientation(QSplitter.Vertical) - -# Create the shell, browser, variables part of the user interface -self.sbv = SBVviewer(dbs, self.vSplitter) - -# Create the log viewer part of the user interface -self.logViewer = LogView(self.vSplitter) -self.logViewer.setMinimumSize(100,100) - +# setup logview self.stdoutTab = LogWidget(self) self.logViewer.addTab(self.stdoutTab, self.trUtf8(stdout)) self.stderrTab = LogWidget(self)
Re: [PyKDE] Re: eric3 python-site files not found
On Thursday 28 November 2002 21:22, Detlev Offenbach wrote:
Hi Arno,
Hi Arno,
what about subscribing PyKDE? Pretty low traffic ML.
On Tuesday 26 November 2002 12:47, you wrote:
Hi,
when single-stepping through some of my python files with eric3
I get an error dialog with the message
The file
/var/tmp/python-2.2.1-build/usr/lib/python2.2/sre.py
could not be opened.
I am using python-2.2.1-45 from SuSE 8.1. I also have the rpm
python-nothreads-2.2.1-45 installed, not sure whether that
maytters. The same python files run fine outside of eric3.
The filename in the message looks like a leftover from a build.
I am using SuSE 8.1 as well and haven't seen the described behaviour so
far. Would it be possible for you, to send me one of your scripts that
fails to run. The only difference I can see from your description is,
that I don't have the python-nothreads-2.2.1-45 package installed. It
could be possible, that your Python tries to execute a script
compiled/optimized with one version with the other one. At the moment I
don't have any other clue.
The problem seems to be related to the way, how eric resolves
the path of the source (using the path provided in the *.py{c,o}
files). This clashes with the way, SuSE built their python package,
which leads to these strange messages from eric. I solved this
problem with the attached script:
Hans-Peter, what do you mean by that. I am not aware of any special path
resolving in eric (but maybe that's deep in the old code that I haven't
touched).
Detlev, please try this:
strings -f /usr/lib/python2.2/*.py[co] | grep /var/tmp/
I bet, you will find a lot of matches. Try single stepping through one of
these, and you should see.
Attached is a significantly speeded up version of my compile script.
(works with a pipe and two, not n+1 python processes)
Detlev
Hans-Peter
#! /usr/bin/env python
usage: %s [-arv] [dirs/files] ...
byte-compiles python files/dirs
-a compile all files of current python installation
-o optimized compile, too
-r recursive behaviour
-v verbose level (cumulative)
dirs/files: to compile
# (c)reated by Hans-Peter Jansen, LISA GmbH, Berlin
#
# Licence: GPL http://www.gnu.org/licenses/gpl.html
#
# 2002-11-27hpinitial version
# 2002-11-28hppipe for optimized compile
#
# TODO:
# - testing
#
# vim:set et ts=4 sw=4:
import sys, os
import getopt
import glob
import py_compile
argv0 = os.path.basename(sys.argv[0])
optimize = 0
verbose = 0
optpipe = None
def out(lvl, arg):
if lvl verbose:
return
err(arg, sys.stdout)
def err(arg, ch = sys.stderr):
if arg:
ch.write(arg)
if arg[-1] != \n:
ch.write(\n)
else:
ch.write(\n)
ch.flush()
def exit(ret=0, arg=None):
if arg:
out(0, %s: %s % (argv0, arg))
sys.exit(ret)
def usage(ret=0, arg=None):
if arg:
out(0, %s: %s % (argv0, arg))
out(0, __doc__ % (argv0))
sys.exit(ret)
def pycompile(path, recursive = 0, depth = 0):
if os.path.isdir(path):
for p in glob.glob(os.path.join(path, *)):
if depth == 0 or recursive:
pycompile(p, recursive, depth + 1)
elif os.path.isfile(path):
if path[-3:] == '.py':
out(1, compiling %s % (path))
py_compile.compile(path)
if optimize:
out(1, compiling %s (opt) % (path))
optpipe.write(%s\n % path)
optpipe.flush()
else:
out(1, %s ignored % (path))
if __name__ == '__main__':
#global verbose, optimize
try:
optlist, args = getopt.getopt(sys.argv[1:], aorvO)
except getopt.error, msg:
usage(1, msg)
all = 0
optimize = 0
recursive = 0
optproc = 0
for opt, par in optlist:
if opt == '-a':
all = 1
elif opt == '-o':
optimize = 1
elif opt == '-r':
recursive = 1
elif opt == '-v':
verbose += 1
elif opt == '-O':
optproc = 1
if optimize:
# create a pipe to a slave process for optimized compile
optpipe, stdout = os.popen2(python -O %s -O % (sys.argv[0]))
elif optproc:
# handle optimized compile here
while 1:
l = sys.stdin.readline()
if not l:
sys.exit(0)
py_compile.compile(l[:-1])
if all:
pyFullVers = sys.version.split()[0]
vl = pyFullVers.split(.)
pyVers = vl[0] + . + vl[1]
pycompile(os.path.join(sys.prefix, lib/python + pyVers), 1)
else:
for p in args:
pycompile(p, recursive)
if optpipe:
optpipe.close()
Re: [PyKDE] ANN: Packages for Eric, the Python IDE
On Wednesday 27 November 2002 17:19, Gordon Tyler wrote: Víctor R. Ruiz wrote: - The default fonts are too big This was a prolem for me too. I found it quite annoying to change all the fonts to something else like Courier New because I had to individually change every different font style (Comment, Numbers, etc.). It would be nice if there was a Change All Styles Font button where I could select one font to use for _all_ the styles. Implying, you're using eric3 on some unix derivate, try using an editor with search and replace in [Scintilla] section of ~/.eric3/eric3rc. Been there, done that, now it fits me needs. Note: you cannot use eric3 itself for that task. Ciao, Gordon Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] [ANN] SuSE 8.1 RPMs for PyQt/PyQwt/PyKDE snapshots added/updated
Hi PyQties, just updated PyQt-20021122-2.i586.rpm to PyQt-20021122-3.i586.rpm, because I missed to include the new qtext module. This is due to fact, that I haven't managed to build the rpm with a proper RPM_BUILD_ROOT. Sorry for the inconvenience. As a bonus, I've added PyQwt and PyKDE today: http://lisa-gmbh.de/download.html#PyQt-snapshots http://lisa-gmbh.de/download/qscintilla-20021122-1.i586.rpm 285 KB http://lisa-gmbh.de/download/sip-20021114-1.i586.rpm 131 KB http://lisa-gmbh.de/download/PyQt-20021122-3.i586.rpm 3.4 MB ***UPDATED*** http://lisa-gmbh.de/download/eric3-3.0.0a2-1.i586.rpm 500 KB http://lisa-gmbh.de/download/PyQwt-20020807p1-2.i586.rpm 498 KB http://lisa-gmbh.de/download/PyKDE-3.3.2-7.i586.rpm 5.4 MB A short success/busted message on usage is highly appreciated. Thanks goes out to everybody involvedgrin. Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] [ANN] New repository for non-official Debian packages
Hi Ric,
On Monday 25 November 2002 23:01, Tom Jenkins wrote:
I installed python2.2-qtext which pulled in libqscintilla0. However the
installation failed with:
Setting up python2.2-qtext (3.4+20021122-1) ...
Traceback (most recent call last):
File string, line 1, in ?
File /usr/lib/python2.2/site-packages/qtext.py, line 28, in ?
import libqtextc
ImportError: libqscintilla.so.0: cannot open shared object file: No such
file or directory
dpkg: error processing python2.2-qtext (--configure):
subprocess post-installation script returned error exit status 1
i looked at libqscintilla0's files and there are only /usr/share/doc
files; no actual so's. did i miss something or is this a problem with
the package?
FJI: This one hit me today, too. Well not me, but another guy told me...
I was missing this module in _PyQt_:
%{python_site}/qtext.py
%{python_site}/libqtextcmodule.so
%{python_site}/libqtextcmodule.so.1
%{python_site}/libqtextcmodule.so.1.0
%{python_site}/libqtextcmodule.so.1.0.0
It's noted in NEWS, btw.
Cheers,
Hans-Peter
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] [ANN] SuSE 8.1 RPMs for QScintilla/sip/PyQt/eric3 snapshots
Hi PyQties, thanks to the efforts of Phil and Detlef, I proudly announce the availability of following packages here: http://lisa-gmbh.de/download.html#PyQt-snapshots http://lisa-gmbh.de/download/qscintilla-20021122-1.i586.rpm 285 KB http://lisa-gmbh.de/download/sip-20021114-1.i586.rpm 131 KB http://lisa-gmbh.de/download/PyQt-20021122-1.i586.rpm 3.4 MB http://lisa-gmbh.de/download/eric3-3.0.0a2-1.i586.rpm 500 KB A short success/busted message on usage is highly appreciated. Thanks goes out to Phil and Detlef. This toolkit is simply the sexiest in town. Enjoy, Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] crash: pure virtual function called
On Tuesday 12 November 2002 22:39, marvelan L wrote: I have built an application with Qt 3.0.4 and PyQt 3.4. From time to time I get a error message on stdout saying pure virtual function call and then abort is called and the program exits. What about providing the facts at least, not some magical phrase. Narrowing down the problem to the essence inside a test script often helps a lot. Remember: we're all telepathic unapt. I suspect that this is from the PyQt bindings. Have anyone seen this and know what to do about it? /Marv Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] Python list handling for QRect, QPoint, and QSize
Hi Phil, since I catched the flu this weekend, I think of contributing something useful to PyQt. Namely the IMHO missing handling of python lists, where QRect, QPoint, and QSize objects are expected. (QColor?) On my first cursory look, there seem to be to ways, but I don't know their implications: 1) implement __len__(), __getitem__() like in qstringlist.sip 2) %MappedType QxyzQInt, like in qvaluelist.sip Q1) Why is __setitem__ missing from 1 Q2) Does method 2 provide transparent conversion from and to the correct types, whereever they're used? (e.g. QObject) TIA, Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] eric locale problem fixed
Hi Detlef, hi Phil, as promised, I looked into my eric locale issue here. The attached patch fixes it for me. It boils down to filtering the locale definition to the major value, and fixes two c/p glitches. Along the way, hunk 1 and 2 removes some stray ^M's at EOL. BTW: Today, I prepared some new SuSE 8.1 rpm's, but won't find time to throw them on my site today: sip-20021018-1.i586.rpm (112k), qscintilla-0.2-1.i586.rpm (252k), and PyQt-20021024-2.i586.rpm (3,45m). I will happily send them everybody directly on short request. (w or w/o src.rpm's?). Have a good day, Hans-Peter --- /usr/src/packages/SOURCES/PyQt-x11-gpl-snapshot-20021024/eric/eric.py 2002-10-24 11:04:14.0 +0200 +++ eric/eric.py 2002-10-24 16:19:41.0 +0200 -5,7 +5,7 import os from qt import QApplication, QTranslator, QTextCodec -from Dirs import ericDir +from Dirs import ericDir import Preferences qtTrans = None -27,11 +27,16 prog = None # Load translation files and install them -loaded = 0 +loaded = 0 loc = Preferences.getUILanguage() if loc is None: loc = unicode(QTextCodec.locale()) - +# grab the major locale +try: +loc = loc.split(_)[0] +except: +pass + # 1) load translations for qt qtTrans = QTranslator(None) qtdir = os.getenv(QTDIR) -54,10 +59,10 # 2) load translations for eric ericTrans = QTranslator(None) -loaded = qtTrans.load(eric_ + loc, .) +loaded = ericTrans.load(eric_ + loc, .) # try in our installation if not found if not loaded: -loaded = qtTrans.load(eric_ + loc, ericDir) +loaded = ericTrans.load(eric_ + loc, ericDir) # install it if successful if loaded: app.installTranslator(ericTrans)
[PyKDE] Back to work..
Hi Phil, here is the diff against build.py v3.4, I'm using for the RPMs. I'm confident about the first hunk, but unsure about the second: --- build.py.orig 2002-10-08 19:11:40.0 +0200 +++ build.py2002-10-08 20:13:35.0 +0200 @@ -1147,7 +1147,7 @@ f = open(Makefile,a) f.write(\ninstall-eric:\n) -ericdir = modDir + os.sep + eric +ericdir = os.path.join(modDir, eric) # Create the platform specific wrappers. ename = createPyWrapper(ericdir,eric,eric) @@ -1162,6 +1162,7 @@ f.write(\t-%s eric%s*.py %s\n % (platCopy,os.sep,ericdir)) f.write(\t-%s eric%s*.pyc %s\n % (platCopy,os.sep,ericdir)) f.write(\t-%s eric%s*.qm %s\n % (platCopy,os.sep,ericdir)) +f.write(\t-%s eric%s*.ts %s\n % (platCopy,os.sep,ericdir)) f.write(\t-%s %s %s\n % (platCopy,ename,platBinDir)) f.write(\t-%s %s %s\n % (platCopy,uname,platBinDir)) f.write(\t-%s %s %s\n % (platCopy,hname,platBinDir)) Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Where What ?
On Wednesday 23 October 2002 10:10, Phil Thompson wrote: On Wednesday 23 October 2002 9:02 am, Jonathan Gardner wrote: On Tuesday 22 October 2002 12:25 pm, Rob Hooft wrote: Jonathan Gardner wrote: 3. Web designer. Needs to be familiar with PHP, or willing and able to learn. What you describe might actually be served very well with a WikiWiki. And with MoinMoin there is a very nice python implementation available. That would just leave you with the requirement to find a place that can host a Wiki for you. Sounds great. Where can we do it? Can you administer something like this? Why don't you use the Wiki on python.org? There is a section for PyQt which I put introductory, PyQt is great type stuff in. It would be one way to give PyQt greater exposure to the wider Python community. Also regular Freshmeat release entries would serve this purpose. Last one of PyQt is from july with version 3.3, and for PyKDE from may with 3.2.4. Phil Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] QPixmap.getWidget() returns colurful something
Hi Marc, On Thursday 17 October 2002 09:49, Marc Schmitt wrote: Hi, I get strange behavior when I try to grab a pixmap from a widget. After one second, when the timer times, the app flickers and all buttons are gone. When I then open the saved image, only lines and some colors appear. Did I miss something, or is it an PyQt anormaly ? Works for me here. Want the snap? Thanks -Marc Cheers, Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Runtime issues on SuSE 8.1
Hi Marc, hi Jim,
I finally touched the khtml_part problem. Here is my mod:
--- ../PyKDE-3.3.2.orig/sip/khtml_part.sip 2002-08-21 20:08:45.0 +0200
+++ ./sip/khtml_part.sip2002-10-16 13:02:32.0 +0200
@@ -124,8 +124,8 @@
QRect r;
int i = 0;
- if
(sipParseArgs(sipArgsParsed,sipArgs,mJ0J0ii,sipThisObj,sipClass_KHTMLPart,ptr,
sipClass_QPainter, p,
- sipClass_QRect, r, i))
+ if
+(sipParseArgs(sipArgsParsed,sipArgs,mJ0J0JOi,sipThisObj,sipClass_KHTMLPart,ptr,
+sipClass_QPainter, p,
+ sipClass_QRect, r, i))
{
bool b;
At least, it compiles, but does this make sense also?
I moderately sure about the missing , which fixes the compiler complaint,
but what about this sip argument format string?
Please comment!
Thanks,
Hans-Peter
On Wednesday 16 October 2002 11:10, Marc Schmitt wrote:
On Mittwoch, 16. Oktober 2002 02:48, Jim Bublitz wrote:
Nope. I changed that (and some randomly some other permutation of
that occurance within khtml*.sip) but without success.
I'm not sure what you mean here - the 'ii' means it's looking for
two ints passed in, but only one is passed in PyKDE (the second from
the original declaration was a bool *, which PyKDE *returns* as a
value in a tuple). ii is only wrong if only one int is expected
in the arg list; it would be correct for two ints in the arglist,
which isn't the case here.
I first assumed replacing the (to me mysterious) string mJ0J0ii had
helped and brought me further (which was a mistake, I just looked at the
wrong lines) so I thought, Hey, if this helpes lets edit some others too
:)
About the internals of sip I know not much. I've read a bit about swig, and
used it once but not sip.
Ooops! My mistake (in more ways than one). The exact same code is
in khtml_part.sip (cut and pasted, I'm sure), so you might try
another iteration of the same fixes but on khtml_part.sip instead.
It doesn't seem likely that the extra 'i' is the problem though -
I'm not sure what is. Anybody recognize the meaning of non-POD
type??
I found this :
http://www.boost.org/libs/python/doc/v2/definitions.html
POD: A technical term from the C++ standard. Short for Plain Ol'Data: A
POD-struct is an aggregate class that has no non-static data members of
type pointer to member, non-POD-struct, non-POD-union (or array of such
types) or reference, and has no user-defined copy assign- ment operator and
no user-defined destructor. Similarly, a POD-union is an aggregate union
that has no non-static data members of type pointer to member,
non-POD-struct, non-POD-union (or array of such types) or reference, and
has no user-defined copy assignment operator and no user-defined
destructor. A POD class is a class that is either a POD-struct or a
POD-union. An aggregate is an array or a class (clause 9) with no
user-declared constructors (12.1), no private or protected non-static data
members (clause 11), no base classes (clause 10), and no virtual functions
(10.3).
and especially this one :
http://lists.trolltech.com/qt-interest/2002-03/thread4-0.html :
[Q:]
I'm trying to use QString::sprintf with little luck.
During compilation I get the following warnings:
g++ -c -pipe -Wall -W -O2 -DQT_NO_DEBUG -I/var/tmp/qt/include
-I/var/tmp/qt/mkspecs/default -o main.o main.cpp
main.cpp: In function `int main (int, char **)':
main.cpp:50: warning: cannot pass objects of non-POD type `class
QString' through `...'
main.cpp:50: warning: cannot pass objects of non-POD type `class
QString' through `...'
[A:]
You can't pass QStrings through QString::sprintf().
[A2:]
Yes, you can, but you'll lose some Unicode information:
sprintf(%s, string.latin1())
or just
sprintf(%s, (const char*)string)
This leas me to the following conclusion : Its not KDE3.0.4 that changed,
but GCC3.2 ! Before it has been just a warning, now it's an error ... So,
what do you think ?
That's exactly the reason why I stopped developing C(++) and started
python.
c-compiler-developer : Hey, compiling is just too easy. Lets do some
education on our users and show them how -officially- standarized code must
look like ...
-Marc
ps: I'm just compliling without the paint method. Let's see.
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] ANN : PyKDE 3.3.2 SuSE 8.1 rpm
On Wednesday 16 October 2002 11:28, Marc Schmitt wrote:
Hi,
PyKDE 3.3.2 for SuSE 8.1 is there (its currently uploading). It has the
subtitle (Krippled) as I had to remove the paint function within
khtml_part.sip in order to make it compile. Everything else should work as
before.
When we find a way to work around the non-pod type error (probably caused
by gcc3.2) I'll make a new minor release.
For your convenience, I've made an alternative build available here:
http://lisa-gmbh.de/download.html#PyQt-RPMs
Note, that I don't regard this as a contest with Marc's affords,
with were pretty valuable to get this job done. Not to forget the
affords of the well known creators of these packages. Thanks a lot!
We finally came to the conclusion, that providing more than the
necessary number of packages, is sub optimal for most users.
I hope, I've made the correct fixes to sip/khtml_part.sip:
--- ../PyKDE-3.3.2.orig/sip/khtml_part.sip 2002-08-21 20:08:45.0 +0200
+++ ./sip/khtml_part.sip2002-10-16 21:11:18.0 +0200
@@ -124,8 +124,8 @@
QRect r;
int i = 0;
- if
(sipParseArgs(sipArgsParsed,sipArgs,mJ0J0ii,sipThisObj,sipClass_KHTMLPart,ptr,
sipClass_QPainter, p,
- sipClass_QRect, r, i))
+ if
+(sipParseArgs(sipArgsParsed,sipArgs,mJ0J0i,sipThisObj,sipClass_KHTMLPart,ptr,
+sipClass_QPainter, p,
+ sipClass_QRect, r, i))
{
bool b;
Bye
-Marc
Enjoy,
Hans-Peter
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Runtime issues on SuSE 8.1
On Tuesday 15 October 2002 03:38, Ricardo Javier Cardenes Medina wrote: On Mon, Oct 14, 2002 at 09:14:29PM -0400, Eron Lloyd wrote: Hi Eron. This SuSE issue was discussed a couple of weeks ago. Please, read the end of the thread, starting from: http://mats.gmd.de/pipermail/pykde/2002-October/003767.html to see the causes and the solution. I don't know if Marc published at last the fixed SuSE packages. Well, SuSE fixed their qt3 package, which is available as online update. Unfortunately their yast online update, aka you has a problem. If you run you the first time, it will force you to update some yast2 packages first. Before running you a second time, run this in a shell: cd /var/adm/YaST mkdir SelDB cp InstSrcManager/IS_CACHE_0x0001/DATA/descr/default.sel SelDB mkdir ProdDB cp InstSrcManager/IS_CACHE_0x0001/DESCRIPTION/description ProdDB/prod_0001 see: http://sdb.suse.de/de/sdb/html/81_you.html and: http://sdb.suse.de/de/sdb/html/81_you2.html Hth, Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] sip/PyQt-3.4 RPMs for SuSE 8.1 available
Hi Adrian, hi *, I put some homebrewn PyQt-x11-gpl-3.4 RPMs here: http://lisa-gmbh.de/download.html#PyQt-RPMs Please bear with me, as these are my first RPM experiments... Althrough it doesn't solve the KDE_MALLOC problem generally, it fixes eric and friends by patching the generated wrapper scipts and _really_ installs him [It took me a while to get the Eric Idle joke :-)]. BTW: Detlev, somehow eric doesn't appear localized here, although it loads its de translation (verified with strace), unlike the qt translations: eric eric: no translations for Qt found I added an additional doc package with doc and examples3(*) dirs. Hans-Peter (*) this is, where my contributions live ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] [PATCH] i18n
Hi Detlev,
what do you think about the attached patch. Without keeping a
reference to the widgets, they all disappear, but the last,
when selecting All...
Really nice example, though.
Hans-Peter
--- i18n.py.orig Tue Sep 10 14:56:22 2002
+++ i18n.py Mon Sep 30 15:08:39 2002
-56,6 +56,7
self.emit(PYSIGNAL('mapped(int)'), (self.map[qo],))
translator = None
+wlist = [] # keep reference to widgets
def showLang(lang):
global translator
-80,6 +81,7
qApp.installTranslator(translator)
m = MyWidget()
m.setCaption(PyQt Example - i18n - + unicode(m.caption()))
+wlist.append(m)
return m
def main(argv):
Re: [PyKDE] Python functions as slots
Hi Konrad, On Monday 30 September 2002 20:50, Konrad Hinsen wrote: I have lots of problems using Python functions as slots. As a simple illustration, take the following code (an example from Boudewijn Rempt's excellent book with an added connect): import sys from qt import * def foo(*args): print args app=QApplication(sys.argv) button=QPushButton(Hello World, None) app.setMainWidget(button) button.show() app.connect(button, SIGNAL(clicked()), app, foo) app.exec_loop() This is apparently wrong. Remove app arg from app.connect and all goes well. BTW: signal clicked does not take any arguments. If you want to pass some custom arguments with signals, roll your own (signals). When I run this code, I get: Traceback (most recent call last): File hello1.py, line 14, in ? app.connect(button, SIGNAL(clicked()), app, foo) TypeError: Argument 4 of QObject.connect() has an invalid type This doesn't always happen. For example, I can run the example dial.py from the same book without problems, although it uses Python methods as slots. In case it matters, I use PyQt 3.4 and Qt 2.3.1. Any idea what is happening here? Konrad. BTW: Are you the Konrad Signum Hinsen? Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] lineedits.py example
[No reponses on my previous mails. Seems like a Mo-Fr 9-5 list :-(] Anyways, this time a new transition is attached. I took an easy one, and this one is working already (less Qt bug, Double Validator isn't working here in both versions). Phil: would you mind throwing it into examples? I'm doing these to get comfortable with PyQt and being able to study Kalle's book Programming with Qt, 2nd Edition more successful. Boudewijn's book is missing some important aspects of PyQt 3 from my view, especially SQL features. Although Kalle's book isn't comprehensive on this topic, either. Will go on with table examples. Bye, Hans-Peter lineedits.py Description: Binary data
[PyKDE] pyqt sql table3 problem
Hi all, while diving into the wonderful world of sql featured PyQt-3.2.4, I've tried to convert the sql/table3 example from qt 3.0.4 into python. While thinking, that I've done the conversion correctly (I'm pretty new on mind translation c++ to python, so please be patient), it just behaves different to the c++ version. The subject of this example is a custom combobox editor for QDataTable. In the c++ version, the combobox pops it up correctly, when double clicking on a status field, while the python version simply does ignore this. What's wrong with it? For your convenience, I've attached both, the sqltable3.py script, and a testdb.sql to offer an instant starting point. Please edit DB variables on top of sqltable3.py to fit your needs, and populate the database with mysql testdb.sql. The script expects to have the right database plugin compiled for qt. I've configured qt additionally with: -plugin-sql-mysql -I /usr/include/mysql -L /usr/lib/mysql on my SuSE 7.3 setup. To Phil: sqltable3.py is prepared to go into the example section, if it works some day. Any objections? Cheers, Hans-Peter sqltable3.py Description: Binary data testdb.sql Description: Binary data
[PyKDE] Update to sqltable3.py and new sqlcustom1.py with new problem
Hi again, I've fixed one problem in sqltable3.py not returning the right object in CustomSqlEditorFactory. Also attached is a conversion of sql/custom1. This one shows badly, that I haven't yet succeeded in wrapping my mind around signals/slots nor Q_PROPERTIES. Running it doesn't show the any widgets but the save button and segfaults on exit :-(. Any help highly appreciated. TIA, Hans-Peter sqltable3.py Description: Binary data sqlcustom1.py Description: Binary data
[PyKDE] PyQt-3.2.4 for Qt 2.3.1 examples
Hi Phil et al., while failed in setup of PyQt-3.2.4 for Qt-3.0.4 (see my last mail), I'm playing with the Qt-2.3.1 version now, accompanied by Boudewijn's book, which is very nice and really helpful, by the way. Congratulations, Boudewijn! Back on track, here are my first observations: a) The themes.py example only shows the first tab label on startup. It takes at least on switch of the style to show them all.. b) Executing desktop.py says: QMutex::~QMutex: destroy failure: Device or resource busy Could this be related with qt compiled with multi thread support? As before, SuSE 7.3, Qt 2.3.1, PyQt-3.2.4 May some kind soul shred some light on this, especially (b). TIA Cheers, Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] Qt 3.0.4 and PyQt-3.2.4 install trouble
Hi, just tried to install $subject. While building Qt and PyQt was successful, PyQt throws this error message on make install: /bin/sh ../mkinstalldirs /usr/lib/python2.1/site-packages /usr/bin/install -c -m 644 qt.py /usr/lib/python2.1/site-packages/qt.py make install-data-hook make[3]: Entering directory `/home/hp/Downloads/qt/PyQt-3.2.4/qt' (cd /tmp; PYTHONPATH=/usr/lib/python2.1/site-packages:/usr/lib/python2.1/site-packages /usr/bin/python -c import qt) Traceback (most recent call last): File string, line 1, in ? File /usr/lib/python2.1/site-packages/qt.py, line 49, in ? import libqtc ImportError: /usr/lib/python2.1/site-packages/libqtcmodule.so: undefined symbol: static_QUType_ptr while objdump says, it exists: objdump -t /usr/lib/python2.1/site-packages/libqtcmodule.so | grep static_QUType_ptr *UND* static_QUType_ptr I haven't seen this one before. Any ideas? To be sure, I removed all sip and qt rudiments from site-packages and tried again, with the same results. I'm puzzled :-( /usr/lib/python2.1/site-packages: -rw-r--r--1 root root91470 8. Jun 21:43 qt.pyc -rwxr-xr-x1 root root 7513152 8. Jun 21:43 libqtcmodule-3.2.4.so* -rwxr-xr-x1 root root 910 8. Jun 21:43 libqtcmodule.la* lrwxrwxrwx1 root root 21 8. Jun 21:43 libqtcmodule.so - libqtcmodule-3.2.4.so* -rw-r--r--1 root root21518 8. Jun 21:43 qt.py -rwxr-xr-x1 root root 769 8. Jun 21:11 libsip.la* lrwxrwxrwx1 root root 15 8. Jun 21:11 libsip.so - libsip.so.9.0.3* lrwxrwxrwx1 root root 15 8. Jun 21:11 libsip.so.9 - libsip.so.9.0.3* -rwxr-xr-x1 root root 159003 8. Jun 21:11 libsip.so.9.0.3* System: SuSE 7.3 Above is running in a shell with: export QTDIR=/usr/lib/qt3 export LD_LIBRARY_PATH=$QTDIR/lib Any help highly appreciated. TIA, Hans-Peter ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] (no subject)
On Thu, 6 Jun 2002 09:26:32 GMT François CORRIHONS [EMAIL PROTECTED] wrote: Hi, I have a problem: I want to use Qt Designer both on PC and XTerm. On XTerm, no problem. But on PC, a segmentation fault (core dumped) appears each time I try to start Qt Designer. I'm using a screen emulator to connect on Linux: Reflexion X (version 7.00). I think the problem comes from that. Could you help me please?? Parse error! Please rethink your problem and come back again. Hint: PC is a synonym for a common hardware architecture, XTerm is a terminal emulation within the X Window System... Thanks a lot. Please insert coin to try again... hp ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
