From verwilst at gentoo.org Thu Aug 1 05:06:03 2002 From: verwilst at gentoo.org (Bart Verwilst) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Easy question In-Reply-To: <200207311343.03802.verwilst@gentoo.org> References: <3D474163.5D88FFFB@fluent.com> <200207311343.03802.verwilst@gentoo.org> Message-ID: <200208010457.44961.verwilst@gentoo.org> Hi Heh, i think this one's easy, but i just can't seem to find it, although i found it several weeks ago without problems.. When i select an item in my listview, only one field is selected.. How do i make it select the whole row, instead of that one field? (With QT Designer or in python itself) Thanks in advance! -- Bart Verwilst Gentoo Linux Developer, Release Coordinator Gent, Belgium From laz at strakt.com Thu Aug 1 08:45:00 2002 From: laz at strakt.com (Fredrik Juhlin) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Easy question In-Reply-To: <200208010457.44961.verwilst@gentoo.org> References: <3D474163.5D88FFFB@fluent.com> <200207311343.03802.verwilst@gentoo.org> <200208010457.44961.verwilst@gentoo.org> Message-ID: <1028184250.16148.8.camel@Raven> On Thu, 2002-08-01 at 04:57, Bart Verwilst wrote: > Hi > > When i select an item in my listview, only one field is selected.. > How do i make it select the whole row, instead of that one field? > (With QT Designer or in python itself) You're looking for QListView.setAllColumnsShowFocus(). obReadTheFineManual: I find that the nicest way to read the Qt docs is to use the Qt Assistant. It does indexing and stuff for you, so searching is a lot easier than using your average browser. I had a bit of a problem setting it up (it checks for the QTDIR variable and expects to find the documentation there, laid out in directories the way it is in the source distribution. Running Debian Linux, I had neither QTDIR set nor the documentation in such a layout) but it's worth the hassle. //Fredrik From jbublitz at nwinternet.com Thu Aug 1 11:04:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Easy question In-Reply-To: <200208010457.44961.verwilst@gentoo.org> Message-ID: On 01-Aug-02 Bart Verwilst wrote: > How do i make it select the whole row, instead of that one field? > (With QT Designer or in python itself) lv = QListView (...) lv.setAllColumnsShowFocus (1) Jim From mickey at tm.informatik.uni-frankfurt.de Thu Aug 1 12:43:01 2002 From: mickey at tm.informatik.uni-frankfurt.de (Michael Lauer) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyQt application icon on Zaurus taskbar In-Reply-To: References: Message-ID: <1028198530.21085.101.camel@gandalf.tm.informatik.uni-frankfurt.de> I'm using PyQt on the Zaurus - any idea why the icons of running PyQt-applications do not appear on the taskbar ? I am using QPEApplication and have a correct *.desktop entry. Yours, -- :M: -------------------------------------------------------------------------- Dipl.-Inf. Michael 'Mickey' Lauer mickey@tm.informatik.uni-frankfurt.de Raum 10b - ++49 69 798 28358 Fachbereich Informatik und Biologie -------------------------------------------------------------------------- From hpj at urpla.net Thu Aug 1 14:16:01 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] bad resolution on designer imported PNGs: solution In-Reply-To: <200207241441.09151.hpj@urpla.net> References: <200207241140.55684.w.richert@gmx.net> <200207241441.09151.hpj@urpla.net> Message-ID: <200208011415.00436.hpj@urpla.net> On Wednesday 24 July 2002 14:41, Hans-Peter Jansen wrote: > On Wednesday 24 July 2002 11:40, Willi Richert wrote: > > Hi, > > > > I have some nice PNG images which I want to use for the toolbar. But, > > when ddesigner/pyuic generates the icons data they don't look as good any > > more. I have to use the PNG file name instead so that they look good > > (QPixmap("forward.png")). > > > > You can see the difference in the attached picture (1,2K only). The left > > is the pyuic generated data, the right is the png given QPixmap as a file > > path. > > > > Any hints? > > I came across this a few days before. It's releated to xpm conversion > of semi transparent shadows in the PNG. I got the feeling, this isn't > supported in xpm format. Please somebody correct me, if I'm wrong. > > I'm thinking about a tool to inline the images in a module, and load > them via StringIO. Done now. You can find a first shot on this attached. img2pyqt.py: Inlines a list of images, and embed them in a Python module with appropriate code so it can be loaded into a PyQt program at runtime. The benefit is that since it is Python source code it can be delivered as a .pyc or 'compiled' into the program using freeze, py2exe, etc. Each filename is stripped from ext and non alphanumeric characters, and 3 functions are created: fileData(), fileIcon() and fileIconSet(). If file extension is not one of (png, xpm, bmp), the last two are ommited. It leaves me to the question, how pixmaps are handled internally: if the same pixmap is used multiple times, do they share memory, or does each instance occupy additional ram? Phil? What would the nicest way to integrate this with Qt designer? Anybody wrapped her/his mind around QMimeSourceFactory here? > > willi Enjoy, Hans-Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: img2pyqt.py Type: text/x-python Size: 5344 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020801/d49fe4e0/img2pyqt.py From verwilst at gentoo.org Thu Aug 1 16:17:01 2002 From: verwilst at gentoo.org (Bart Verwilst) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QPopupMenu Question In-Reply-To: <200208011415.00436.hpj@urpla.net> References: <200207241140.55684.w.richert@gmx.net> <200207241441.09151.hpj@urpla.net> <200208011415.00436.hpj@urpla.net> Message-ID: <200208011605.10177.verwilst@gentoo.org> Hello! I have a QPopup, as follows: MyPopup = QPopupMenu(self.win.lstSearch, "Popup") MyPopup.insertItem( "Function 1", self.myfunction()) MyPopup.insertItem( "Funciton 2", self.myfunction2()) MyPopup.popup(QCursor.pos()) The menu shows fine, but as soon as the menu appears, both function 1 and function 2 are executed, and then actually clicking on either one of them doesn't execute it... It's a floating popup btw, not a fixed one in a menubar.. Thanks! And thanks for the help you guys have given me so far! -- Bart Verwilst Gentoo Linux Developer, Release Coordinator Gent, Belgium From gordon at doxxx.net Thu Aug 1 16:26:00 2002 From: gordon at doxxx.net (Gordon Tyler) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QPopupMenu Question References: <200207241140.55684.w.richert@gmx.net> <200207241441.09151.hpj@urpla.net> <200208011415.00436.hpj@urpla.net> <200208011605.10177.verwilst@gentoo.org> Message-ID: <001a01c23967$4b25ac10$673c010a@sitraka.com> From: "Bart Verwilst" > I have a QPopup, as follows: > > MyPopup = QPopupMenu(self.win.lstSearch, "Popup") > MyPopup.insertItem( "Function 1", self.myfunction()) > MyPopup.insertItem( "Funciton 2", self.myfunction2()) > MyPopup.popup(QCursor.pos()) > > The menu shows fine, but as soon as the menu appears, both function 1 and > function 2 are executed, and then actually clicking on either one of them > doesn't execute it... It's a floating popup btw, not a fixed one in a > menubar.. Thanks! The syntax you have there will call myfunction when you are inserting the items into the popup. You want the following: MyPopup = QPopupMenu(self.win.lstSearch, "Popup") MyPopup.insertItem( "Function 1", self.myfunction) MyPopup.insertItem( "Funciton 2", self.myfunction2) MyPopup.popup(QCursor.pos()) Note the lack of () after self.myfunction and self.myfunction2. Without the () they refer to the functions' _object_ (functions are code objects in python) and passes that function object to the popup item as the action. Ciao, Gordon From phil at river-bank.demon.co.uk Thu Aug 1 17:16:00 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyQt application icon on Zaurus taskbar References: <1028198530.21085.101.camel@gandalf.tm.informatik.uni-frankfurt.de> Message-ID: <3D495098.7010108@river-bank.demon.co.uk> Michael Lauer wrote: > I'm using PyQt on the Zaurus - any idea why the icons of running > PyQt-applications do not appear on the taskbar ? > > I am using QPEApplication and have a correct *.desktop entry. Works fine for me with the simple example. Phil From pkropf at legato.com Thu Aug 1 19:39:01 2002 From: pkropf at legato.com (Peter Kropf) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Mac OS/X State Message-ID: I've looked through the archives and it appears that SIP and PyQT may have been working at one point but that support was removed around May-ish 2002. Since I'm interested in getting one of our PyQT applications working on OS/X, I'd like to find out where things stand. Does anyone have anything working? There's a reference to SIP v4 in the SIP 3.3.1 NEWS file. Is work being done on it? And lastly, if someone were motivated enough, what would they have to do to SIP to allow it to work on OS/X? Any pointers? Thanks! Peter Kropf Special Projects, Legato Systems 3210 Porter Drive, Palo Alto, CA 94304 650-812-6081 Desk 408-482-9427 Cell pkropf@legato.com From phil at river-bank.demon.co.uk Thu Aug 1 20:27:00 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Mac OS/X State References: Message-ID: <3D497D5D.4000405@river-bank.demon.co.uk> Peter Kropf wrote: > I've looked through the archives and it appears that SIP and PyQT may have > been working at one point but that support was removed around May-ish 2002. > Since I'm interested in getting one of our PyQT applications working on > OS/X, I'd like to find out where things stand. Does anyone have anything > working? There's a reference to SIP v4 in the SIP 3.3.1 NEWS file. Is work > being done on it? And lastly, if someone were motivated enough, what would > they have to do to SIP to allow it to work on OS/X? Any pointers? It was never working. The problem is that shared libraries and dynamically loadable modules/plugins are, strictly speaking, different things. However, SIP generated code is used as both a shared library and a loadable module - and, incidentally, breaks the Python "rules" for modules. So far this hasn't actually been a problem because UNIX and Windows can deal with it - OS/X can't. The plan is that SIP v4 will generate code that is only used as a loadable module - which should then work with OS/X. I know what I want to do - but as it's more than a simple patch, it's a question of finding the time. I imagine that I'd start work on SIP v4 towards the end of September, with initial releases towards the end of October - but very much depending on my other commitments at the time. However, as I always say, my priorities can always be changed if people start waving money at me. Phil From pkropf at legato.com Thu Aug 1 20:32:00 2002 From: pkropf at legato.com (Peter Kropf) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Mac OS/X State Message-ID: Thanks for the info. And while I'm not able to wave any money at you right now, I am willing to help out with the work that has to be done. Let me know... - Peter -----Original Message----- From: Phil Thompson [mailto:phil@river-bank.demon.co.uk] Sent: Thursday, August 01, 2002 11:27 AM To: Peter Kropf Cc: 'PyQT Mailing List (pykde@mats.gmd.de)' Subject: Re: [PyKDE] Mac OS/X State Peter Kropf wrote: > I've looked through the archives and it appears that SIP and PyQT may > have been working at one point but that support was removed around > May-ish 2002. Since I'm interested in getting one of our PyQT > applications working on OS/X, I'd like to find out where things stand. > Does anyone have anything working? There's a reference to SIP v4 in > the SIP 3.3.1 NEWS file. Is work being done on it? And lastly, if > someone were motivated enough, what would they have to do to SIP to > allow it to work on OS/X? Any pointers? It was never working. The problem is that shared libraries and dynamically loadable modules/plugins are, strictly speaking, different things. However, SIP generated code is used as both a shared library and a loadable module - and, incidentally, breaks the Python "rules" for modules. So far this hasn't actually been a problem because UNIX and Windows can deal with it - OS/X can't. The plan is that SIP v4 will generate code that is only used as a loadable module - which should then work with OS/X. I know what I want to do - but as it's more than a simple patch, it's a question of finding the time. I imagine that I'd start work on SIP v4 towards the end of September, with initial releases towards the end of October - but very much depending on my other commitments at the time. However, as I always say, my priorities can always be changed if people start waving money at me. Phil From mickey at tm.informatik.uni-frankfurt.de Thu Aug 1 23:58:01 2002 From: mickey at tm.informatik.uni-frankfurt.de (Michael Lauer) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyQt application icon on Zaurus taskbar In-Reply-To: <3D495098.7010108@river-bank.demon.co.uk> References: <1028198530.21085.101.camel@gandalf.tm.informatik.uni-frankfurt.de> <3D495098.7010108@river-bank.demon.co.uk> Message-ID: <1028239039.8198.21.camel@gandalf.tm.informatik.uni-frankfurt.de> Am Don, 2002-08-01 um 17.15 schrieb Phil Thompson: > Michael Lauer wrote: > > > I'm using PyQt on the Zaurus - any idea why the icons of running > > PyQt-applications do not appear on the taskbar ? > > > > I am using QPEApplication and have a correct *.desktop entry. > > > Works fine for me with the simple example. Thanks for your note. A further debugging inquiry showed me the source of my problem - it's in StartingAppList::isStarting(): bool StartingAppList::isStarting( const QString name ) { if ( appl ) { QTime *t = appl->dict.find( "QPE/Application/" + name ); if ( !t ) return FALSE; if ( t->elapsed() > 10000 ) { // timeout in case of crash or something appl->dict.remove( "QPE/Application/" + name ); return FALSE; } return TRUE; } return FALSE; } My application parses an xml tree before firing up the GUI - which can take more than 10 seconds - and in this case, the icon will not show up. Yours, -- :M: -------------------------------------------------------------------------- Dipl.-Inf. Michael 'Mickey' Lauer mickey@tm.informatik.uni-frankfurt.de Raum 10b - ++49 69 798 28358 Fachbereich Informatik und Biologie -------------------------------------------------------------------------- From BPettersen at narex.com Fri Aug 2 22:58:01 2002 From: BPettersen at narex.com (Bjorn Pettersen) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] SIP generated code SEGV Message-ID: <60FB8BB7F0EFC7409B75EEEC13E20192158F7F@admin56.narex.com> I've got the following simple app, embedding Python. NDate is a trivial class holding three values -- it does have a __repr__ method defined, but I don't think that is relevant(?): #include #include extern "C" SIP_IMPORT void initlibnrxc(); extern "C" SIP_IMPORT void initlibsip(); void main() { Py_Initialize(); initlibsip(); initlibnrxc(); PyObject* mainmod = PyImport_AddModule("__main__"); Py_INCREF(mainmod); PyObject* ns = PyModule_GetDict(mainmod); Py_INCREF(ns); PyRun_String("import nrx\n", Py_file_input, ns, ns); PyRun_String("x = nrx.NDate(1970,5,2)\n", Py_file_input, ns, ns); /**/ PyRun_String("x = nrx.NDate(1970,5,2)\n", Py_file_input, ns, ns); Py_DECREF(ns); Py_DECREF(mainmod); Py_Finalize(); } In debug builds, it's failing (asserts) on the line marked /**/. From the stacktrace (see below), it looks like it's failing in _Py_Dealloc as part of decrementing the reference count of x and disposing of the object. It works without problems in release builds (checked by inspecting 'x'). The assertion it is failing is (from MS's dbgheap.c): /* * If this ASSERT fails, a bad pointer has been passed in. It may be * totally bogus, or it may have been allocated from another heap. * The pointer MUST come from the 'local' heap. */ _ASSERTE(_CrtIsValidHeapPointer(pUserData)); It almost seems like the sip NDate class was allocated on the .dll's heap and then deallocated on the main program's heap, but this doesn't make sense since all access to the class is through python22_d.dll (and deleting the wrapped NDate object proceeds without any warning/assertion). I'm using sip 3.2.3 which has been modified to put "try {} catch (...) {}" around most method calls and set a Python exception and return NULL if it enters the catch block. No catch blocks are invoked in this example... Any insight would be greatly apppreciated. -- bjorn Bjorn Pettersen NAREX Inc. 303.526.4000 ext. 312 303.526.5130 fax www.narex.com NTDLL! 77f7f570() NTDLL! 77f67dc6() KERNEL32! 77e6c936() _CrtIsValidHeapPointer(const void * 0x02cd1f78) line 1697 _free_dbg_lk(void * 0x02cd1f78, int 1) line 1044 + 9 bytes _free_dbg(void * 0x02cd1f78, int 1) line 1001 + 13 bytes free(void * 0x02cd1f78) line 956 + 11 bytes _PyObject_Del(_object * 0x02cd1f78) line 143 + 10 bytes sipDeleteThis(_sipThisType * 0x02cd1f78) line 2277 + 12 bytes sipDealloc_NDate(_sipThisType * 0x02cd1f78) line 459 + 12 bytes _Py_Dealloc(_object * 0x02cd1f78) line 1826 + 7 bytes sipDtor(_object * 0x00000000, _object * 0x02ecf700) line 1243 + 65 bytes PyCFunction_Call(_object * 0x02f32b58, _object * 0x02ecf700, _object * 0x00000000) line 80 + 11 bytes PyObject_Call(_object * 0x02f32b58, _object * 0x02ecf700, _object * 0x00000000) line 1684 + 15 bytes instancemethod_call(_object * 0x02f32b58, _object * 0x02ecf700, _object * 0x00000000) line 2276 + 17 bytes PyObject_Call(_object * 0x02f00348, _object * 0x02cbb9e0, _object * 0x00000000) line 1684 + 15 bytes PyEval_CallObjectWithKeywords(_object * 0x02f00348, _object * 0x02cbb9e0, _object * 0x00000000) line 3049 + 17 bytes instance_dealloc(PyInstanceObject * 0x02f40988) line 616 + 13 bytes _Py_Dealloc(_object * 0x02f40988) line 1826 + 7 bytes insertdict(_dictobject * 0x02ee2410, _object * 0x02fdd610, long -1819822983, _object * 0x02efe460) line 373 + 59 bytes PyDict_SetItem(_object * 0x02ee2410, _object * 0x02fdd610, _object * 0x02efe460) line 541 + 21 bytes eval_frame(_frame * 0x02eeb388) line 1538 + 17 bytes PyEval_EvalCodeEx(PyCodeObject * 0x02f71f18, _object * 0x02ee2410, _object * 0x02ee2410, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * * 0x00000000, int 0, _object * 0x00000000) line 2585 + 9 bytes PyEval_EvalCode(PyCodeObject * 0x02f71f18, _object * 0x02ee2410, _object * 0x02ee2410) line 488 + 31 bytes run_node(_node * 0x02efe450, char * 0x1e17c2b4, _object * 0x02ee2410, _object * 0x02ee2410, PyCompilerFlags * 0x00000000) line 1079 + 17 bytes run_err_node(_node * 0x02efe450, char * 0x1e17c2b4, _object * 0x02ee2410, _object * 0x02ee2410, PyCompilerFlags * 0x00000000) line 1066 + 25 bytes PyRun_String(char * 0x00422074 `string', int 257, _object * 0x02ee2410, _object * 0x02ee2410) line 1009 + 37 bytes main() line 20 + 26 bytes mainCRTStartup() line 206 + 25 bytes KERNEL32! 77e7eb69() From hpj at urpla.net Sat Aug 3 13:13:00 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QSpinBox doesn't work as expected within QSqlForm Message-ID: <200208031312.26551.hpj@urpla.net> Hi *, while struggling with QSqlForms, I observed a strange bahaviour of QSpinBoxes in QSqlForms. Arrow up/down keys simply don't work. All other keyboard/mouse events are handled fine. A corresponding c++ version doesn't show this anomaly. For your convenience, I've attached my test scripts/sources. They're based on $QTDIR/examples/sql/overview/custom1 and my sql examples environment. Any hints are highly appreciated. Hans-Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: sqlcustom2.py Type: text/x-python Size: 3770 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020803/a0f7e7d9/sqlcustom2.py -------------- next part -------------- A non-text attachment was scrubbed... Name: main.cpp Type: text/x-c++src Size: 4456 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020803/a0f7e7d9/main.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: main.h Type: text/x-chdr Size: 1273 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020803/a0f7e7d9/main-0001.bin From jmamer at anderson.ucla.edu Sun Aug 4 05:16:01 2002 From: jmamer at anderson.ucla.edu (John Mamer) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] build of PyQt failed with error code 32512 Message-ID: <5.1.0.14.0.20020803200818.02549538@mail.anderson.ucla.edu> Hi, Am trying to build PyQt under Red Hat 7.1 (kernel 2.4.9). Build.py halts after printing "Generating the features file" with "qttest failed with an exit code of 32512". I've searched the archives but can't find a reference to 32512 or build problems. Any help would be appreciated. thanks j From detlev at die-offenbachs.de Sun Aug 4 21:06:00 2002 From: detlev at die-offenbachs.de (Detlev Offenbach) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] ANNOUNCE: Eric 2.1.2 released Message-ID: <200208042103.52484.detlev@majestix.gallien.de> Hi all, Eric 2.1.2 has been released today. It includes the following additional features. - Evaluate/Execute a python statement/expression in the current context of the debugged program - Change programs variables while it is being debugged - Implemented remote debugging (this is experimental, s. README for the proper setup) - Implemented the bookmark handling (add/edit/delete) for the helpviewer The first three were requested by Hans-Peter Jansen. Thanks for the input. As usual you can download it via the following links. www.die-offenbachs.de/detlev/eric.html www.die-offenbachs.de/detlev/eric_en.html (english page) www.riverbankcomputing.co.uk/pyqt (in the latest snapshot) Regards, Detlev -- Detlev Offenbach detlev@die-offenbachs.de From heikowu at ceosg.de Mon Aug 5 02:18:01 2002 From: heikowu at ceosg.de (Heiko Wundram) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyQt book Message-ID: <1028506627.23866.18.camel@d168.stw.stud.uni-saarland.de> Hello to all! I've wondered where the site of OpenDocs went as of yesterday... I tried to have a look at the book by Boudewijn Rempt, but the website www.opendocs.org just gives me a 404, even on their starting page... Dunno what's happening here... If someone could direct me to another copy of the book, I'd be more than grateful. Heiko. From phil at river-bank.demon.co.uk Mon Aug 5 19:36:00 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] build of PyQt failed with error code 32512 References: <5.1.0.14.0.20020803200818.02549538@mail.anderson.ucla.edu> Message-ID: <3D4EB73C.4060304@river-bank.demon.co.uk> John Mamer wrote: > Hi, > Am trying to build PyQt under Red Hat 7.1 (kernel 2.4.9). Build.py > halts after > printing "Generating the features file" with "qttest failed with an > exit code of 32512". > I've searched the archives but can't find a reference to 32512 or build > problems. > > Any help would be appreciated. Which versions of PyQt, Python and Qt? Phil From jouve at esrf.fr Mon Aug 5 19:39:01 2002 From: jouve at esrf.fr (Thierry JOUVE) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QHeader customization... Message-ID: <3D4E8B2C.BC621BA3@esrf.fr> Hi, I want to customize the header contained in a QTable or in a QListView... : - change the background of a section - change the font of a section's label... But, I can't reimplement the QHeader class....because I can't replace the QHeader objects in the QTable or QListVIew... But if I could redefine the "paintSection" method, everything will be ok... Any idea ?? Regars, -- Thierry JOUVE BLISS GROUP - ESRF Mail : jouve@esrf.fr, Office : 155b, Tel : 29-46 From aloy at ctv.es Mon Aug 5 19:56:00 2002 From: aloy at ctv.es (Antoni Aloy =?iso-8859-1?q?L=F3pez?=) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyKde 3.0.2 Message-ID: <200208052000.14454.aloy@ctv.es> Hi! I suppose it should be a FAQ, but anybody has an idea about when we could have pyKDE bindings for KDE 3.0.2? I could make some tests or help if necessari, but I have no experience with making binding. -- Antoni Aloy L?pez Binissalem - Mallorca Linux Registered User # 210825 Gentoo Powered From phil at river-bank.demon.co.uk Mon Aug 5 20:14:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QSpinBox doesn't work as expected within QSqlForm References: <200208031312.26551.hpj@urpla.net> Message-ID: <3D4EC032.7090309@river-bank.demon.co.uk> Hans-Peter Jansen wrote: > Hi *, > > while struggling with QSqlForms, I observed a strange bahaviour of > QSpinBoxes in QSqlForms. Arrow up/down keys simply don't work. All > other keyboard/mouse events are handled fine. A corresponding c++ > version doesn't show this anomaly. > > For your convenience, I've attached my test scripts/sources. > They're based on $QTDIR/examples/sql/overview/custom1 and my sql > examples environment. > > Any hints are highly appreciated. It worked fine for me. Phil From jbublitz at nwinternet.com Mon Aug 5 20:31:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyKde 3.0.2 In-Reply-To: <200208052000.14454.aloy@ctv.es> Message-ID: On 05-Aug-02 Antoni Aloy López wrote: > I suppose it should be a FAQ, but anybody has an idea about when > we could have pyKDE bindings for KDE 3.0.2? Any day now - basically what's left to do is generate the docs, test the builds on a couple more versions, and package it for release. It's just been difficult to find the time to complete it. > I could make some tests or help if necessari, but I have no > experience with making binding. Once it's released, any bug reports or build problems posted here would be greatly appreciated. Jim From hpj at urpla.net Tue Aug 6 13:43:00 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QSpinBox doesn't work as expected within QSqlForm In-Reply-To: <3D4EC032.7090309@river-bank.demon.co.uk> References: <200208031312.26551.hpj@urpla.net> <3D4EC032.7090309@river-bank.demon.co.uk> Message-ID: <200208061342.21669.hpj@urpla.net> On Monday 05 August 2002 20:13, Phil Thompson wrote: > Hans-Peter Jansen wrote: > > Hi *, > > > > while struggling with QSqlForms, I observed a strange bahaviour of > > QSpinBoxes in QSqlForms. Arrow up/down keys simply don't work. All > > other keyboard/mouse events are handled fine. A corresponding c++ > > version doesn't show this anomaly. > > > > For your convenience, I've attached my test scripts/sources. > > They're based on $QTDIR/examples/sql/overview/custom1 and my sql > > examples environment. > > > > Any hints are highly appreciated. > > It worked fine for me. > > Phil Take Two: I finally found out, that this effect isn't related to QSqlForms. Please, everybody, who can spend three minutes: run the attached script, and check, if both spinboxes can be controlled with the arrow keys. Top spinbox is a Qt native one, below is a reimplemented one with a custom eventFilter. This one is working fine for me, but the first isn't (Qt 3.0.4, PyQt 3.3.2, Python 2.1.1, Linux) All other events seem to work fine, including wheel events, BTW. Thanks in advance, Hans-Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: sbform2.py Type: text/x-python Size: 1824 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020806/f2e0373a/sbform2.py From hpj at urpla.net Tue Aug 6 13:54:01 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Problem connecting to QDataBrowser.currentChanged Message-ID: <200208061353.18003.hpj@urpla.net> Hi, attached is a sql example, which stores images in a database. In order to control its behaviour, I would like to connect to the currentChanged(const QSqlRecord *) signal. But it results in: Traceback (most recent call last): File "./runform3.py", line 32, in polish self.currentChanged) RuntimeError: Signal has wrong argument types for slot Traceback (most recent call last): File "./runform3.py", line 32, in polish self.currentChanged) RuntimeError: Signal has wrong argument types for slot Traceback (most recent call last): File "./runform3.py", line 32, in polish self.currentChanged) RuntimeError: Signal has wrong argument types for slot Traceback (most recent call last): File "./runform3.py", line 32, in polish self.currentChanged) RuntimeError: Signal has wrong argument types for slot Signal handler is defined as follows: def currentChanged(self, rec): The question is, how do I specify a const QSqlRecord * parameter in my signal handler? TIA, Hans-Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: runform3.py Type: text/x-python Size: 8354 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020806/3e502c86/runform3.py -------------- next part -------------- A non-text attachment was scrubbed... Name: testform3.ui Type: application/x-designer Size: 22481 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020806/3e502c86/testform3.bin -------------- next part -------------- use testdb; #drop table test; create table test (id integer primary key auto_increment, name varchar(100) not null default '', file varchar(255) not null default '', descr text not null, image mediumblob not null, chgts timestamp); From phil at river-bank.demon.co.uk Tue Aug 6 14:00:00 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QSpinBox doesn't work as expected within QSqlForm References: <200208031312.26551.hpj@urpla.net> <3D4EC032.7090309@river-bank.demon.co.uk> <200208061342.21669.hpj@urpla.net> Message-ID: <3D4FBA28.2020906@river-bank.demon.co.uk> Hans-Peter Jansen wrote: > On Monday 05 August 2002 20:13, Phil Thompson wrote: > >>Hans-Peter Jansen wrote: >> >>>Hi *, >>> >>>while struggling with QSqlForms, I observed a strange bahaviour of >>>QSpinBoxes in QSqlForms. Arrow up/down keys simply don't work. All >>>other keyboard/mouse events are handled fine. A corresponding c++ >>>version doesn't show this anomaly. >>> >>>For your convenience, I've attached my test scripts/sources. >>>They're based on $QTDIR/examples/sql/overview/custom1 and my sql >>>examples environment. >>> >>>Any hints are highly appreciated. >>> >>It worked fine for me. >> >>Phil >> > > Take Two: > > I finally found out, that this effect isn't related to QSqlForms. > > Please, everybody, who can spend three minutes: run the attached > script, and check, if both spinboxes can be controlled with the > arrow keys. > > Top spinbox is a Qt native one, below is a reimplemented > one with a custom eventFilter. This one is working fine for me, > but the first isn't (Qt 3.0.4, PyQt 3.3.2, Python 2.1.1, Linux) > All other events seem to work fine, including wheel events, BTW. Both work fine for me. Qt 3.0.5, latest PyQt snapshot, Python 2.2.1. Phil From boud at valdyas.org Tue Aug 6 14:14:00 2002 From: boud at valdyas.org (Boudewijn Rempt) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QSpinBox doesn't work as expected within QSqlForm In-Reply-To: <200208061342.21669.hpj@urpla.net> References: <200208031312.26551.hpj@urpla.net> <3D4EC032.7090309@river-bank.demon.co.uk> <200208061342.21669.hpj@urpla.net> Message-ID: <200208061411.53119.boud@valdyas.org> On Tuesday 06 August 2002 13:42, Hans-Peter Jansen wrote: > > Take Two: > > I finally found out, that this effect isn't related to QSqlForms. > > Please, everybody, who can spend three minutes: run the attached > script, and check, if both spinboxes can be controlled with the > arrow keys. > > Top spinbox is a Qt native one, below is a reimplemented > one with a custom eventFilter. This one is working fine for me, > but the first isn't (Qt 3.0.4, PyQt 3.3.2, Python 2.1.1, Linux) > All other events seem to work fine, including wheel events, BTW. > Doesn't work for me either, with the same configuration; I'll test the latest of the latest some time soon, since Phil reports that it works for him. -- Boudewijn Rempt | http://www.valdyas.org From w.richert at gmx.net Tue Aug 6 15:41:01 2002 From: w.richert at gmx.net (Willi Richert) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QSpinBox doesn't work as expected within QSqlForm In-Reply-To: <200208061342.21669.hpj@urpla.net> References: <200208031312.26551.hpj@urpla.net> <3D4EC032.7090309@river-bank.demon.co.uk> <200208061342.21669.hpj@urpla.net> Message-ID: <200208061540.33056.w.richert@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Works fine for me. PyQt 3.3.2 Qt 3.0.3 Python 2.2 On Tuesday 06 August 2002 13:42, Hans-Peter Jansen wrote: > On Monday 05 August 2002 20:13, Phil Thompson wrote: > > Hans-Peter Jansen wrote: > > > Hi *, > > > > > > while struggling with QSqlForms, I observed a strange bahaviour of > > > QSpinBoxes in QSqlForms. Arrow up/down keys simply don't work. All > > > other keyboard/mouse events are handled fine. A corresponding c++ > > > version doesn't show this anomaly. > > > > > > For your convenience, I've attached my test scripts/sources. > > > They're based on $QTDIR/examples/sql/overview/custom1 and my sql > > > examples environment. > > > > > > Any hints are highly appreciated. > > > > It worked fine for me. > > > > Phil > > Take Two: > > I finally found out, that this effect isn't related to QSqlForms. > > Please, everybody, who can spend three minutes: run the attached > script, and check, if both spinboxes can be controlled with the > arrow keys. > > Top spinbox is a Qt native one, below is a reimplemented > one with a custom eventFilter. This one is working fine for me, > but the first isn't (Qt 3.0.4, PyQt 3.3.2, Python 2.1.1, Linux) > All other events seem to work fine, including wheel events, BTW. > > Thanks in advance, > Hans-Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9T9HRClnsru/vnVgRArnJAKDG6p2cKw/t1309GiGhO7o42oX/CgCfbWUb Kdng6HnTWC7M6EeoBVaDYQc= =jmo1 -----END PGP SIGNATURE----- From jjl at pobox.com Tue Aug 6 15:45:01 2002 From: jjl at pobox.com (John J. Lee) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QHeader customization... In-Reply-To: <3D4E8B2C.BC621BA3@esrf.fr> Message-ID: On Mon, 5 Aug 2002, Thierry JOUVE wrote: > I want to customize the header contained in a QTable or in a > QListView... : > - change the background of a section > - change the font of a section's label... > > But, I can't reimplement the QHeader class....because I can't replace > the QHeader objects in the QTable or QListVIew... But if I could > redefine the "paintSection" method, everything will be ok... > > Any idea ?? This was discussed either here or on the Qt mailing list (qt-interest) a few months ago, I think (relating to QTable, IIRC). I think it was probably the Qt list. Sorry, I don't remember what the solution was, but try searching the archives. John From hpj at urpla.net Tue Aug 6 16:06:00 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QSpinBox doesn't work as expected within QSqlForm In-Reply-To: <3D4FBA28.2020906@river-bank.demon.co.uk> References: <200208031312.26551.hpj@urpla.net> <200208061342.21669.hpj@urpla.net> <3D4FBA28.2020906@river-bank.demon.co.uk> Message-ID: <200208061605.21657.hpj@urpla.net> On Tuesday 06 August 2002 13:59, Phil Thompson wrote: > Hans-Peter Jansen wrote: > > On Monday 05 August 2002 20:13, Phil Thompson wrote: > >>Hans-Peter Jansen wrote: > >>>Hi *, > >>> > >>>while struggling with QSqlForms, I observed a strange bahaviour of > >>>QSpinBoxes in QSqlForms. Arrow up/down keys simply don't work. All > >>>other keyboard/mouse events are handled fine. A corresponding c++ > >>>version doesn't show this anomaly. > >>> > >>>For your convenience, I've attached my test scripts/sources. > >>>They're based on $QTDIR/examples/sql/overview/custom1 and my sql > >>>examples environment. > >>> > >>>Any hints are highly appreciated. > >> > >>It worked fine for me. > >> > >>Phil > > > > Take Two: > > > > I finally found out, that this effect isn't related to QSqlForms. > > > > Please, everybody, who can spend three minutes: run the attached > > script, and check, if both spinboxes can be controlled with the > > arrow keys. > > > > Top spinbox is a Qt native one, below is a reimplemented > > one with a custom eventFilter. This one is working fine for me, > > but the first isn't (Qt 3.0.4, PyQt 3.3.2, Python 2.1.1, Linux) > > All other events seem to work fine, including wheel events, BTW. > > Both work fine for me. Qt 3.0.5, latest PyQt snapshot, Python 2.2.1. With sip-snapshot-20020714, PyQt-snapshot-20020805, but keeping Qt, it doesn't work either. So it's maybe a Qt 3.0.4 (build) issue here. Do you have any debugging hints for such a case? Seems, I will need to go thru the 3.0.5 hassle :-( Hans-Peter > Phil From hpj at urpla.net Tue Aug 6 16:21:01 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Problem connecting to QDataBrowser.currentChanged In-Reply-To: <200208061353.18003.hpj@urpla.net> References: <200208061353.18003.hpj@urpla.net> Message-ID: <200208061619.57448.hpj@urpla.net> These lines where missing in my first mail: BTW: if you're interested in PyQt database programming, have a look into runform3.py. When uncommenting the possibly offending lines: self.connect(self.ImageDataBrowser, SIGNAL("currentChanged(const QSqlRecord *)"), self.currentChanged) in runform3.py mainWindow.polish(), it's a nice sql based image browser with some problems mostly solved, when facing sql TEXT and BLOB fields. I have still to solve sql mode dependant handling under certain conditions (after bulk import). Setup with: cp runform3.py testform3.ui test.sql $PYQTDIR/examples3/SQL cd $PYQTDIR/examples3/SQL mysql < test.sql pyuic testform3.ui -o testform3.py python runform3.py Have fun, Hans-Peter From hpj at urpla.net Tue Aug 6 16:21:14 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QSpinBox doesn't work as expected within QSqlForm In-Reply-To: <200208061411.53119.boud@valdyas.org> References: <200208031312.26551.hpj@urpla.net> <200208061342.21669.hpj@urpla.net> <200208061411.53119.boud@valdyas.org> Message-ID: <200208061619.53879.hpj@urpla.net> On Tuesday 06 August 2002 14:11, Boudewijn Rempt wrote: > On Tuesday 06 August 2002 13:42, Hans-Peter Jansen wrote: > > Take Two: > > > > I finally found out, that this effect isn't related to QSqlForms. > > > > Please, everybody, who can spend three minutes: run the attached > > script, and check, if both spinboxes can be controlled with the > > arrow keys. > > > > Top spinbox is a Qt native one, below is a reimplemented > > one with a custom eventFilter. This one is working fine for me, > > but the first isn't (Qt 3.0.4, PyQt 3.3.2, Python 2.1.1, Linux) > > All other events seem to work fine, including wheel events, BTW. > > Doesn't work for me either, with the same configuration; I'll test > the latest of the latest some time soon, since Phil reports that > it works for him. That's the pity! Just confirmed, with sip-snapshot-20020714 and PyQt-snapshot-20020805 it doesn't work either. Thanks for the feedback, Boudewijn. BTW: I'm currently working on a customized QDataBrowser class to support foreign fields and add the missing search and print capabilities... QSql* and QData* is a whole little universe folded in the Qt one, where grasping can be bitchy... Hans-Peter From fredan-pykde at fredan.org Tue Aug 6 19:47:01 2002 From: fredan-pykde at fredan.org (fredrik danerklint) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QSpinBox Message-ID: <200208061948.37558.fredan-pykde@fredan.org> >Please, everybody, who can spend three minutes: run the attached >script, and check, if both spinboxes can be controlled with the >arrow keys. The first doesn't work, but the second does. sip-3.3.2, qt-3.0.5, PyQT-3.3.2 -- //fredan From phil at river-bank.demon.co.uk Tue Aug 6 19:52:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Problem connecting to QDataBrowser.currentChanged References: <200208061353.18003.hpj@urpla.net> Message-ID: <3D500C8D.4000503@river-bank.demon.co.uk> Hans-Peter Jansen wrote: > Hi, > > attached is a sql example, which stores images in a database. In order > to control its behaviour, I would like to connect to the > currentChanged(const QSqlRecord *) signal. But it results in: > > Traceback (most recent call last): > File "./runform3.py", line 32, in polish > self.currentChanged) > RuntimeError: Signal has wrong argument types for slot > Traceback (most recent call last): > File "./runform3.py", line 32, in polish > self.currentChanged) > RuntimeError: Signal has wrong argument types for slot > Traceback (most recent call last): > File "./runform3.py", line 32, in polish > self.currentChanged) > RuntimeError: Signal has wrong argument types for slot > Traceback (most recent call last): > File "./runform3.py", line 32, in polish > self.currentChanged) > RuntimeError: Signal has wrong argument types for slot > > Signal handler is defined as follows: > def currentChanged(self, rec): > > The question is, how do I specify a const QSqlRecord * parameter > in my signal handler? It's a SIP code generator bug. Re-build your PyQt source with tonight's SIP snapshot. Phil From hpj at urpla.net Wed Aug 7 00:00:01 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QSpinBox doesn't work as expected within QSqlForm In-Reply-To: <3D4FBA28.2020906@river-bank.demon.co.uk> References: <200208031312.26551.hpj@urpla.net> <200208061342.21669.hpj@urpla.net> <3D4FBA28.2020906@river-bank.demon.co.uk> Message-ID: <200208062358.39074.hpj@urpla.net> Thanks to everybody, who gave feedback. To summarize: Problem is reproducible under Qt 3.0.4, seems not depending on the PyQt nor the Python version, as reported from Boudewijn and Detlev and me. Neither Qt 3.0.3 nor Qt 3.0.5 show this effect, as reported from Willi, Peter and yourself. The real pain is, it works in c++, thus Qt seems to be innocent here. Oh well, digging time... Any ideas welcome! Hans-Peter On Tuesday 06 August 2002 13:59, Phil Thompson wrote: > Hans-Peter Jansen wrote: > > On Monday 05 August 2002 20:13, Phil Thompson wrote: > >>Hans-Peter Jansen wrote: > >>>Hi *, > >>> > >>>while struggling with QSqlForms, I observed a strange bahaviour of > >>>QSpinBoxes in QSqlForms. Arrow up/down keys simply don't work. All > >>>other keyboard/mouse events are handled fine. A corresponding c++ > >>>version doesn't show this anomaly. > >>> > >>>For your convenience, I've attached my test scripts/sources. > >>>They're based on $QTDIR/examples/sql/overview/custom1 and my sql > >>>examples environment. > >>> > >>>Any hints are highly appreciated. > >> > >>It worked fine for me. > >> > >>Phil > > > > Take Two: > > > > I finally found out, that this effect isn't related to QSqlForms. > > > > Please, everybody, who can spend three minutes: run the attached > > script, and check, if both spinboxes can be controlled with the > > arrow keys. > > > > Top spinbox is a Qt native one, below is a reimplemented > > one with a custom eventFilter. This one is working fine for me, > > but the first isn't (Qt 3.0.4, PyQt 3.3.2, Python 2.1.1, Linux) > > All other events seem to work fine, including wheel events, BTW. > > Both work fine for me. Qt 3.0.5, latest PyQt snapshot, Python 2.2.1. > > Phil From hpj at urpla.net Wed Aug 7 00:11:01 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QSpinBox doesn't work as expected within QSqlForm In-Reply-To: <200208062358.39074.hpj@urpla.net> References: <200208031312.26551.hpj@urpla.net> <3D4FBA28.2020906@river-bank.demon.co.uk> <200208062358.39074.hpj@urpla.net> Message-ID: <200208070009.45831.hpj@urpla.net> On Tuesday 06 August 2002 23:58, Hans-Peter Jansen wrote: > Thanks to everybody, who gave feedback. > > To summarize: > Problem is reproducible under Qt 3.0.4, seems not depending on the > PyQt nor the Python version, as reported from Boudewijn and Detlev > and me. > > Neither Qt 3.0.3 nor Qt 3.0.5 show this effect, as reported from > Willi, Peter and yourself. The real pain is, it works in c++, thus > Qt seems to be innocent here. > > Oh well, digging time... Any ideas welcome! > Hans-Peter and I forgot Fredrik, who is the first one, who confirmed the problem with Qt 3.0.5, thus I was on the wrong track (suspecting some bad interaction between PyQt and Qt). Hans-Peter From hpj at urpla.net Wed Aug 7 00:17:01 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Problem connecting to QDataBrowser.currentChanged In-Reply-To: <3D500C8D.4000503@river-bank.demon.co.uk> References: <200208061353.18003.hpj@urpla.net> <3D500C8D.4000503@river-bank.demon.co.uk> Message-ID: <200208070016.17212.hpj@urpla.net> On Tuesday 06 August 2002 19:51, Phil Thompson wrote: > > The question is, how do I specify a const QSqlRecord * parameter > > in my signal handler? > > It's a SIP code generator bug. Re-build your PyQt source with tonight's > SIP snapshot. > Phil Thanks, will check it tomorrow (as it's not available by now). How do you like it? Is it worth adding to the examples (after fixing some obvious problems)? Hans-Peter From mickey at tm.informatik.uni-frankfurt.de Wed Aug 7 12:16:01 2002 From: mickey at tm.informatik.uni-frankfurt.de (Michael Lauer) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyQt for Qt _and_ Qt/E Message-ID: <1028715310.22632.15.camel@gandalf.tm.informatik.uni-frankfurt.de> Hi, we are working on an application which runs on iPAQs and x86 desktop PCs. It should adapt itself to the underlying environment by automatically choosing qt or qt/embedded. Now we have some kludges for this (e.g. seperate python installations), but what is the _recommended_ practice for this? Would it be easily possible to rename the Qt/Embedded modul to qte and thus switching by "import qt" / "import qte"? Or should I use PYTHONPATH tricks together with a qt/qte wrapper module which automaticall uses the "real" lowlevel libqtcmodule.so ? Please share your ideas with me. Yours, -- :M: -------------------------------------------------------------------------- Dipl.-Inf. Michael 'Mickey' Lauer mickey@tm.informatik.uni-frankfurt.de Raum 10b - ++49 69 798 28358 Fachbereich Informatik und Biologie -------------------------------------------------------------------------- From phil at river-bank.demon.co.uk Wed Aug 7 13:24:00 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyQt for Qt _and_ Qt/E References: <1028715310.22632.15.camel@gandalf.tm.informatik.uni-frankfurt.de> Message-ID: <3D51031F.1050301@river-bank.demon.co.uk> Michael Lauer wrote: > Hi, > > we are working on an application which runs on iPAQs and > x86 desktop PCs. It should adapt itself to the underlying environment > by automatically choosing qt or qt/embedded. Now we have > some kludges for this (e.g. seperate python installations), but what is > the _recommended_ practice for this? Would it be easily possible to > rename the Qt/Embedded modul to qte and thus switching by > "import qt" / "import qte"? Or should I use PYTHONPATH tricks > together with a qt/qte wrapper module which automaticall uses > the "real" lowlevel libqtcmodule.so ? > > Please share your ideas with me. You are implying that you are going to have both Qt and Qt/E installed on both the PCs and the iPAQs - which doesn't seem to make much sense. If not then it's only your app that cares and it should be able to determine at run time what features are present or absent. Or am I missing something? Phil From mickey at tm.informatik.uni-frankfurt.de Wed Aug 7 13:45:01 2002 From: mickey at tm.informatik.uni-frankfurt.de (Michael Lauer) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyQt for Qt _and_ Qt/E In-Reply-To: <3D51031F.1050301@river-bank.demon.co.uk> References: <1028715310.22632.15.camel@gandalf.tm.informatik.uni-frankfurt.de> <3D51031F.1050301@river-bank.demon.co.uk> Message-ID: <1028720662.22632.20.camel@gandalf.tm.informatik.uni-frankfurt.de> > You are implying that you are going to have both Qt and Qt/E installed > on both the PCs and the iPAQs - which doesn't seem to make much sense. Well, for us it makes sense, because actual development happens _only_ on the PC where we also have qvfb and qt/embedded. Now the choice if we have to use Qt/E or Qt depends on if the qvfb is running. So, the question remains: How can I have one python installation with both Qt and Qt/E available except using PYTHONPATH and LD_LIBRARY_PATH tricks. Yours, -- :M: -------------------------------------------------------------------------- Dipl.-Inf. Michael 'Mickey' Lauer mickey@tm.informatik.uni-frankfurt.de Raum 10b - ++49 69 798 28358 Fachbereich Informatik und Biologie -------------------------------------------------------------------------- From hpj at urpla.net Wed Aug 7 16:16:01 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyQt for Qt _and_ Qt/E In-Reply-To: <1028720662.22632.20.camel@gandalf.tm.informatik.uni-frankfurt.de> References: <1028715310.22632.15.camel@gandalf.tm.informatik.uni-frankfurt.de> <3D51031F.1050301@river-bank.demon.co.uk> <1028720662.22632.20.camel@gandalf.tm.informatik.uni-frankfurt.de> Message-ID: <200208071615.27401.hpj@urpla.net> On Wednesday 07 August 2002 13:44, Michael Lauer wrote: > > You are implying that you are going to have both Qt and Qt/E installed > > on both the PCs and the iPAQs - which doesn't seem to make much sense. > > Well, for us it makes sense, because actual development happens _only_ > on the PC where we also have qvfb and qt/embedded. Now the choice if we > have to use Qt/E or Qt depends on if the qvfb is running. So, the > question remains: How can I have one python installation with both Qt > and Qt/E available except using PYTHONPATH and LD_LIBRARY_PATH tricks. > > Yours, I would start with a simple command line switch, and fiddle with automatics later. Hans-Peter From P.FREMY at OBERTHURCS.com Wed Aug 7 17:28:00 2002 From: P.FREMY at OBERTHURCS.com (Philippe FREMY) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Problem compiling PyQt Message-ID: <191CBBF91062D411855D00D0B76F1C30E23A43@PROXIMA> Hi, I am compiling latest PyQt 3.3.2 on Windows 2000, with visual 6 and Python 2.2 from ActiveState. I am getting the error: d:/software/PyQt-3.3.2 > nmake Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cd qt nmake Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. link /NOLOGO /DEBUG /SUBSYSTEM:windows /DLL /OUT:d:\software\Python22\Li b\site-packages\libqtc.pyd @c:\WINNT\TEMP\nma01708. LINK : fatal error LNK1104: cannot open file "python22_d.lib" NMAKE : fatal error U1077: 'link' : return code '0x450' Stop. NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio\VC98\bin\n make.exe"' : return code '0x2' I checked, I haven't got any python22_d.lib file on my harddrive. I have however a python22.lib . How do I switch from one to the other ? regards, Philippe From phil at river-bank.demon.co.uk Wed Aug 7 17:34:00 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Problem compiling PyQt References: <191CBBF91062D411855D00D0B76F1C30E23A43@PROXIMA> Message-ID: <3D513DDA.60205@river-bank.demon.co.uk> Philippe FREMY wrote: > > Hi, > > I am compiling latest PyQt 3.3.2 on Windows 2000, with visual 6 and Python > 2.2 from ActiveState. > > I am getting the error: > > d:/software/PyQt-3.3.2 > nmake > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > cd qt > nmake > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > link /NOLOGO /DEBUG /SUBSYSTEM:windows /DLL > /OUT:d:\software\Python22\Li > b\site-packages\libqtc.pyd @c:\WINNT\TEMP\nma01708. > LINK : fatal error LNK1104: cannot open file "python22_d.lib" > NMAKE : fatal error U1077: 'link' : return code '0x450' > Stop. > NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual > Studio\VC98\bin\n > make.exe"' : return code '0x2' > > I checked, I haven't got any python22_d.lib file on my harddrive. I have > however a python22.lib . How do I switch from one to the other ? I'm not sure how you've got the /DEBUG switch specified as qmake will be adding this. How did you build Qt? Phil From P.FREMY at OBERTHURCS.com Wed Aug 7 18:09:01 2002 From: P.FREMY at OBERTHURCS.com (Philippe FREMY) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Problem compiling PyQt Message-ID: <191CBBF91062D411855D00D0B76F1C30E23A93@PROXIMA> > > d:/software/PyQt-3.3.2 > nmake > > > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > > > cd qt > > nmake > > > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > > > link /NOLOGO /DEBUG /SUBSYSTEM:windows /DLL > > /OUT:d:\software\Python22\Li > > b\site-packages\libqtc.pyd @c:\WINNT\TEMP\nma01708. > > LINK : fatal error LNK1104: cannot open file "python22_d.lib" > > NMAKE : fatal error U1077: 'link' : return code '0x450' > > Stop. > > NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual > > Studio\VC98\bin\n > > make.exe"' : return code '0x2' > > > > I checked, I haven't got any python22_d.lib file on my harddrive. I have > > however a python22.lib . How do I switch from one to the other ? > > > I'm not sure how you've got the /DEBUG switch specified as qmake will be > adding this. How did you build Qt? My Qt was built from source with the debug flag. Does it influence ? Philippe From phil at river-bank.demon.co.uk Wed Aug 7 18:15:02 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Problem compiling PyQt References: <191CBBF91062D411855D00D0B76F1C30E23A93@PROXIMA> Message-ID: <3D51475E.1030708@river-bank.demon.co.uk> Philippe FREMY wrote: >>>d:/software/PyQt-3.3.2 > nmake >>> >>>Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 >>>Copyright (C) Microsoft Corp 1988-1998. All rights reserved. >>> >>> cd qt >>> nmake >>> >>>Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 >>>Copyright (C) Microsoft Corp 1988-1998. All rights reserved. >>> >>> link /NOLOGO /DEBUG /SUBSYSTEM:windows /DLL >>>/OUT:d:\software\Python22\Li >>>b\site-packages\libqtc.pyd @c:\WINNT\TEMP\nma01708. >>>LINK : fatal error LNK1104: cannot open file "python22_d.lib" >>>NMAKE : fatal error U1077: 'link' : return code '0x450' >>>Stop. >>>NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual >>>Studio\VC98\bin\n >>>make.exe"' : return code '0x2' >>> >>>I checked, I haven't got any python22_d.lib file on my harddrive. I have >>>however a python22.lib . How do I switch from one to the other ? >>> >> >>I'm not sure how you've got the /DEBUG switch specified as qmake will be >>adding this. How did you build Qt? >> > > My Qt was built from source with the debug flag. Does it influence ? It looks like it does. Phil From fredan-pykde at fredan.org Wed Aug 7 19:24:01 2002 From: fredan-pykde at fredan.org (fredrik danerklint) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] LCD problems Message-ID: <200208071925.53927.fredan-pykde@fredan.org> Hi! I've just start to lern python and PyQT, so this is probably an easy question which I haven't find any solution to... What I would like to happen is to make sure that the LCD display gets updated from the thread. So, how do I do that? import sys from qt import * class mythread(QThread): def __init__(self,widget, *args): self.i = 0 self.w = widget apply(QThread.__init__, (self, ) + args) def run(self): while self.i < 20: self.i = self.i + 1 self.w.LCDNumber1.display(self.i) self.msleep(100) print "bye from thread!" class PlayerForm(QWidget): def __init__(self,parent = None,name = None,fl = 0): QWidget.__init__(self,parent,name,fl) if name == None: self.setName("Form1") self.resize(417,173) self.setCaption(self.trUtf8("Form1")) self.LCDNumber1 = QLCDNumber(10,self,"LCDNumber1") self.LCDNumber1.setGeometry(QRect(10,10,200,50)) if __name__ == "__main__": a = QApplication(sys.argv) QObject.connect(a,SIGNAL("lastWindowClosed()"),a,SLOT("quit()")) w = PlayerForm() t = mythread(w) a.setMainWidget(w) w.show() t.start() a.exec_loop() t.wait() -- //fredan From detlev at die-offenbachs.de Wed Aug 7 19:43:00 2002 From: detlev at die-offenbachs.de (Detlev Offenbach) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] ANNOUNCE: Eric 2.1.2 released In-Reply-To: References: Message-ID: <200208071941.13156.detlev@majestix.gallien.de> Am Mittwoch, 7. August 2002 00:22 schrieb Peter Kropf: > Just to let you know, build.py doesn't work with PyQt 3.3.1. There's > an attempt to convert PYQT_VERSION into a float that fails since the > value is 3.3.1... Thanks for the bug report. Please use "float(PYQT_VERSION[:3])" instead of "float(PYQT_VERSION)". The bug fix will be in the next standalone release. > > - Peter > > [snip] Detlev -- Detlev Offenbach detlev@die-offenbachs.de From phil at river-bank.demon.co.uk Wed Aug 7 19:51:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] LCD problems References: <200208071925.53927.fredan-pykde@fredan.org> Message-ID: <3D515DF5.3010809@river-bank.demon.co.uk> fredrik danerklint wrote: > Hi! > > I've just start to lern python and PyQT, so this is probably an easy question > which I haven't find any solution to... > > What I would like to happen is to make sure that the LCD display gets updated > from the thread. So, how do I do that? Change... self.w.LCDNumber1.display(self.i) ...to... qApp.lock() self.w.LCDNumber1.display(self.i) qApp.unlock() Phil From jbublitz at nwinternet.com Thu Aug 8 11:06:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyKDE Release (almost) Message-ID: The next PyKDE release (covering KDE 3.01 and 3.0.2) should be available for download by the weekend. Basically I need to check it over, put the tarballs together and send them to Phil, which I should get done tomorrow. The only major changes (other than bug fixes and upgrading through KDE 3.0.2) is in the build system - it now uses the same system as PyQt. Rather than run ./configure, you need to run: KDE2: python build.py -l qt -c KDE3: python build.py -l qt-mt -c and then 'make' and 'make install' as root. The explicit -l switch is required at the moment. The -c switch is optional - including it reduces the compile time by about 80%, but requires a fair amount of available memory when compiling (this is the cpp file concatenation trick). This should be the same command line you used to build PyQt. There is one problem with PyKDE on KDE3 that's had me hung up the last few days: the pyParts.py example using KView as a part. I've been getting truely bizarre behavior and initially it looked like a PyKDE problem (segfaulting). Finally I got it somewhat stable, but the functions (scaling/rotating/resetting) still didn't work. Trying the same thing in konqueror (using the embedded KView) yields the same results and hangs konqueror, so it's fairly safe to assume the problem is with KView. The KHTML/KParts example works perfectly and uses mostly the same code (but a different KPart). Jim From san at nnov.matra-dtv.fr Thu Aug 8 14:53:00 2002 From: san at nnov.matra-dtv.fr (Sergey ANIKIN) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Using PyQt in my .sip file leads to several problems Message-ID: <3D526858.7020506@nnov.matra-dtv.fr> Domain: Linux C++ Qt-2.2.2 PyQt-3.3.2 sip-3.3.2 I'm trying to write a small C++ class with one method retuning the desktop widget for my application. I would like my method to be called from Python script to use the widget returned as a parent for PyQt dialogs. I do the following: // desktop.h: #include class Desktop { public: static QWidget* getDesktop(); }; // desktop.cxx: #include QWidget* Desktop::getDesktop() { return qApp::desktop(); } // desktop.sip: %Module Desktop # FIRST PROBLEM: I had to include almost all PyQt .sip files here in order to make SIP work without errors. Otherwise, it reports "QWidget is not defined", etc. # Is it right? %Include versions.sip %Include qglobal.sip ... %Include qwidget.sip ... class Desktop { %HeaderCode #include %End public: static QWidget* getDesktop(); }; SECOND PROBLEM: Well, I processed desktop.sip with SIP and it produced more than 400 (!) .cc and .h files. I guess it practically duplicated those of PyQt except my Desktop files. Can I do anything to reduce the number of SIP-generated files to a reasonable extent? THIRD PROBLEM: Three of intermediate .cc/.h files include PyQt intermediate files (sipqtQObject.h, sipqtQWidget.h and sipqtQFileInfo.h;these files are included directly by PyQt .sip files). I had to edit the intermediate files manually in order to include my versions of the files (sipDesktopQObject.h, etc.). Perhaps this results from the FIRST PROBLEM. Who knows how to avoid this? FOURTH PROBLEM: When I try to compile intermediate .cc/.h files with GCC I get the following errors: /users/san/PyQt-3.3.2/sip/qobject.sip: In function `PyObject *PyQtGetQObjectPythonClass (const QObject *)': /users/san/PyQt-3.3.2/sip/qobject.sip:684: `sipName_qt_QAccel' undeclared (first use this function) /users/san/PyQt-3.3.2/sip/qobject.sip:684: (Each undeclared identifier is reported only once for each function it appears in.) /users/san/PyQt-3.3.2/sip/qobject.sip:686: `sipName_qt_QAction' undeclared (first use this function) /users/san/PyQt-3.3.2/sip/qobject.sip:687: `sipName_qt_QActionGroup' undeclared (first use this function) /users/san/PyQt-3.3.2/sip/qobject.sip:689: `sipName_qt_QApplication' undeclared (first use this function) .... and so on for every Qt class referred. Once again, I've got links to PyQt intermediates. Only after changing them to sipName_Desktop_QAccel, etc. I was able to compile the stuff though it took me more than an hour on PIII-750! QUESTION: Is there anybody who knows how to do it right to fix all the above-mentioned, i.e. to remove numerous links to PyQt intermediate files and to make my intermediate code compact? Best regards! From phil at river-bank.demon.co.uk Thu Aug 8 15:24:00 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Using PyQt in my .sip file leads to several problems References: <3D526858.7020506@nnov.matra-dtv.fr> Message-ID: <3D5270CE.2010409@river-bank.demon.co.uk> Sergey ANIKIN wrote: > Domain: Linux C++ Qt-2.2.2 PyQt-3.3.2 sip-3.3.2 > > I'm trying to write a small C++ class with one method retuning the > desktop widget for my application. > I would like my method to be called from Python script to use the widget > returned as a parent for PyQt dialogs. > I do the following: > > // desktop.h: > > #include > class Desktop > { > public: > static QWidget* getDesktop(); > }; > > // desktop.cxx: > > #include > QWidget* Desktop::getDesktop() > { > return qApp::desktop(); > } > > // desktop.sip: > > %Module Desktop > > # FIRST PROBLEM: I had to include almost all PyQt .sip files here in > order to make SIP work without errors. Otherwise, it reports "QWidget is > not defined", etc. > # Is it right? > %Include versions.sip > %Include qglobal.sip > ... > %Include qwidget.sip Don't %Include any of the PyQt .sip file. Instead... %Import qtmod.sip Take a look at how the other PyQt modules (eg. qtcanvasmod.sip) work. Phil From san at nnov.matra-dtv.fr Thu Aug 8 16:39:00 2002 From: san at nnov.matra-dtv.fr (Sergey ANIKIN) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Using PyQt in my .sip file leads to several problems References: <3D526858.7020506@nnov.matra-dtv.fr> <3D5270CE.2010409@river-bank.demon.co.uk> Message-ID: <3D5280CA.2030901@nnov.matra-dtv.fr> Thanks for the good advice!Now I see the difference between %Include and %Import :) Phil Thompson wrote: > Don't %Include any of the PyQt .sip file. Instead... > > %Import qtmod.sip > > Take a look at how the other PyQt modules (eg. qtcanvasmod.sip) work. > > Phil > > _______________________________________________ > PyKDE mailing list PyKDE@mats.gmd.de > http://mats.gmd.de/mailman/listinfo/pykde > > From hpj at urpla.net Thu Aug 8 19:59:01 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QSpinBox doesn't work as expected within QSqlForm In-Reply-To: <3D4FBA28.2020906@river-bank.demon.co.uk> References: <200208031312.26551.hpj@urpla.net> <200208061342.21669.hpj@urpla.net> <3D4FBA28.2020906@river-bank.demon.co.uk> Message-ID: <200208081958.17434.hpj@urpla.net> On Tuesday 06 August 2002 13:59, Phil Thompson wrote: > Hans-Peter Jansen wrote: > > Top spinbox is a Qt native one, below is a reimplemented > > one with a custom eventFilter. This one is working fine for me, > > but the first isn't (Qt 3.0.4, PyQt 3.3.2, Python 2.1.1, Linux) > > All other events seem to work fine, including wheel events, BTW. > > Both work fine for me. Qt 3.0.5, latest PyQt snapshot, Python 2.2.1. > > Phil Take three: attached is an enhanced version of the test program to ensure this app receives the events. It does. The anomaly persists with Qt 3.0.5, BTW. Should I consider to think about blame it to my python version? Phil, can you make a crosscheck with 2.1.1 without much hassle? Hans-Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: sbform3.py Type: text/x-python Size: 10354 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020808/1d7b744e/sbform3.py From fredan-pykde at fredan.org Thu Aug 8 21:45:00 2002 From: fredan-pykde at fredan.org (fredrik danerklint) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QSpinBox doesn't work as expected within QSqlForm In-Reply-To: <200208081958.17434.hpj@urpla.net> References: <200208031312.26551.hpj@urpla.net> <3D4FBA28.2020906@river-bank.demon.co.uk> <200208081958.17434.hpj@urpla.net> Message-ID: <200208082146.26043.fredan-pykde@fredan.org> > Take three: > > attached is an enhanced version of the test program to ensure this > app receives the events. It does. Yes, it does, but only the second spinbox gives an update. However, the keyevent is also recived by the first spinbox (without any updates) -- //fredan From the at uni-bremen.de Thu Aug 8 23:12:00 2002 From: the at uni-bremen.de (Thorsten Ende) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] compiling problems PyKde3.2.4, KDE3.02 debian sarge Message-ID: <200208082220.26084.the@uni-bremen.de> Hi everyone, i tried to compile PyKDE and got the following error : g++ -E -I/usr/include/python2.1 -I/usr/include/python2.1/ -I/usr/local/kde3/include -I/usr/local/src/qt-copy-3.0.3/include -DQT_THREAD_SUPPORT -I/usr/X11R6/include -I.. sipdcopProxydcop.h >moc_sipdcopProxydcop.h In file included from /usr/local/src/qt-copy-3.0.3/include/qmime.h:43, from /usr/local/src/qt-copy-3.0.3/include/qevent.h:45, from /usr/local/src/qt-copy-3.0.3/include/qobject.h:45, from /usr/include/python2.1/sipQt.h:41, from sipdcopProxydcop.h:34: /usr/local/src/qt-copy-3.0.3/include/qmap.h:49: iterator: No such file or directory /usr/local/src/qt-copy-3.0.3/include/qmap.h:50: map: No such file or directory In file included from /usr/local/src/qt-copy-3.0.3/include/qtranslator.h:44, from /usr/local/src/qt-copy-3.0.3/include/qapplication.h:45, from sipdcopProxydcop.h:37: /usr/local/src/qt-copy-3.0.3/include/qvaluelist.h:48: iterator: No such file or directory /usr/local/src/qt-copy-3.0.3/include/qvaluelist.h:49: list: No such file or directory make[2]: *** [sipdcopProxydcop.moc] Error 1 make[2]: Leaving directory ` After i add the dir with the includes for iterator and list (/usr/include/g++-3/) , i got some other complains : g++ -E -I/usr/include/g++-3 -I/usr/include/python2.1 -I/usr/include/python2.1/ -I/usr/local/kde3/include -I/usr/local/src/qt-copy-3.0.3/include -DQT_THREAD_SUPPORT -I/usr/X11R6/include -I.. sipdcopProxydcop.h >moc_sipdcopProxydcop.h /usr/local/src/qt-copy-3.0.3/bin/moc -o sipdcopProxydcop.moc moc_sipdcopProxydcop.h moc_sipdcopProxydcop.h:31238: Error: syntax error g++ version is 2.95.4. Sounds simple but i dont have any further idea. Anyone else has an one ? TIA The From jbublitz at nwinternet.com Fri Aug 9 00:07:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyKDE Release Message-ID: I've sent the PyKDE-3.3.2 tarball to Phil to post on the riverbankcomputing site. This release uses about the same build system as PyQt - please read the README for details. Note that there are command line switches for specifying each of the directories that PyKDE requires to build. If you need a lot of switches, look at the -z switch/buildrc example in the top level directory. build.py is not as agressive as ./configure was in locating directories. This release was tested on KDE 2.1.1/2.2.2/3.0.0/3.0.1. It covers KDE through 3.0.2 (there is almost no difference for PyKDE between 3.0.1 and 3.0.2). The pyParts.py example program doesn't work for KDE >= 3.0.0. As noted earlier, this appears to be a KDE problem. The build system has only been tested on SuSE (7.1/7.3/8.0) - please report any problems, as I'm not set up to test with other distributions or platforms. As usual, bug reports, comments and suggestions are appreciated. I don't intend to release anything for KDE3.1 alpha/beta releases (although that may change). KDE 3.1 is due in October - between now and then I'd like to work on example programs, testing, and tools for building PyKDE, as well as some other projects (some personal, some not). Contributions of example programs or test code would also be appreciated. Thanks for your patience - it's taken a while to get this released. Jim From jbublitz at nwinternet.com Fri Aug 9 01:00:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] compiling problems PyKde3.2.4, KDE3.02 debian sarge In-Reply-To: <200208082220.26084.the@uni-bremen.de> Message-ID: On 08-Aug-02 Thorsten Ende wrote: > g++ version is 2.95.4. > Sounds simple but i dont have any further idea. Anyone else has > an one ? PyKDE-3.2.4 won't build with KDE > 3.0.0. The new release (PyKDE-3.3.2) should be on the riverbankcomputing site shortly, but I can't say how long a debian release will take (Ricardo?) Jim From rcardenes at debian.org Fri Aug 9 08:13:00 2002 From: rcardenes at debian.org (Ricardo Javier Cardenes Medina) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] compiling problems PyKde3.2.4, KDE3.02 debian sarge In-Reply-To: References: <200208082220.26084.the@uni-bremen.de> Message-ID: <20020809061207.GA2879@bifrost.ddts.net> On Thu, Aug 08, 2002 at 03:13:32PM -0700, Jim Bublitz wrote: > > PyKDE-3.2.4 won't build with KDE > 3.0.0. The new release > (PyKDE-3.3.2) should be on the riverbankcomputing site shortly, but > I can't say how long a debian release will take (Ricardo?) Hopefully, a week or two after release. I'll do new packaging for the new build system. From phil at river-bank.demon.co.uk Fri Aug 9 11:42:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QSpinBox doesn't work as expected within QSqlForm References: <200208031312.26551.hpj@urpla.net> <200208061342.21669.hpj@urpla.net> <3D4FBA28.2020906@river-bank.demon.co.uk> <200208081958.17434.hpj@urpla.net> Message-ID: <3D538E34.4060603@river-bank.demon.co.uk> Hans-Peter Jansen wrote: > On Tuesday 06 August 2002 13:59, Phil Thompson wrote: > >>Hans-Peter Jansen wrote: >> >>>Top spinbox is a Qt native one, below is a reimplemented >>>one with a custom eventFilter. This one is working fine for me, >>>but the first isn't (Qt 3.0.4, PyQt 3.3.2, Python 2.1.1, Linux) >>>All other events seem to work fine, including wheel events, BTW. >>> >>Both work fine for me. Qt 3.0.5, latest PyQt snapshot, Python 2.2.1. >> >>Phil >> > > Take three: > > attached is an enhanced version of the test program to ensure this > app receives the events. It does. > > The anomaly persists with Qt 3.0.5, BTW. > > Should I consider to think about blame it to my python version? > Phil, can you make a crosscheck with 2.1.1 without much hassle? Python 2.1.1 works fine for me as well. Phil From fredan-pykde at fredan.org Fri Aug 9 13:25:00 2002 From: fredan-pykde at fredan.org (fredrik danerklint) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyKDE 3.3.2 Message-ID: <200208091326.13812.fredan-pykde@fredan.org> Hi! I run into the following problem: [root@datorn PyKDE-3.3.2]# python build.py -c Building PyKDE 3.3 for Python 2.2.1 on linux2. /usr/local/lib/python2.2/site-packages is the PyKDE installation directory. /usr/local/include/python2.2 contains Python.h. /usr/local/bin/sip will be used as the SIP code generator. /usr/local/include/python2.2 contains sipQt.h. /usr/local/lib/python2.2/site-packages contains the SIP module. /usr/local/qt3 is the Qt base directory. /usr/local/qt3/include contains qglobal.h. An internal error occured. Please report all the output from the program, including the following traceback, to phil@riverbankcomputing.co.uk. Traceback (most recent call last): File "build.py", line 1403, in ? main(sys.argv) File "build.py", line 1328, in main installChecks() File "build.py", line 788, in installChecks checkQtDirAndVersion() File "build.py", line 415, in checkQtDirAndVersion qtVersion = int(wl[2]) ValueError: invalid literal for int(): 0x030005 [root@datorn PyKDE-3.3.2]# -- //fredan From fredan-pykde at fredan.org Fri Aug 9 15:24:00 2002 From: fredan-pykde at fredan.org (fredrik danerklint) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] More problems with PyKDE 3.3.2 Message-ID: <200208091525.53414.fredan-pykde@fredan.org> Missing -I/usr/X11R6/include in makefile. cd kdecore && "/usr/bin/make" -f Makefile make[1]: Entering directory `/usr/local/src/kde3/afterkde/PyKDE-3.3.2/kdecore' g++ -c -pipe -w -O2 -march=athlon -mmmx -m3dnow -D_REENTRANT -fPIC -DSIP_MAKE_MODULE_DLL -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -fno-exceptions -I-I -I../extraH -I. -I../../../../../include/python2.2 -I../../../../../kde3/include -I/usr/local/qt3/include -I/usr/local/qt3/mkspecs/default -o kdecorehuge.o kdecorehuge.cpp In file included from sip/netwm.sip:138, from kdecorehuge.cpp:124: ../../../../../kde3/include/netwm.h:31:22: X11/Xlib.h: No such file or directory ../../../../../kde3/include/netwm.h:32:23: X11/Xutil.h: No such file or directory ../../../../../kde3/include/netwm.h:33:23: X11/Xatom.h: No such file or directory make[1]: *** [kdecorehuge.o] Error 1 make[1]: Leaving directory `/usr/local/src/kde3/afterkde/PyKDE-3.3.2/kdecore' make: *** [sub-kdecore] Error 2 -- //fredan From tschortsch at gmx.ch Fri Aug 9 16:14:01 2002 From: tschortsch at gmx.ch (=?iso-8859-1?q?J=FCrg=20Marti?=) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyKDE 3.3.2 In-Reply-To: <200208091326.13812.fredan-pykde@fredan.org> References: <200208091326.13812.fredan-pykde@fredan.org> Message-ID: <200208091613.40529.tschortsch@gmx.ch> this is caused by the new version system of qt-3.0.5. from http://www.trolltech.com/developer/changes/3.0.5.html: >The version number format of QT_VERSION changed. It is now 0xmmiibb (m = >major, i = minor, b = bugfix). Qt 3.0.5's QT_VERSION is 0x030005. an easy workaround would be to change the version number of qt in qglobels.h to the old format. -------------------------patch starts-------------------------------------- --- qglobal.h.orig Fri Aug 9 16:06:00 2002 +++ qglobal.h Fri Aug 9 16:08:15 2002 @@ -42,7 +42,7 @@ /* QT_VERSION is ( MAJOR<<16+MINOR<<8+_PATCH) */ -#define QT_VERSION 0x030005 +#define QT_VERSION 305 /* The operating system, must be one of: (Q_OS_x) --------------------------------ends--------------------------------------- On Friday 09 August 2002 13:26, fredrik danerklint wrote: > Hi! > > I run into the following problem: > > [root@datorn PyKDE-3.3.2]# python build.py -c > Building PyKDE 3.3 for Python 2.2.1 on linux2. > /usr/local/lib/python2.2/site-packages is the PyKDE installation directory. > /usr/local/include/python2.2 contains Python.h. > /usr/local/bin/sip will be used as the SIP code generator. > /usr/local/include/python2.2 contains sipQt.h. > /usr/local/lib/python2.2/site-packages contains the SIP module. > /usr/local/qt3 is the Qt base directory. > /usr/local/qt3/include contains qglobal.h. > An internal error occured. Please report all the output from the program, > including the following traceback, to phil@riverbankcomputing.co.uk. > > Traceback (most recent call last): > File "build.py", line 1403, in ? > main(sys.argv) > File "build.py", line 1328, in main > installChecks() > File "build.py", line 788, in installChecks > checkQtDirAndVersion() > File "build.py", line 415, in checkQtDirAndVersion > qtVersion = int(wl[2]) > ValueError: invalid literal for int(): 0x030005 > [root@datorn PyKDE-3.3.2]# From jbublitz at nwinternet.com Fri Aug 9 17:30:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyKDE 3.3.2 In-Reply-To: <200208091613.40529.tschortsch@gmx.ch> Message-ID: On 09-Aug-02 Jürg Marti wrote: > this is caused by the new version system of qt-3.0.5. > from http://www.trolltech.com/developer/changes/3.0.5.html: >>The version number format of QT_VERSION changed. It is now >>0xmmiibb (m = >>major, i = minor, b = bugfix). Qt 3.0.5's QT_VERSION is 0x030005. > an easy workaround would be to change the version number of qt in > qglobels.h > to the old format. Thanks - saved me some digging for the cause. Phil has a fix for this in PyQt's build.py which I'll steal. In the meantime temporarily changing the version string as noted is a quick workaround. Jim From jbublitz at nwinternet.com Fri Aug 9 17:30:30 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] More problems with PyKDE 3.3.2 In-Reply-To: <200208091525.53414.fredan-pykde@fredan.org> Message-ID: On 09-Aug-02 fredrik danerklint wrote: > Missing -I/usr/X11R6/include in makefile. > cd kdecore && "/usr/bin/make" -f Makefile > make[1]: Entering directory > `/usr/local/src/kde3/afterkde/PyKDE-3.3.2/kdecore' > g++ -c -pipe -w -O2 -march=athlon -mmmx -m3dnow -D_REENTRANT > -fPIC > -DSIP_MAKE_MODULE_DLL -DQT_NO_DEBUG -DQT_THREAD_SUPPORT > -fno-exceptions -I-I > -I../extraH -I. -I../../../../../include/python2.2 > -I../../../../../kde3/include -I/usr/local/qt3/include > -I/usr/local/qt3/mkspecs/default -o kdecorehuge.o kdecorehuge.cpp > In file included from sip/netwm.sip:138, > from kdecorehuge.cpp:124: > ../../../../../kde3/include/netwm.h:31:22: X11/Xlib.h: No such > file or > directory > ../../../../../kde3/include/netwm.h:32:23: X11/Xutil.h: No such > file or > directory > ../../../../../kde3/include/netwm.h:33:23: X11/Xatom.h: No such > file or > directory > make[1]: *** [kdecorehuge.o] Error 1 > make[1]: Leaving directory > `/usr/local/src/kde3/afterkde/PyKDE-3.3.2/kdecore' > make: *** [sub-kdecore] Error 2 The following change in PyKDE-3.3.2/sip/kde30/kdecore.sip should work: from: INCLUDEPATH = -I ../extraH @BL_INCLUDEPATH@ to: INCLUDEPATH = -I ../extraH @BL_INCLUDEPATH@ -I /usr/X11R6/include It doesn't seem it should be necessary (I haven't needed it at any rate) as the path should be picked up via qmake from qmake.conf. It shouldn't hurt to add it for those who need it. I'll add this change and correct Qt version detection in build.py and put out an update later today - PyKDE-3.3.2-1 Jim From jbublitz at nwinternet.com Sat Aug 10 01:06:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyKDE-3.3.2-1 Message-ID: PyKDE-3.3.2-1 should be available shortly. It contains the following changes: 1. build.py fixed for Qt 3.0.5 versioning 2. added include of /usr/X11R6/include path for kdecore.sip If you're not using Qt 3.0.5 and haven't had trouble with the above include path, there's no reason to update PyKDE-3.3.2, as there are no other changes. I haven't tested either fix since I don't have Qt 3.0.5 installed and don't have a problem with the include path, so let me know if further repair is required. I also forgot to update the change log, but I'll get that on the next round. Jim From detlev at die-offenbachs.de Sat Aug 10 12:00:01 2002 From: detlev at die-offenbachs.de (Detlev Offenbach) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyKDE-3.3.2-1 In-Reply-To: References: Message-ID: <200208101158.12577.detlev@majestix.gallien.de> Hi Jim, Am Samstag, 10. August 2002 00:25 schrieb Jim Bublitz: > PyKDE-3.3.2-1 should be available shortly. It contains the > following changes: > > 1. build.py fixed for Qt 3.0.5 versioning > 2. added include of /usr/X11R6/include path for kdecore.sip > > If you're not using Qt 3.0.5 and haven't had trouble with the above > include path, there's no reason to update PyKDE-3.3.2, as there are > no other changes. > > I haven't tested either fix since I don't have Qt 3.0.5 installed > and don't have a problem with the include path, so let me know if > further repair is required. I also forgot to update the change log, > but I'll get that on the next round. Now it doesn't work for Qt before 3.0.5 anymore. In your build.py script you have to change the qttags definition as follows: qttags = { 0x020000: "Qt_1_43", 0x020100: "Qt_2_00", 0x020200: "Qt_2_1_0", 0x020300: "Qt_2_2_0", 0x020301: "Qt_2_3_0", 0x030000: "Qt_2_3_1", 0x030001: "Qt_3_0_0", 0x030002: "Qt_3_0_1", 0x030004: "Qt_3_0_2", 0x030005: "Qt_3_0_4", 0x040000: "Qt_3_0_5" } Then it works again (see Phil's build.py script). I addition to this I have a problem executing the build.py script. When it tries to generate the C++ code for the kjs module, I get the following error message. Generating the C++ source for the kjs module. sip: Unable to find file "kjs.sip" ****************************************************************************** Error: /usr/bin/sip failed with an exit code of 256 -- from line 1125 in build.py ****************************************************************************** Please help. Configuration is as follows. KDE 3.0.2, Qt 3.0.4, PyQt 3.3.2, PyKDE 3.3.2-1 > > > Jim > > _______________________________________________ > PyKDE mailing list PyKDE@mats.gmd.de > http://mats.gmd.de/mailman/listinfo/pykde Regards, Detlev -- Detlev Offenbach detlev@die-offenbachs.de From jbublitz at nwinternet.com Sat Aug 10 20:07:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyKDE-3.3.2-1 In-Reply-To: <200208101158.12577.detlev@majestix.gallien.de> Message-ID: On 10-Aug-02 Detlev Offenbach wrote: > Now it doesn't work for Qt before 3.0.5 anymore. In your build.py > script you have to change the qttags definition as follows: > > qttags = { > 0x020000: "Qt_1_43", > 0x020100: "Qt_2_00", > 0x020200: "Qt_2_1_0", > 0x020300: "Qt_2_2_0", > 0x020301: "Qt_2_3_0", > 0x030000: "Qt_2_3_1", > 0x030001: "Qt_3_0_0", > 0x030002: "Qt_3_0_1", > 0x030004: "Qt_3_0_2", > 0x030005: "Qt_3_0_4", > 0x040000: "Qt_3_0_5" > } > Then it works again (see Phil's build.py script). Yes - you're right. I missed that change, but will get the fix out right away. > I addition to this I have a problem executing the build.py > script. When it tries to generate the C++ code for the kjs > module, I get the following error message. > Generating the C++ source for the kjs module. > sip: Unable to find file "kjs.sip" > ****************************************************************** > ************ > Error: /usr/bin/sip failed with an exit code of 256 -- from line > 1125 in > build.py > ****************************************************************** > ************ > Please help. > Configuration is as follows. > KDE 3.0.2, Qt 3.0.4, PyQt 3.3.2, PyKDE 3.3.2-1 Somehow kjs.sip got deleted from the -1 tarball ??? It's back now. I've already sent PyKDE-3.3.2-2 out to Phil with the changes - should be available shortly. If you want to avoid another download: If you have a PyKDE-3.2.4 kjs.sip around, you can just copy it into the PyKDE-3.3.2/sip directory - there are no changes for 3.0.1 or 3.0.2. The patch above for qttags can be applied to build.py. Jim From aloy at ctv.es Sat Aug 10 22:01:01 2002 From: aloy at ctv.es (Antoni Aloy =?iso-8859-1?q?L=F3pez?=) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QCString is undefined error Message-ID: <200208102207.30671.aloy@ctv.es> Hi! After patching the build.py file to locate my Qt/sip and to correct the version bug and after installing the tmake I have tried to build the new PyKde, but I get this error message: Generating the C++ source for the dcop module. sip: QCString is undefined ****************************************************************************** Error: /usr/bin/sip failed with an exit code of 256 -- from line 1116 in build.py ****************************************************************************** My TMAKEPATH points to /usr/lib/tmake/linux-g++/ and I'm using Gentoo Linux. Any ideas? The full log follows: PyKDE-3.3.2 $ python build.py -l qt-mt -c Building PyKDE 3.3 for Python 2.2.1 on linux2. /usr/lib/python2.2/site-packages is the PyKDE installation directory. /usr/include/python2.2 contains Python.h. /usr/bin/sip will be used as the SIP code generator. /usr/include/python2.2 contains sipQt.h. /usr/lib/python2.2/site-packages contains the SIP module. /usr/qt/3 is the Qt base directory. /usr/qt/3/include contains qglobal.h. Qt 3.0.5 is being used. /usr/kde/3 is the KDE base directory. /usr/kde/3/include contains kdeversion.h. KDE 3.0.2 is being used. /usr/bin/tmake will be used to generate Makefiles. Qt thread support is enabled. Qt and KDE use compatible libs (threading) found libs for modules: dcop kdecore kdesu kdefx kdeui kio kfile (kio) kparts khtml kjs kspell kdeprint PyQt/sip directory found at /feina/downloads/PyQt/sip /usr/bin/make will be used as the make program. Checking to see if the C++ compiler supports -fno-exceptions. g++ -c -pipe -O2 -D_REENTRANT -DQT_THREAD_SUPPORT -DNO_DEBUG -fno-exceptions -I. -I/usr/include/python2.2 -I/usr/kde/3/include -I/usr/qt/3/include -o qttest.o qttest.cpp g++ -o qttest qttest.o -L/usr/qt/3/lib -L/usr/X11R6/lib -lpthread -lqt-mt -lXext -lX11 -lm The C++ compiler supports -fno-exceptions. Using existing features file. Copying sip module files for version KDE302 to sip directory Copying version specific h files for KDE302 to extraH directory Generating the C++ source for the dcop module. sip: QCString is undefined ****************************************************************************** Error: /usr/bin/sip failed with an exit code of 256 -- from line 1116 in build.py ****************************************************************************** -- Antoni Aloy L?pez Binissalem - Mallorca Linux Registered User # 210825 Gentoo Powered From jbublitz at nwinternet.com Sun Aug 11 01:59:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] QCString is undefined error In-Reply-To: <200208102207.30671.aloy@ctv.es> Message-ID: On 10-Aug-02 Antoni Aloy López wrote: > After patching the build.py file to locate my Qt/sip and to > correct the version bug and after installing the tmake I have > tried to build the new PyKde, but I get this error message: You don't need to modify build.py to specify a sip file location: python build.py -lqt-mt -v /usr/local/PyQt-3.3.2/sip -c The -v switch lets you specify the location of PyQt's sip files (although in this case build.py would find them without -v). python build.py -h will give you all of the switches - virtually any setup should be able to be specified without editing build.py. You can also use the -z switch to specify a file with the switches: python build.py -z buildrc where PyKDE-3.3.2/buildrc contains: -lqt-mt -v/usr/local/PyQt-3.3.2/sip -c should be equivalent to the command line above. > Generating the C++ source for the dcop module. > sip: QCString is undefined > ****************************************************************** > ************ > Error: /usr/bin/sip failed with an exit code of 256 -- from line > 1116 in > build.py > ****************************************************************** > ************ > My TMAKEPATH points to /usr/lib/tmake/linux-g++/ and I'm using > Gentoo Linux. That's correct. > Any ideas? > The full log follows: The log looked correct up to the point of failure. First, make sure you have qcstring.sip in the PyQt sip directory you specified, and qtmod.sip contains a '%Include qcstring.sip' line. Next, in the generateSource function in build.py do the following (around line 1036): change: runProgram (sipBin, argv) to: print sipBin print argv runProgram (sipBin, argv) the argv list should contain a '-I ' where 'PyQt sip file path' is replaced with the value specified with -v or that you edited in to build.py. I don't imagine permissions should be a problem, but you might check that you can actually access the PyQt sip files (especially qcstring.sip) as well. This is a completely new build system, so I wouldn't be surprised to find some bugs, however I don't see what might cause this at the moment. I just re-ran build.py with PyQt's sip files copied to an odd location and using the -v switch, and it ran without errors. Jim From verwilst at gentoo.org Sun Aug 11 18:47:01 2002 From: verwilst at gentoo.org (Bart Verwilst) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Installation of user-end pyqt app on windows In-Reply-To: References: Message-ID: <200208111853.16952.verwilst@gentoo.org> Hi! My app is working great in linux, but i was wondering what steps should be taken to make it easy for users to install my app on windows... (Like 1 setup.exe which does the trick). Is this possible? And can a pyqt/qt dll or something be included in that? I hope somebody can give me a detailed explanation/reference to my prob.. Thanks in advance! -- Bart Verwilst Gentoo Linux Developer, Release Coordinator Gent, Belgium From martin.preishuber at eclipt.at Sun Aug 11 20:13:00 2002 From: martin.preishuber at eclipt.at (Martin Preishuber) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyQT Installation Error Message-ID: <1029089776.3599.10.camel@daddy> Hi all, I'm originally a PyGTK user, but since I like the new KDE3 I thought I probably consider PyKDE for future projects. I tried to install PyKDE and managed to install sip-3.3.2 and most of pyqt-3.3.2 ... most of, because it compiled fine, but I can't include anything. The error is: Python 2.1.3 (#1, Jul 29 2002, 22:34:51) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from qt import * Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/site-packages/qt.py", line 53, in ? import libqtc ImportError: /usr/lib/python2.1/site-packages/libqtcmodule.so: undefined symbol: metaObject__C9QSGIStyle >>> I tried to compile it on a athlon desktop and on a p3 notebook, both running debian unstable, gcc-2.95.4 and qt-3.0.5. Any ideas ? btw. are there any debian packages of pykde somewhere ? Martin -- Martin Preishuber - IT Expert, Student, SysAdmin http://www.eclipt.at, mailto:Martin.Preishuber@eclipt.at Never underestimate the power of somebody with source code, a text editor, and the willingness to totally hose their system. -- Rob Landley From phil at river-bank.demon.co.uk Sun Aug 11 21:39:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Installation of user-end pyqt app on windows References: <200208111853.16952.verwilst@gentoo.org> Message-ID: <3D56BD3B.6010008@river-bank.demon.co.uk> Bart Verwilst wrote: > Hi! > > My app is working great in linux, but i was wondering what steps should be > taken to make it easy for users to install my app on windows... > (Like 1 setup.exe which does the trick). > Is this possible? And can a pyqt/qt dll or something be included in that? > I hope somebody can give me a detailed explanation/reference to my prob.. Options for a setup.exe are... - Python distutils package - the McMillan installer (I think this is different to distutils) - a commercial installer like Wise or InstallShield You can distribute a Qt DLL if you have bought a commercial Qt license or you have bought the Business Edition of BlackAdder. You may (check the license) also be able to include the DLL for the non-commercial edition of Qt - you can certainly tell your users to install it themselves (so long as they conform to its license). Phil From phil at river-bank.demon.co.uk Sun Aug 11 21:41:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyQT Installation Error References: <1029089776.3599.10.camel@daddy> Message-ID: <3D56BDC4.9010509@river-bank.demon.co.uk> Martin Preishuber wrote: > Hi all, > > I'm originally a PyGTK user, but since I like the new KDE3 I thought I > probably consider PyKDE for future projects. I tried to install PyKDE > and managed to install sip-3.3.2 and most of pyqt-3.3.2 ... most of, > because it compiled fine, but I can't include anything. The error is: > > Python 2.1.3 (#1, Jul 29 2002, 22:34:51) > [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 > Type "copyright", "credits" or "license" for more information. > >>>>from qt import * >>>> > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/lib/python2.1/site-packages/qt.py", line 53, in ? > import libqtc > ImportError: /usr/lib/python2.1/site-packages/libqtcmodule.so: undefined > symbol: metaObject__C9QSGIStyle > > > I tried to compile it on a athlon desktop and on a p3 notebook, both > running debian unstable, gcc-2.95.4 and qt-3.0.5. Any ideas ? Read README.Linux. Phil From rcardenes at debian.org Mon Aug 12 00:53:01 2002 From: rcardenes at debian.org (Ricardo Javier Cardenes Medina) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] PyQT Installation Error In-Reply-To: <1029089776.3599.10.camel@daddy> References: <1029089776.3599.10.camel@daddy> Message-ID: <20020811225224.GA23959@bifrost.ddts.net> On Sun, Aug 11, 2002 at 08:16:15PM +0200, Martin Preishuber wrote: > > Python 2.1.3 (#1, Jul 29 2002, 22:34:51) > [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 > Type "copyright", "credits" or "license" for more information. > >>> from qt import * > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/lib/python2.1/site-packages/qt.py", line 53, in ? > import libqtc > ImportError: /usr/lib/python2.1/site-packages/libqtcmodule.so: undefined > symbol: metaObject__C9QSGIStyle > >>> As the README.Linux says, that's a problem with Debian (and others) way to package Qt 3, compiling CDE, MotifPlus, Platinum, SGI, and Windows styles as plugins. My Debian packages deal with that problem. > I tried to compile it on a athlon desktop and on a p3 notebook, both > running debian unstable, gcc-2.95.4 and qt-3.0.5. Any ideas ? > > btw. are there any debian packages of pykde somewhere ? Please, get the last Debian packages from: deb http://ulysses.gulic.org/debian unstable main Then: # apt-get install python2.1-qt3 I plan to upload them to mainstream Debian this week if I have the time, anyway. From scherrey at proteus-tech.com Mon Aug 12 06:23:00 2002 From: scherrey at proteus-tech.com (Benjamin Scherrey) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Multi-platform commercial development... Message-ID: My company is seriously looking at using Python/PyQt to do the interface development for our new products. Our target environments are win32, linux, & OS-X. I understand that PyQt for OS-X is not yet implemented and does't have a specified timeframe (although we might be interested in helping with an OS-X move). Presently our development is in C++ and we have a commercial win32 Qt license but we'd like to move to python for the application code (calling our C++ services). We're also looking to see if BlackAdder might be an option for us and are curious as to what the relationship between BlackAdder and PyQt are and if BlackAdder will have Qt 3.x support forthcoming. Besides the above - can someone advise us as to the effort involved in getting PyQt ported to OS-X. Please pardon the rambling on and thanx for your help, Ben Scherrey From phil at river-bank.demon.co.uk Mon Aug 12 10:19:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:43 2007 Subject: [PyKDE] Multi-platform commercial development... References: Message-ID: <3D576F50.5000004@river-bank.demon.co.uk> Benjamin Scherrey wrote: > My company is seriously looking at using Python/PyQt to do the interface development for our new > products. Our target environments are win32, linux, & OS-X. I understand that PyQt for OS-X is not > yet implemented and does't have a specified timeframe (although we might be interested in helping > with an OS-X move). Presently our development is in C++ and we have a commercial win32 Qt > license but we'd like to move to python for the application code (calling our C++ services). We're > also looking to see if BlackAdder might be an option for us and are curious as to what the > relationship between BlackAdder and PyQt are and if BlackAdder will have Qt 3.x support > forthcoming. Besides the above - can someone advise us as to the effort involved in getting PyQt > ported to OS-X. You need to talk to theKompany about BlackAdder. The relationship is simply that they license PyQt to be included in BlackAdder. I believe Qt3 support is in the works, but this won't includes MacOS support. Adding MacOS support to PyQt requires significant changes to SIP - it's more than a porting exercise. We can talk off-list if you are interested in helping with the development costs. Phil From P.FREMY at OBERTHURCS.com Tue Aug 13 13:47:02 2002 From: P.FREMY at OBERTHURCS.com (Philippe FREMY) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Problem compiling PyQt Message-ID: <191CBBF91062D411855D00D0B76F1C30E2420A@PROXIMA> > Philippe FREMY wrote: > > >>>d:/software/PyQt-3.3.2 > nmake > >>> > >>>Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > >>>Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > >>> > >>> cd qt > >>> nmake > >>> > >>>Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > >>>Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > >>> > >>> link /NOLOGO /DEBUG /SUBSYSTEM:windows /DLL > >>>/OUT:d:\software\Python22\Li > >>>b\site-packages\libqtc.pyd @c:\WINNT\TEMP\nma01708. > >>>LINK : fatal error LNK1104: cannot open file "python22_d.lib" > >>>NMAKE : fatal error U1077: 'link' : return code '0x450' > >>>Stop. > >>>NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual > >>>Studio\VC98\bin\n > >>>make.exe"' : return code '0x2' > >>> > >>>I checked, I haven't got any python22_d.lib file on my harddrive. I have > >>>however a python22.lib . How do I switch from one to the other ? > >>> > >> > >>I'm not sure how you've got the /DEBUG switch specified as qmake will be > >>adding this. How did you build Qt? > >> > > > > My Qt was built from source with the debug flag. Does it influence ? > > > It looks like it does. > I find the behaviour really strange. The makefile generated by qt.pro (attached) contains the /DEBUG flag but the qt.pro does not. So it looks like it has been added by build.py . Does build.py have a debug mode ? Even if the debug was added by build.py, I don't know how it manages to pick python22_d.lib instead of python22.lib . I have managed to open the temporary file created by nmake to link and it does contains python22.lib . I really wonder where this python22_d.lib comes from. Anyone familiar with nmake around ? regards, Philippe -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 542409 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020812/ad463ad9/Makefile.obj From douard at magic.fr Tue Aug 13 13:48:40 2002 From: douard at magic.fr (David Douard) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Quickexec and Packaging question Message-ID: <200208131334.09477.douard@magic.fr> Hi list ! This is about embedded Qt for PDA (Zaurus). Have anyone any idea to implement the "quiexec" feature for a purely PyQt application ? Then, what is the right way to package it (as a standalone app... I think I can use the McMillan Installer to generate a standalone exec, and then package it with required libs as a rpm/ipkg package). Also, does anyone have any experiment with packaging an PyQt app (I mean in the "final end user" goal : no python installed on the PDA, and so on...) Thank you, David Douard PS: I am not on the ML, so please CC me back. Thank you. From douard at magic.fr Tue Aug 13 13:48:49 2002 From: douard at magic.fr (David Douard) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] QtPE Missing features Message-ID: <200208131334.21289.douard@magic.fr> Hi list, Hi Phil I know there are many things to do for such a wrapper, but I am using Qtopia classes (TrollTech's 1.5.0 GPL version) in my PyQt application for the Zaurus which are not included in PyQt, and quite easy to add, namely: Config AppLnk/DocLnk (and Sets) FileManager FileSelector Resource All thoses are really easy to add to PyQt (what I did). Should I send you (Phil) a patch for these, so they can be included in PyQt ? (But these are really trivial changes). I have not tried other Qtopia classes, but I think they must but also easy to add... The problem I have encountered is with the DCopEnvelope. The normal use of it is to call the constructor with 2 params (channel and message). But you then have to call the operator << on the created object to pass arguments, and the message is actually sent when the object it deleted (almost all the code of the object is in the destructor). What is the right way to wrap it ? I have tried to write a wrapp Member Code so you give the 2 required params and an optional list of strings... But I does not work, and I don't have time to guess the way Sip works in details... Anoyone did something ? Thank you David Douard PS: I am not on the ML, so please CC me back. Thank you. From douard at magic.fr Tue Aug 13 13:48:57 2002 From: douard at magic.fr (David Douard) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] about QPEApplication and QMainWindow Message-ID: <200208131334.23858.douard@magic.fr> Hi ! I am developping a little app (for the zaurus contest) using PyQt. And I have found several problems... First, I am still obliged to comment out a few lines in the sip files in order to compile PyQt... (gcc complains about accessing vars which are declared private in the master C++ class and thus not availbale in any derived class---which is normal. So I still do not understand how PyQt can be compiled out of the box. NB: I am using Qtopia as available to Trolltech's site, GPL version). Then I have spent almost a day to realize that I had many problems with the Qtopia integration of my app which where du to the fact that the /tmp/qcop-msg file was not opened, read end destroyed by my app... Which was due to the fact that, in the QApplication code (file qapplication.cpp), the name of the program (argv[0]) is filtered (to remove full path and so) AFTER the file /tmp/qcop-msg/appname if opened... And Python gives the fullpath as argv[0]... So I could solve this easily just by filtering the args given to my QPEApplication constructor... It's trivial but one can spen time on it (as I did). Maybe a little TIP file (or FAQ entry) on the PyQt site would be nice ? Last, I use a QMainWindow derived class as main widget. But the problem is that the QMainApplication does NOT declare slots which are used by QApplication to send messages like "newDocument" or "accept". In the C++ world, you just have to subclass QMainApplication declaring thoses fuctions... But if I subclass it with a python class, messages are not transmited... I haven't looked deeply, but I guess it is not possible for a C++ class to send a message (at the c++ level. When I say send, I mean calling the slot function as done in QPEApplication code for "setDocument", for example) to a purely python defined slot... (Am I wrong ?) In this case you (I mean Phil) should provide a QPEMainApplication class with an associated python binding which just declare thoses required slot functions as virtual, so user can redefine them at Python level. It is what I have done for my little app, but it would be nice to have that explained and implemented in PyQt... Thanks for any answer... David Douard PS: I am not on the ML, so please CC me back. Thank you. From mickey at tm.informatik.uni-frankfurt.de Tue Aug 13 14:52:01 2002 From: mickey at tm.informatik.uni-frankfurt.de (Michael Lauer) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] PyQt 3.3.2 for QtEmbedded Message-ID: <1029243100.16104.6.camel@gandalf.tm.informatik.uni-frankfurt.de> Hi, Despite frequent rebuilds and switching environments it still seems impossible for me to build sip and pyqt 3.3.1 with Qt/Embedded. It always tries to bind itself to Qt despite the knowledge (the output says Qt Embedded 2.3.2 is being used) of building with Qt/Embedded. Am I the only one using this combination? Is this working for anyone? So far, it's back to 3.2.4 for me - since the build process changed, no version of pyqt binds to qt/embedded here. I'm really out of ideas... Yours sincerely, -- :M: -------------------------------------------------------------------------- Dipl.-Inf. Michael 'Mickey' Lauer mickey@tm.informatik.uni-frankfurt.de Raum 10b - ++49 69 798 28358 Fachbereich Informatik und Biologie -------------------------------------------------------------------------- From aloy at ctv.es Tue Aug 13 19:35:01 2002 From: aloy at ctv.es (Antoni Aloy =?iso-8859-1?q?L=F3pez?=) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Success installing pyKDE but error in pyuic Message-ID: <200208131941.52085.aloy@ctv.es> Hello! After all the problems I thought the best solution was to install everything again, so yesterday I've downloaded pyQT and pyKDE. Everything compiles and they are installed now. Thank you for your help Phil! Now I make a design with qt dessigner using some kde widgets and I try to generate the source code with pyuic, but I get this error: pyuic -x -o form1.py form1.ui pyuic: relocation error: /usr/kde/3/lib/libkio.so.4: undefined symbol: unregisterStaticDeleter__7KGlobalP18KStaticDeleterBase I have no problems with the Qt widgets. Any ideas? -- Antoni Aloy L?pez Binissalem - Mallorca Linux Registered User # 210825 Gentoo Powered From boud at valdyas.org Wed Aug 14 09:18:00 2002 From: boud at valdyas.org (Boudewijn Rempt) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Looking for a job... Message-ID: <200208140915.09720.boud@valdyas.org> Dear people, I feel it's a bit of a misuse of the PyKDE list, but I hope people won't mind too much. It appears that the company I work for is going to disappear in a few months, despite all the hard work we put in it for the past year, so I'm looking for a new job. I'd prefer something related to Python, PyQt or Qt, so I thought I'd announce my availability here... -- Boudewijn Rempt | http://www.valdyas.org/cv.html From jbublitz at nwinternet.com Wed Aug 14 11:07:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Success installing pyKDE but error in pyuic In-Reply-To: <200208131941.52085.aloy@ctv.es> Message-ID: On 13-Aug-02 Antoni Aloy López wrote: > Now I make a design with qt dessigner using some kde widgets and > I try to generate the source code with pyuic, but I get this > error: > pyuic -x -o form1.py form1.ui > pyuic: relocation error: /usr/kde/3/lib/libkio.so.4: undefined > symbol: > unregisterStaticDeleter__7KGlobalP18KStaticDeleterBase > I have no problems with the Qt widgets. > Any ideas? I get the same error on the 'first.ui' PyKDE example with pyuic3, but it generates a correct 'first.py' anyway. Was 'form.py'generated? The Qt2 (pyuic2) version runs without the error. The symbol referenced above should be undefined in libkio.so.4 - it's defined in libkdecore.so (KGLobal and KStaticDeleterBase are kdecore classes). If it wasn't defined, 'import kdecore' would fail. Jim From mickey at tm.informatik.uni-frankfurt.de Wed Aug 14 11:25:01 2002 From: mickey at tm.informatik.uni-frankfurt.de (Michael Lauer) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Quickexec and Packaging question In-Reply-To: <200208131334.09477.douard@magic.fr> References: <200208131334.09477.douard@magic.fr> Message-ID: <1029317086.16105.18.camel@gandalf.tm.informatik.uni-frankfurt.de> Salut David, My research group and I are also working on PyQt applications, maybe we can share our findings here. There don't seem to be many people working on this. > Also, does anyone have any experiment with packaging an PyQt app (I mean in > the "final end user" goal : no python installed on the PDA, and so on...) I rely on the standard ipk system. >First, I am still obliged to comment out a few lines in the sip files >in order to compile PyQt... (gcc complains about accessing vars which >are declared private in the master C++ class and thus not availbale in >any derived class---which is normal. So I still do not understand how >PyQt can be compiled out of the box. NB: I am using Qtopia as available >to Trolltech's site, GPL version). No problems here to compile PyQt 3.2.4 - which Python and which Qt are you using? Did you manage to compile PyQt 3.3.2 with Qt/Embedded ??? >Then I have spent almost a day to realize that I had many problems with >the Qtopia integration of my app which where du to the fact that the >/tmp/qcop-msg file was not opened, read end destroyed by my app... >Which was due to the fact that, in the QApplication code (file >qapplication.cpp), the name of the program (argv[0]) is filtered (to >remove full path and so) AFTER the file /tmp/qcop-msg/appname if >opened... And Python gives the fullpath as argv[0]... >So I could solve this easily just by filtering the args given to my QPEApplication constructor... >It's trivial but one can spen time on it (as I did). Maybe a little TIP >file (or FAQ entry) on the PyQt site would be nice ? Nice work, David! I spent a whole lot more than one day to find it... and I have yet to discover, why -- instead of my application icon -- the "Unknown-Document-14" icon is displayed... any idea? Yours, -- :M: -------------------------------------------------------------------------- Dipl.-Inf. Michael 'Mickey' Lauer mickey@tm.informatik.uni-frankfurt.de Raum 10b - ++49 69 798 28358 Fachbereich Informatik und Biologie -------------------------------------------------------------------------- From detlev at die-offenbachs.de Wed Aug 14 13:04:01 2002 From: detlev at die-offenbachs.de (Detlev Offenbach) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] ANN: Version 2.1.3 of eric available Message-ID: <200208141302.51336.detlev@majestix.gallien.de> Hi folks, I have made version 2.1.3 of eric available. With this version I introduce a UI in different languages. Please be aware that you need at least PyQt snapshot-20020812 or newer due to a bug in earlier versions. At the moment it contains translations for English (the default) and German. Volunteers for additional translation are welcome. Please drop me a mail and tell me the two letter country code you would like to do and I will send you the respective Qt-Linguist file. As usual you can download it via the following links. www.die-offenbachs.de/detlev/eric.html www.die-offenbachs.de/detlev/eric_en.html (english page) www.riverbankcomputing.co.uk/pyqt (in the latest snapshot) Regards, Detlev -- Detlev Offenbach detlev@die-offenbachs.de From laz at strakt.com Wed Aug 14 14:32:01 2002 From: laz at strakt.com (Fredrik Juhlin) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] SIP and PyQT with debugging symbols Message-ID: <1029328290.21849.21.camel@Raven> Hi! As a part of an effort to build a "debug environment", I've made patches that allows building SIP and PyQT with debugging info by supplying an argument to the respective build.py script. I'm attaching the relevant patches, in case they are of interest. //Fredrik -------------- next part -------------- A non-text attachment was scrubbed... Name: pyqt_debug.patch Type: text/x-patch Size: 5848 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020814/bb4cb4d5/pyqt_debug.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: sip_debug.patch Type: text/x-patch Size: 2359 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020814/bb4cb4d5/sip_debug.bin From verwilst at gentoo.org Wed Aug 14 17:21:00 2002 From: verwilst at gentoo.org (Bart Verwilst) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Making a form full-screen in PyQT? In-Reply-To: <1029328290.21849.21.camel@Raven> References: <1029328290.21849.21.camel@Raven> Message-ID: <200208141719.38935.verwilst@gentoo.org> Hellow! I was wondering if it's possible to make a form full-screen, and cover the whole screen without having the menu on top and such (you know the bar with maximize, minimize, ... forgot the name :o) Thanks in advance! -- Bart Verwilst Gentoo Linux Developer, Release Coordinator Gent, Belgium From martin.preishuber at eclipt.at Wed Aug 14 20:09:01 2002 From: martin.preishuber at eclipt.at (Martin Preishuber) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Mixing PyGTK and PyKDE Message-ID: <1029348468.12883.7.camel@daddy> Hi, I have an existing PyGTK application (ECLiPt SSH Shell, a small applet for starting SSH connections) and I want to create a small PyKDE applet in the system tray which basically just opens the main window of the PyGTK window. I managed to create a small PyKDE application, but somehow it's not possible to mix PyGTK and PyKDE code, because PyGTK needs the mainloop() call to handle all events and this mainloop() blocks execution of PyKDE code ... is there any possibility to work around this problem ? Martin -- Martin Preishuber - IT Expert, Student, SysAdmin http://www.eclipt.at, mailto:Martin.Preishuber@eclipt.at I love children. Especially when they cry -- for then someone takes them away. -- Nancy Mitford From jbublitz at nwinternet.com Wed Aug 14 22:00:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Mixing PyGTK and PyKDE In-Reply-To: <1029348468.12883.7.camel@daddy> Message-ID: On 14-Aug-02 Martin Preishuber wrote: > I have an existing PyGTK application (ECLiPt SSH Shell, a small > applet for starting SSH connections) and I want to create a > small PyKDE applet in the system tray which basically just opens > the main window of the PyGTK window. I managed to create a small > PyKDE application, but somehow it's not possible to mix PyGTK > and PyKDE code, because PyGTK needs the mainloop() call to > handle all events and this mainloop() blocks execution of PyKDE > code ... is there any possibility to work around this problem ? You could look at QObject/QApplication eventFilter/processOneEvent and see if there's any way to use those to accomplish what you want (KApplication inherits those). I think what I'd consider instead is having the PyKDE program fork the PyGTK program and use some sort of IPC (like sockets) to pass events between the two. PyKDE has a pretty large memory footprint for writing applets; I expect PyGTK is pretty big too. Jim From laz at strakt.com Thu Aug 15 15:06:00 2002 From: laz at strakt.com (Fredrik Juhlin) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Memory leak when overriding QListViewItem.key()? Message-ID: <1029416747.11220.55.camel@Raven> Hi! While trying to figure out the best way to control the sorting of a QListView, I stumbled over what seems to be some sort of memory leak when I override QlistViewItem.key(). When I run the code below, my python process uses aprox 58MB. If I uncomment the key() method in MyListItem, it uses 150MB. If there's a reasonable explanation for this that eludes me, or if I'm simply doing something horribly wrong, please let me know :) //Fredrik #!/usr/bin/env python import qt import sys class MyListItem(qt.QListViewItem): def key(self, column, ascending): return qt.QListViewItem.key(self, column, ascending) pass if __name__ == '__main__': app = qt.QApplication(sys.argv) lw = qt.QListView() lw.addColumn('Mepp') for x in xrange(5000): li = MyListItem(lw) li.setText(0, str(x)) app.setMainWidget(lw) lw.show() app.exec_loop() From phil at river-bank.demon.co.uk Sat Aug 17 02:41:00 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] SIP and PyQT with debugging symbols References: <1029328290.21849.21.camel@Raven> Message-ID: <3D5D9B77.5070405@river-bank.demon.co.uk> Fredrik Juhlin wrote: > Hi! > > As a part of an effort to build a "debug environment", I've made patches > that allows building SIP and PyQT with debugging info by supplying an > argument to the respective build.py script. I'm attaching the relevant > patches, in case they are of interest. Applied - though I've changed the flag to be -u rather than -o. Thanks, Phil From phil at river-bank.demon.co.uk Sat Aug 17 13:23:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] QtPE Missing features References: <200208131334.21289.douard@magic.fr> Message-ID: <3D5E1CE8.1020607@river-bank.demon.co.uk> David Douard wrote: > Hi list, > Hi Phil > > I know there are many things to do for such a wrapper, but I am using Qtopia > classes (TrollTech's 1.5.0 GPL version) in my PyQt application for the Zaurus > which are not included in PyQt, and quite easy to add, namely: > > Config > AppLnk/DocLnk (and Sets) > FileManager > FileSelector > Resource > > All thoses are really easy to add to PyQt (what I did). Should I send you > (Phil) a patch for these, so they can be included in PyQt ? (But these are > really trivial changes). A patch would be great. > I have not tried other Qtopia classes, but I think they must but also easy to > add... > The problem I have encountered is with the DCopEnvelope. The normal use of it > is to call the constructor with 2 params (channel and message). But you then > have to call the operator << on the created object to pass arguments, and > the message is actually sent when the object it deleted (almost all the code > of the object is in the destructor). > > What is the right way to wrap it ? I have tried to write a wrapp Member Code > so you give the 2 required params and an optional list of strings... But I > does not work, and I don't have time to guess the way Sip works in details... > Anoyone did something ? You can implement __lshift__() for the class - see how QStringList implements __len__(), __getitem__() etc. Phil From phil at river-bank.demon.co.uk Sat Aug 17 13:25:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] about QPEApplication and QMainWindow References: <200208131334.23858.douard@magic.fr> Message-ID: <3D5E1A3F.6000906@river-bank.demon.co.uk> David Douard wrote: > Hi ! > > I am developping a little app (for the zaurus contest) using PyQt. And I have > found several problems... > > First, I am still obliged to comment out a few lines in the sip files in order > to compile PyQt... (gcc complains about accessing vars which are declared > private in the master C++ class and thus not availbale in any derived > class---which is normal. So I still do not understand how PyQt can be > compiled out of the box. NB: I am using Qtopia as available to Trolltech's > site, GPL version). Probably because I am using the SDK provided to the original contest entrants. I am not using the current GPL version - I will do when I get some spare time. > Then I have spent almost a day to realize that I had many problems with the > Qtopia integration of my app which where du to the fact that the > /tmp/qcop-msg file was not opened, read end destroyed by my app... Which was > due to the fact that, in the QApplication code (file qapplication.cpp), the > name of the program (argv[0]) is filtered (to remove full path and so) AFTER > the file /tmp/qcop-msg/appname if opened... And Python gives the fullpath as > argv[0]... > So I could solve this easily just by filtering the args given to my > QPEApplication constructor... > > It's trivial but one can spen time on it (as I did). Maybe a little TIP file > (or FAQ entry) on the PyQt site would be nice ? > > Last, I use a QMainWindow derived class as main widget. But the problem is > that the QMainApplication does NOT declare slots which are used by > QApplication to send messages like "newDocument" or "accept". In the C++ > world, you just have to subclass QMainApplication declaring thoses > fuctions... But if I subclass it with a python class, messages are not > transmited... I haven't looked deeply, but I guess it is not possible for a > C++ class to send a message (at the c++ level. When I say send, I mean > calling the slot function as done in QPEApplication code for "setDocument", > for example) to a purely python defined slot... (Am I wrong ?) Yes you are wrong. You can connect a C++ signal to any Python callable object (ie. a function or a method). If your Python slots are not being called then the problem is probably elsewhere. > In this case you (I mean Phil) should provide a QPEMainApplication class with > an associated python binding which just declare thoses required slot > functions as virtual, so user can redefine them at Python level. > It is what I have done for my little app, but it would be nice to have that > explained and implemented in PyQt... This isn't necessary. Phil From phil at river-bank.demon.co.uk Sat Aug 17 13:26:00 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Problem compiling PyQt References: <191CBBF91062D411855D00D0B76F1C30E2420A@PROXIMA> Message-ID: <3D5E17E6.3070004@river-bank.demon.co.uk> Philippe FREMY wrote: > >>Philippe FREMY wrote: >> >> >>>>>d:/software/PyQt-3.3.2 > nmake >>>>> >>>>>Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 >>>>>Copyright (C) Microsoft Corp 1988-1998. All rights reserved. >>>>> >>>>> cd qt >>>>> nmake >>>>> >>>>>Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 >>>>>Copyright (C) Microsoft Corp 1988-1998. All rights reserved. >>>>> >>>>> link /NOLOGO /DEBUG /SUBSYSTEM:windows /DLL >>>>>/OUT:d:\software\Python22\Li >>>>>b\site-packages\libqtc.pyd @c:\WINNT\TEMP\nma01708. >>>>>LINK : fatal error LNK1104: cannot open file "python22_d.lib" >>>>>NMAKE : fatal error U1077: 'link' : return code '0x450' >>>>>Stop. >>>>>NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual >>>>>Studio\VC98\bin\n >>>>>make.exe"' : return code '0x2' >>>>> >>>>>I checked, I haven't got any python22_d.lib file on my harddrive. I >>>>> > have > >>>>>however a python22.lib . How do I switch from one to the other ? >>>>> >>>>> >>>>I'm not sure how you've got the /DEBUG switch specified as qmake will be >>>> > >>>>adding this. How did you build Qt? >>>> >>>> >>>My Qt was built from source with the debug flag. Does it influence ? >>> >> >>It looks like it does. >> >> > > I find the behaviour really strange. The makefile generated by qt.pro > (attached) contains the /DEBUG flag but the qt.pro does not. So it looks > like it has been added by build.py . Does build.py have a debug mode ? It does now as I've added the patch from Fredrik Juhlin, but this won't affect you. I assume what's going on is that when you build a debug version of Qt you also get a debug version of qmake that generates Makefiles with debugging enabled. Or it is simply a bug in qmake. > Even if the debug was added by build.py, I don't know how it manages to pick > python22_d.lib instead of python22.lib . I have managed to open the > temporary file created by nmake to link and it does contains python22.lib . > I really wonder where this python22_d.lib comes from. Presumably it's a result of passing /DEBUG to the linker. Phil From cbaurtx at netzero.com Sat Aug 17 13:31:00 2002 From: cbaurtx at netzero.com (Christof Baur) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] QTableITem Validator Message-ID: <200208170020.56754.cbaurtx@netzero.com> Why does this python code not work ? I use Qt3.03, Python 2.2 and pyqt 3.0 (I am not 100% sure about the PyQt version) Please send your comments also to cbaurtx@netzero.com. Thanks. import sys from qt import * from qttable import * class Test(QWidget): def __init__(self,parent = None,name = None,fl = 0): QWidget.__init__(self,parent,name,fl) if name == None: self.setName("TestValidator") self.resize(733,513) self.setSizePolicy(QSizePolicy(0,0,0,0,self.sizePolicy().hasHeightForWidth())) self.setMaximumSize(QSize(790,544)) f = QFont(self.font()) self.setFont(f) self.setCaption(self.trUtf8("TestValidator")) self.Item1 = [] self.Table1 = QTable(self,"Table1") self.Table1.setGeometry(QRect(35,15,616,416)) self.Table1.setFrameShape(QTable.NoFrame) self.Table1.setFrameShadow(QTable.Plain) self.Table1.setLineWidth(0) self.Table1.setNumRows(4) self.Table1.setNumCols(4) self.Table1.setShowGrid(1) self.Item1.append ( IntTableItem(self.Table1,1,"")) self.Item1[0].setText("123") self.Table1.setItem(1,1,self.Item1[0]) class IntLineEdit (QLineEdit): def __init__(self,parent = None,min = - 32000,max = 32000): QLineEdit.__init__(self,parent) self.setValidator(QIntValidator(min,max,self)) class IntTableItem(QTableItem): def createEditor(self): IntLineEdit(self.table().viewport(),-5000,5000) def setContentFromEditor (createEditor): self.setText (IntLineEdit().currentText()) if __name__ == "__main__": a = QApplication(sys.argv) QObject.connect(a,SIGNAL("lastWindowClosed()"),a,SLOT("quit()")) w = Test() a.setMainWidget(w) w.show() a.exec_loop() From phil at river-bank.demon.co.uk Sat Aug 17 15:10:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] QTableITem Validator References: <200208170020.56754.cbaurtx@netzero.com> Message-ID: <3D5E4AFC.6000206@river-bank.demon.co.uk> Christof Baur wrote: > Why does this python code not work ? > I use Qt3.03, Python 2.2 and pyqt 3.0 (I am not 100% sure about the PyQt > version) > > Please send your comments also to cbaurtx@netzero.com. Thanks. > > > import sys > from qt import * > from qttable import * > > > class Test(QWidget): > def __init__(self,parent = None,name = None,fl = 0): > QWidget.__init__(self,parent,name,fl) > > if name == None: > self.setName("TestValidator") > > self.resize(733,513) > > self.setSizePolicy(QSizePolicy(0,0,0,0,self.sizePolicy().hasHeightForWidth())) > self.setMaximumSize(QSize(790,544)) > f = QFont(self.font()) > self.setFont(f) > self.setCaption(self.trUtf8("TestValidator")) > > > self.Item1 = [] > > self.Table1 = QTable(self,"Table1") > self.Table1.setGeometry(QRect(35,15,616,416)) > > self.Table1.setFrameShape(QTable.NoFrame) > self.Table1.setFrameShadow(QTable.Plain) > self.Table1.setLineWidth(0) > self.Table1.setNumRows(4) > self.Table1.setNumCols(4) > self.Table1.setShowGrid(1) > > > self.Item1.append ( IntTableItem(self.Table1,1,"")) > > self.Item1[0].setText("123") > self.Table1.setItem(1,1,self.Item1[0]) > > class IntLineEdit (QLineEdit): > def __init__(self,parent = None,min = - 32000,max = 32000): > QLineEdit.__init__(self,parent) > self.setValidator(QIntValidator(min,max,self)) > > > class IntTableItem(QTableItem): > def createEditor(self): > IntLineEdit(self.table().viewport(),-5000,5000) > > def setContentFromEditor (createEditor): > self.setText (IntLineEdit().currentText()) > > > > if __name__ == "__main__": > a = QApplication(sys.argv) > QObject.connect(a,SIGNAL("lastWindowClosed()"),a,SLOT("quit()")) > w = Test() > a.setMainWidget(w) > w.show() > a.exec_loop() One obvious problem is the lack of an __init__() in IntTableItem. Phil From phil at river-bank.demon.co.uk Sat Aug 17 15:13:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Memory leak when overriding QListViewItem.key()? References: <1029416747.11220.55.camel@Raven> Message-ID: <3D5E4BB6.7020603@river-bank.demon.co.uk> Fredrik Juhlin wrote: > Hi! > > While trying to figure out the best way to control the sorting of a > QListView, I stumbled over what seems to be some sort of memory leak > when I override QlistViewItem.key(). > > When I run the code below, my python process uses aprox 58MB. If I > uncomment the key() method in MyListItem, it uses 150MB. > > If there's a reasonable explanation for this that eludes me, or if I'm > simply doing something horribly wrong, please let me know :) > > //Fredrik > > #!/usr/bin/env python > > import qt > import sys > > class MyListItem(qt.QListViewItem): > def key(self, column, ascending): > return qt.QListViewItem.key(self, column, ascending) > pass > > > if __name__ == '__main__': > app = qt.QApplication(sys.argv) > lw = qt.QListView() > lw.addColumn('Mepp') > for x in xrange(5000): > li = MyListItem(lw) > li.setText(0, str(x)) > > app.setMainWidget(lw) > lw.show() > app.exec_loop() What about MyListItem.__init__()? Phil From laz at strakt.com Mon Aug 19 09:38:00 2002 From: laz at strakt.com (Fredrik Juhlin) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Memory leak when overriding QListViewItem.key()? In-Reply-To: <3D5E4BB6.7020603@river-bank.demon.co.uk> References: <1029416747.11220.55.camel@Raven> <3D5E4BB6.7020603@river-bank.demon.co.uk> Message-ID: <1029742624.13090.33.camel@Raven> On Sat, 2002-08-17 at 15:12, Phil Thompson wrote: > Fredrik Juhlin wrote: > > > Hi! > > > > While trying to figure out the best way to control the sorting of a > > QListView, I stumbled over what seems to be some sort of memory leak > > when I override QlistViewItem.key(). > > > > When I run the code below, my python process uses aprox 58MB. If I > > uncomment the key() method in MyListItem, it uses 150MB. > > > > If there's a reasonable explanation for this that eludes me, or if I'm > > simply doing something horribly wrong, please let me know :) > > What about MyListItem.__init__()? Just overriding __init__() does not cause any difference in memory consumption. I tried a few others, with the following result: text(): Increased memory usage (Seemingly identical to overriding key()) compare(): No increase in memory usage //Fredrik Juhlin #!/usr/bin/env python import qt import sys class MyListItem(qt.QListViewItem): def __init__(self, parent): qt.QListViewItem.__init__(self, parent) # NOTE: Uncomment either of the methods below for memory-eating # behaviour # def key(self, column, ascending): # return qt.QListViewItem.key(self, column, ascending) # def text(self, column): # return qt.QListViewItem.text(self, column) if __name__ == '__main__': app = qt.QApplication(sys.argv) lw = qt.QListView() lw.addColumn('Mepp') for x in xrange(5000): li = MyListItem(lw) li.setText(0, str(x)) app.setMainWidget(lw) lw.show() app.exec_loop() From laz at strakt.com Mon Aug 19 09:40:01 2002 From: laz at strakt.com (Fredrik Juhlin) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] SIP and PyQT with debugging symbols In-Reply-To: <3D5D9B77.5070405@river-bank.demon.co.uk> References: <1029328290.21849.21.camel@Raven> <3D5D9B77.5070405@river-bank.demon.co.uk> Message-ID: <1029742717.13221.36.camel@Raven> On Sat, 2002-08-17 at 02:40, Phil Thompson wrote: > Fredrik Juhlin wrote: > > > Hi! > > > > As a part of an effort to build a "debug environment", I've made patches > > that allows building SIP and PyQT with debugging info by supplying an > > argument to the respective build.py script. I'm attaching the relevant > > patches, in case they are of interest. > > > Applied - though I've changed the flag to be -u rather than -o. Great! I'm glad you deemed it useful. //Fredrik From littlewisp at gmx.net Mon Aug 19 15:54:00 2002 From: littlewisp at gmx.net (Marc Schmitt) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] precompiled rpm-Packages (any links?) Message-ID: <8334.1029754210@www9.gmx.net> Hi all, I'm looking for some precompiled SuSE packages. As a PyQt user I can say it's a great stuff and so easy, so I'd like use PyKDE too. But unfortunatly I wasn't able to find any rpms. I tried to compile PyKDE-3.3.2-2.tar.gz on my own but after several "configure" errors I gave up. The last one was Error: Couldn't import qt module from PyQt -- from line 671 in build.py which is wrong, because an "import qt" just works fine. But, instead of compiling the package myself, any (suse)rpm package would already make me happy. So, does anyone have a url for me ? (btw, I think there should be a link to the latest precompiled packages somewhere, to save lots of people from the compiling issue) many thanks, -Marc :) -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From jbublitz at nwinternet.com Mon Aug 19 17:02:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] precompiled rpm-Packages (any links?) In-Reply-To: <8334.1029754210@www9.gmx.net> Message-ID: On 19-Aug-02 Marc Schmitt wrote: > I'm looking for some precompiled SuSE packages. As a PyQt user I > can say it's a great stuff and so easy, so I'd like use PyKDE > too. But unfortunatly I wasn't able to find any rpms. I tried > to compile PyKDE-3.3.2-2.tar.gz on my own but after several > "configure" errors I gave up. The last one was > Error: Couldn't import qt module from PyQt -- from line 671 in > build.py The line that's failing is: from qt import PYQT_VERSION You can try this line in the Python interpreter and see if it works there. Possible problems would be that the PyQt and PyKDE versions don't match (both need to be 3.3.2) or that build.py is being run with a different version of Python than the one that has PyQt installed - if you check the line above in the interpreter be sure to use the same path to invoke the interpreter that you used to invoke Python to run build.py. In general, Python isn't finding the symbol PYQT_VERSION in libqtcmodule.so for some reason, or else isn't finding the PyQt module at all. > which is wrong, because an "import qt" just works fine. But, > instead of compiling the package myself, any (suse)rpm package > would already make me happy. So, does anyone have a url for me? > (btw, I think there should be a link to the latest precompiled > packages somewhere, to save lots of people from the compiling > issue) many thanks, There aren't any PyKDE rpm's that I know of. Debian has packages available (they still require compiling) and someone from FreeBSD was working on adding PyKDE to the 'ports' system (which also still requires compiling). The biggest problems with building packages for PyKDE are time, storage space and bandwidth. PyKDE in the latest (compressed) release is a little over 600KB; the compiled libs and other stuff run over 15MB (uncompressed), plus the current release contains support for all platforms, KDE from 2.1.1->3.0.2, any corresponding Qt version, different gcc versions, Python from 1.5.2 forward, etc. If anyone wants to volunteer to package for specific versions/distributions, I'll provide whatever assistance I can. Jim From paul.butcher at asa.co.uk Tue Aug 20 11:55:01 2002 From: paul.butcher at asa.co.uk (Paul Butcher) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Problem with PyQt-3.3-Qt-NC Message-ID: I have just upgraded to Python 2.2.1 (Win32 reference install from www.python.org) and at same time upgraded to PyQt-3.3-Qt-NC.exe. I have Qt-2.3.0-NC edition installed. I get the following error running any PyQt example: site-packages\qt.py line 404: libqtc.SipCallCtor(70, self, args) Attribute Error: 'module' object has no attribute 'qtIsX11' Could someone advise what is wrong? I previously had Python 2.1 and PyQt-2.5-Qt-NC running with no problems. Paul Butcher Alton, Hants, UK From gregory.p.green at boeing.com Wed Aug 21 01:33:01 2002 From: gregory.p.green at boeing.com (Green, Gregory P) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] QTextDrag problems Message-ID: <35D93365CC362C40946B159819F5B761ECB996@XCH-NW-20.nw.nos.boeing.com> I am trying to decode the text in a QTextDrag object, received by a QListView.contentsDropEvent method. The c++ signature of the object is: static bool decode(const QMimeSource*, QString&) The second argument is intended to receive the decoded text. PyQt copies this signature exactly, so that a string needs to be passed, and a boolean is received. That doesn't allow retrieval of the string though. -- Greg Green From jbublitz at nwinternet.com Wed Aug 21 08:04:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] PyKDE Link Problem Message-ID: I have a PyKDE upgrade to KDE 3.0.3 mostly done, but am stuck on one problem. The kjs module builds and links, but any attempt to import it results in: ImportError: /usr/lib/python2.2/site-packages/libkjscmodule.so: undefined symbol: __tiQ23KJS8ValueImp It turns out that KDE's libkjs.so has a symbol: __tfQ23KJS8ValueImp while PyKDE's libkjscmodule.so is looking for: __tiQ23KJS8ValueImp I believe these correspond to the ValueImp constructor. ValueImp is an abstract base class, and is a base type for other classes in the module, so it's fairly difficult to ignore and still have the module anywhere near complete. Anyone know what the difference between __ti and __tf is and why it occurs? I've rebuilt the kdelibs (SuSE stripped the symbols from their rpm kdelibs :( ) but still get the same behaviour (same gcc/ld for KDE/PyKDE). There doesn't appear to be anything unusual in the KDE link. KDE 3.0.0 has the same symbol in it's libkjs, but as far as I know PyKDE's kjs module works fine with KDE 3.0.0. I'd appreciate it if anyone running PyKDE on KDE 3.0.x could do: python -c 'import kjs' and let me know if it throws an error. It would be interesting to know, for example, if it works with RH/gcc2.96 but not gcc2.95. That brings up another question: is anyone using the kjs module? Put another way: would anyone miss it? Otherwise, watch for the KDE 3.0.3 upgrade (perhaps minus a working kjs) in a few days. It'll be PyKDE-3.3.2-3. The only other change will be a PyKDE wrapper for pyuic and a README.pyuic covering stuff on this list related to pyuic and PyKDE. Jim From littlewisp at gmx.net Wed Aug 21 09:08:01 2002 From: littlewisp at gmx.net (Marc Schmitt) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] precompiled rpm-Packages (any links?) In-Reply-To: References: Message-ID: <200208210859.05973.littlewisp@gmx.net> On Montag, 19. August 2002 16:37, Jim Bublitz wrote: > The line that's failing is: > > from qt import PYQT_VERSION > > You can try this line in the Python interpreter and see if it works > there. Possible problems would be that the PyQt and PyKDE versions > don't match (both need to be 3.3.2) or that build.py is being run Yes, you are right. I tried to import PYQT_VERSION, which failed - the versions don't match. Suse one's is 3.0, while I downloaded 3.3.2. :/ > If anyone wants to volunteer to package for specific > versions/distributions, I'll provide whatever assistance I can. I'm just recompiling sip, pyqt and pykde with checkinstall. sip has already finished. If everything works, I hope they finish today. One problem I have (and think I've solved sufficiently) is the make - make install procedure. "Normally" one would expect to compile with make, and install with make install - checkinstall (which i use for packaging) requires a single command for installation. so i wrote a file containing "make && make install" saving as ./install.sh and execteuted "checkinstall ./install.sh". This should work, but when I get a compile-error after some files have already been installed it results in an half installation. So I'd like to know, is there any way to separate compilation (as user) from installation as root to prevent compile-system pollution ? I'll post an update lateron, hopefully containing three rpms and a very little howto-make-rpms-easily. :o) Marc From jbublitz at nwinternet.com Wed Aug 21 11:11:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] pyuic problems Message-ID: Regarding the pyuic problems mentioned on the list earlier: Today I upgraded to Qt 3.0.5 from 3.0.3. I recompiled PyQt and afterwards pyuic didn't work at all (under any circumstances - I couldn't even get the 'Usage' help to display). I got the same relocation error, but for QGPluginManager. I ran qt3/bin/qtconfig and the library path for qt3 plugins still pointed to qt-3.0.3, so I changed that, but it seemed to have no effect. Next, I went to the PyQt/pyuic3 directory and ran 'make clean', 'make' and 'make install' from that directory (the last two as root of course). pyuic now works perfectly. One of the above two steps (or perhaps both) fixed it for my system. I have no reason for why it works now, however. pyuic3 is the subdirectory listed in the top level PyQt makefile if anyone is curious, so that wasn't the problem. Jim From cavallo at casa.darktech.org Wed Aug 21 17:05:00 2002 From: cavallo at casa.darktech.org (Antonio Cavallo) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] precompiled rpm-Packages (any links?) In-Reply-To: <200208210859.05973.littlewisp@gmx.net> Message-ID: Hy, Here you can find the spec files for sip and pyqt (both in snapshoot dir) suitables for a SuSE-8.0 (but i guess they will be ok for any rpm based distro): i hope these will help you as base for a rpm based package. best regards, antonio -------------- next part -------------- %define python_site %(echo `python -c "import sys; print (sys.prefix + '/lib/python' + sys.version[:3] + '/site-packages/')"`) %define python_include %(echo `python -c "import sys; print (sys.prefix + '/include/python' + sys.version[:3] )"`) Name: pyqt Version: 20020817 Release: 1 Copyright: Riverbank Computing Limited Group: Development/Libraries Source: PyQt-snapshot-20020817.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-root Packager: Antonio Cavallo Summary: bindings for the qt toolkit %description These are the Python bindings for Qt. %prep %setup -n PyQt-snapshot-20020817 %build bindir=$RPM_BUILD_ROOT%{_bindir} python_site=$RPM_BUILD_ROOT/%{python_site} python_include=$RPM_BUILD_ROOT/%{python_include} mkdir -p $bindir $python_site $python_include python build.py -b $bindir -d $python_site -c -lqt-mt make %install make install make install-eric %clean rm -rf $RPM_BUILD_ROOT %files %doc LICENSE %doc README %doc README.Linux %doc NEWS %doc THANKS %{_bindir}/eric %{_bindir}/pyuic %{_bindir}/qtunittest %{_bindir}/helpviewer %{_bindir}/pylupdate %{python_site}/libqtsqlcmodule.so.1.0 %{python_site}/eric/Scanner.py %{python_site}/eric/BreakpointForm.pyc %{python_site}/eric/FilterDialog.py %{python_site}/eric/Icons.py %{python_site}/eric/eric.pyc %{python_site}/eric/helpviewer.py %{python_site}/eric/Scanner.pyc %{python_site}/eric/SourceViewer.pyc %{python_site}/eric/BookmarkDialog.py %{python_site}/eric/eric_de.qm %{python_site}/eric/DebugProtocol.py %{python_site}/eric/FilterForm.pyc %{python_site}/eric/DebugServer.py %{python_site}/eric/Info.py %{python_site}/eric/FilterDialog.pyc %{python_site}/eric/BookmarkDialog.pyc %{python_site}/eric/Config.pyc %{python_site}/eric/DebugServer.pyc %{python_site}/eric/Icons.pyc %{python_site}/eric/eric.py %{python_site}/eric/FilterForm.py %{python_site}/eric/HelpWindow.pyc %{python_site}/eric/DebugClient.pyc %{python_site}/eric/BookmarkForm.py %{python_site}/eric/qtunittest.py %{python_site}/eric/UnittestDialog.pyc %{python_site}/eric/SourceViewer.py %{python_site}/eric/Explorer.pyc %{python_site}/eric/Info.pyc %{python_site}/eric/UnittestForm.py %{python_site}/eric/VariablesViewer.pyc %{python_site}/eric/HelpWindow.py %{python_site}/eric/VariablesViewer.py %{python_site}/eric/Shell.pyc %{python_site}/eric/UnittestForm.pyc %{python_site}/eric/BreakpointForm.py %{python_site}/eric/DebugClient.py %{python_site}/eric/Shell.py %{python_site}/eric/BreakpointDialog.pyc %{python_site}/eric/AsyncIO.pyc %{python_site}/eric/BookmarkForm.pyc %{python_site}/eric/qtunittest.pyc %{python_site}/eric/UserInterface.py %{python_site}/eric/Config.py %{python_site}/eric/UnittestDialog.py %{python_site}/eric/helpviewer.pyc %{python_site}/eric/AsyncIO.py %{python_site}/eric/DebugProtocol.pyc %{python_site}/eric/UserInterface.pyc %{python_site}/eric/Explorer.py %{python_site}/eric/BreakpointDialog.py %{python_site}/libqtcmodule.so.1 %{python_site}/libqtnetworkcmodule.so %{python_site}/qtgl.py %{python_site}/qt.py %{python_site}/libqttablecmodule.so.1.0.0 %{python_site}/libqtnetworkcmodule.so.1 %{python_site}/libqtxmlcmodule.so.1.0 %{python_site}/libqtnetworkcmodule.so.1.0 %{python_site}/libqtxmlcmodule.so %{python_site}/libqttablecmodule.so %{python_site}/libqtglcmodule.so.1.0 %{python_site}/qtcanvas.pyc %{python_site}/qtsql.pyc %{python_site}/qtnetwork.py %{python_site}/libqtcanvascmodule.so.1.0 %{python_site}/libqtcmodule.so.1.0.0 %{python_site}/libqttablecmodule.so.1.0 %{python_site}/libqtglcmodule.so %{python_site}/libqtsqlcmodule.so.1.0.0 %{python_site}/libqtglcmodule.so.1.0.0 %{python_site}/libqtcanvascmodule.so.1 %{python_site}/libqtcmodule.so.1.0 %{python_site}/libqtsqlcmodule.so.1 %{python_site}/libqtcmodule.so %{python_site}/libqtxmlcmodule.so.1 %{python_site}/libqttablecmodule.so.1 %{python_site}/libqtxmlcmodule.so.1.0.0 %{python_site}/qtgl.pyc %{python_site}/qt.pyc %{python_site}/qttable.pyc %{python_site}/qtnetwork.pyc %{python_site}/qtsql.py %{python_site}/libqtcanvascmodule.so.1.0.0 %{python_site}/libqtglcmodule.so.1 %{python_site}/qttable.py %{python_site}/qtxml.py %{python_site}/libqtnetworkcmodule.so.1.0.0 %{python_site}/qtcanvas.py %{python_site}/libqtsqlcmodule.so %{python_site}/qtxml.pyc %{python_site}/libqtcanvascmodule.so -------------- next part -------------- %define python_site %(echo `python -c "import sys; print (sys.prefix + '/lib/python' + sys.version[:3] + '/site-packages/')"`) %define python_include %(echo `python -c "import sys; print (sys.prefix + '/include/python' + sys.version[:3] )"`) Name: sip Version: 20020817 Release: 1 Copyright: Riverbank Computing Limited Group: Development/Libraries Source: sip-snapshot-20020817.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-root Packager: Antonio Cavallo Summary: python/c++ bindings generator %description SIP is a tool for generating bindings for C++ classes so that they can be accessed as normal Python classes. SIP takes many of its ideas from SWIG but, because it is specifically designed for C++ and Python, is able to generate tighter bindings. SIP is so called because it is a small SWIG. %prep %setup -n sip-snapshot-20020817 %build bindir=$RPM_BUILD_ROOT%{_bindir} python_site=$RPM_BUILD_ROOT/%{python_site} python_include=$RPM_BUILD_ROOT/%{python_include} mkdir -p $bindir $python_site $python_include python build.py -b $bindir -d $python_site -e $python_include -lqt-mt make %install make install %clean rm -rf $RPM_BUILD_ROOT %files %doc LICENSE %doc ChangeLog %doc README %doc NEWS %doc THANKS %{_bindir}/sip %{python_site}/libsip.so %{python_site}/libsip.so.9.1 %{python_site}/libsip.so.9 %{python_site}/libsip.so.9.1.0 %{python_include}/sip.h %{python_include}/sipQt.h From jbublitz at nwinternet.com Wed Aug 21 19:01:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] precompiled rpm-Packages (any links?) In-Reply-To: <200208210859.05973.littlewisp@gmx.net> Message-ID: On 21-Aug-02 Marc Schmitt wrote: > On Montag, 19. August 2002 16:37, Jim Bublitz wrote: >> The line that's failing is: >> from qt import PYQT_VERSION >> You can try this line in the Python interpreter and see if it >> works there. Possible problems would be that the PyQt and PyKDE >> versions don't match (both need to be 3.3.2) or that build.py >> is being run > Yes, you are right. I tried to import PYQT_VERSION, which failed > - the versions don't match. Suse one's is 3.0, while I downloaded > 3.3.2. :/ SuSE and Mandrake seem to time releases to coincide with major changes in KDE, and lately I've been slow in keeping up with KDE, so it's probably unlikely that PyKDE will make it into those distributions in the near future. Even the PyQt they distribute is usually a version behind. It's usually not that bad for PyQt, but PyKDE will probably continue to require a recent download and sip/PyQt update. OTOH, Debian stays current with everything (thanks, Ricardo!) and FreeBSD may have everything on 'ports' in the near future. I'm not sure of the status of any of these on gentoo or similar 'build-from-scratch' distributions. >> If anyone wants to volunteer to package for specific >> versions/distributions, I'll provide whatever assistance I can. > I'm just recompiling sip, pyqt and pykde with checkinstall. sip > has already finished. If everything works, I hope they finish > today. One problem I have (and think I've solved sufficiently) > is the make - make install procedure. "Normally" one would > expect to compile with make, and install with make install - > checkinstall (which i use for packaging) requires a single > command for installation. so i wrote a file containing "make && > make install" saving as ./install.sh and execteuted "checkinstall > ./install.sh". This should work, but when I get a compile-error > after some files have already been installed it results in an > half installation. So I'd like to know, is there any way to > separate compilation (as user) from installation as root to > prevent compile-system pollution ? I've also noticed that the new build system doesn't always stop when a module generates an error (it seems to continue on to the next module anyway), so it's necessary to review the compiler output a little more carefully. What you're interested in would require editing the qmake-generated Makefile for each module. Look at the 'all' target - moving the second half (the part with ../../...$(TARGET) down to the 'install' target should do it (I think). > I'll post an update lateron, hopefully containing three rpms and > a very little howto-make-rpms-easily. :o) I'm looking at where to make rpms available for download and should have an answer in a day or two. It'd probably be better if you mail the rpms directly to me instead of to the list, and I'll get them on a website somewhere. The 'how-to' would also be appreciated - I don't have any experience with rpm packaging - I assume 'checkinstall' is one of the tools that creates rpms (or spec files?) almost automatically? Looks like I'll have to learn something new :) Jim From Roy.Dragseth at cc.uit.no Thu Aug 22 13:58:00 2002 From: Roy.Dragseth at cc.uit.no (Roy Dragseth) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] drag'n drop in pykless. Message-ID: <200208221345.10754.royd@cc.uit.no> Hi. The drag and drop feature doesn't work in pykless.py, it doesn't seem to receive the right dropevents, when you drop a text file on the window it just displays the url for the file not the file itself. It looks like the overloaded method dropEvent never get called because it doesn't print "drop event": def dropEvent(self, event): # #// the user dropped something on our window. # // So we simply use KIO slaves to download the stuff wherever it is. # // The following code respects Qt's DnD tutorial print "drop event" I've just installed pyKDE 3.3.2 and thought I'd have a look at pykless.py for an introduction. System:python 2.2 on RedHat 7.3. Regards, Roy. -- The Computer Center, University of Troms?, N-9037 TROMS?, Norway. phone:+47 77 64 41 07, fax:+47 77 64 41 00 Roy Dragseth, High Performance Computing System Administrator Direct call: +47 77 64 62 56. email: royd@cc.uit.no From paul.butcher at asa.co.uk Thu Aug 22 14:45:01 2002 From: paul.butcher at asa.co.uk (Paul Butcher) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Re: Problem with PyQt-3.3-Qt-NC Message-ID: On Tuesday 20 Aug 2002 10:03, I wrote: > I have just upgraded to Python 2.2.1 (Win32 reference install from > www.python.org) and at same time upgraded to PyQt-3.3-Qt-NC.exe. I have > Qt-2.3.0-NC edition installed. > > I get the following error running any PyQt example: > > site-packages\qt.py line 404: libqtc.SipCallCtor(70, self, args) > Attribute Error: 'module' object has no attribute 'qtIsX11' > > Could someone advise what is wrong? > I previously had Python 2.1 and PyQt-2.5-Qt-NC running with no problems. Apologies for this report - I had an older sip.dll (from PyQt-2.5) still in my path elsewhere (having forgotten I had copied it there a long time ago). With the new sip DLL there are no problems! Paul Butcher Alton, Hants, UK From jbublitz at nwinternet.com Thu Aug 22 17:03:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] drag'n drop in pykless. In-Reply-To: <200208221345.10754.royd@cc.uit.no> Message-ID: On 22-Aug-02 Roy Dragseth wrote: > The drag and drop feature doesn't work in pykless.py, it doesn't > seem to receive the right dropevents, when you drop a text file > on the window it just displays the url for the file not the > file itself. It looks like the overloaded method dropEvent > never get called because it doesn't print "drop event": > def dropEvent(self, event): > # #// the user dropped something on our window. > # // So we simply use KIO slaves to download the stuff > wherever it > is. > # // The following code respects Qt's DnD tutorial > print "drop event" > I've just installed pyKDE 3.3.2 and thought I'd have a look at > pykless.py for an introduction. > System:python 2.2 on RedHat 7.3. Thanks for the input! I'm just about to write another message to the list announcing the next release and apologizing for the quality of the stuff in examples/ and test/. I hope to have this stuff cleaned up and a number of additions by the next major KDE release (3.1), probably later this fall. Jim From littlewisp at gmx.net Thu Aug 22 21:32:01 2002 From: littlewisp at gmx.net (Marc Schmitt) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] precompiled rpm-Packages - some links (very soon) In-Reply-To: References: Message-ID: <200208222129.32065.littlewisp@gmx.net> Hi all, I've written a tiny howto that describes how rpm packages can be created if you don't know anythink about specfiles (like me). I've prepared sip-3.3.2, PyQt-3.3.2 and PyKDE-3.3.2 rpms for SuSE 8.0 running QT-3.0.3 and KDE-3.0.2 (the current SuSE defaults, if you upgraded to KDE-3.0.2 via YOU). Feel free to send me any critics, improvements or flames about the document. I've appended the text-version below, but the links are 'broken'. (the original is a openoffice document, also exported as html). You can find checkinstall under http://asic-linux.com.mx/~izto/checkinstall/ . Jim, I'd really like to send you the rpms, but my last mail bounced from something called "InterScan E-Mail VirusWall NT" when I tried to reply. I'm not sure if I sent it to the right address, so I'll send a "ping" first with one file to see if it passes - the three rpm's are ~ 7.5 mb and I wouldn't like to see them flooding my own mailbox :> Thanks Antonio for the specfiles, but I haven't done anything with specfiles yet. But when I've time l'll take a closer look at them. enjoy -Marc ------------- Short guide howto make PyKDE RPMs (or DEBs) really easy Last changed : 22.08.2002 (c) 2002 by Marc Schmitt 1.Introduction The probably most important thing when you write something are the first few words, so it's wise to use them carefully ... ehm ... well, at least I got this essay started ;) I've had an eye on PyKDE for a long time now - as a kde and python fan - but having to "compile" a software before using it frightens me ... All I wanted were some files I could install in kpackage, start an editor and begin with my real work. It hadn't been that dramatic if I only wanted to do work for myself, but when I want to give away a KDE Application it's clearly not acceptable to require a user to open a shell or even compile something. Another point I don't like (due to aesthetical reasons) are files not belonging to a package, so I started looking for a way out. 2.Step by Step Instructions First, go to the checkinstall-Homepage and download it - or wait, better try searching through your vendors cd's first, at least SuSE delivers it. Now, go and download the lastest sip, PyQt and PyKDE package.(click here) When you have a SuSE 8.0 (I can only write this for my system; if there are any other steps required please take some time and add them to this document. If you're able to write spec-files, feel free to replace this document by a couple of .src.rpms) the next thing to do is to ensure there no sip or PyQt package installed. Do this by typing (as root): rpm -e pyqt rpm -e sip Now goto /tmp and untar the packages, it will give you three directories. Next type (as root) echo "make && make install" > install.sh echo "make && make install && make install-eric" > install-eric.sh chmod 755 ./install*.sh Just wait a bit, I'll explain the meaning lateron. Now comes the bit tricky part - configuration of the three packages (hehe) :) - I had to tweak the commandline-arguments a bit, so if they don't match your config you may need to play with them a bit (and probably post updates to this document). Enter sip and execute: python build.py -l qt-mt cp ../install.sh . checkinstall ./install.sh When you're lucky this will install sip and generate an rpm somewhere under /usr/src/packages/RPMS. But why the install.sh script ? The reason is checkinstall. It has been designed as a replacement for "make install". It expects exactly one command which it will monitor by a prealoaded library and keeps track of all modified and created files. After the program finishes, checkinstall takes these files and simply packs them into a rpm. This doesn't prevent your files from being overwritten, but free's you from all the specfile hassle. Now enter PyQt and do (as root) : python build.py -l qt-mt cp ../install-eric.sh . checkinstall ./install-eric.sh what should generate a PyQt rpm. The last step consists of entering the PyKDE dir and a (again, as root) export KDEDIR=/opt/kde3 python build.py -l qt-mt cp ../install.sh . checkinstall ./install.sh Now, you should have three rpms, which are ready for distribution. DEBs can be generated by "checkinstall -D " . It's also possible to pass more advanced options to checkinstall, but best look at them on your own ("checkinstall -help"). Sure, it's not as flexible as using specfiles but it's simple, and gives you instantly what you want - an rpm for redistribution. 3.Credits Thanks to Jim Bublitz for his open arms and his effords in finding a home for this stuff and the python, KDE and checkinstall crew for their tools. 4.Legal Feel free to copy and modify this document at will, as long as you don't abuse my name. (And please correct my orthography !) From jbublitz at nwinternet.com Thu Aug 22 23:07:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] precompiled rpm-Packages - some links (very soon) In-Reply-To: <200208222129.32065.littlewisp@gmx.net> Message-ID: On 22-Aug-02 Marc Schmitt wrote: > I've written a tiny howto that describes how rpm packages can be > created if you don't know anythink about specfiles (like me). > I've prepared sip-3.3.2, PyQt-3.3.2 and PyKDE-3.3.2 rpms for > SuSE 8.0 running QT-3.0.3 and KDE-3.0.2 (the current SuSE > defaults, if you upgraded to KDE-3.0.2 via YOU). > Feel free to send me any critics, improvements or flames about > the document. I've appended the text-version below, but the > links are 'broken'. (the original is a openoffice document, > also exported as html). You can find checkinstall under > http://asic-linux.com.mx/~izto/checkinstall/ . > Jim, I'd really like to send you the rpms, but my last mail > bounced from something called "InterScan E-Mail VirusWall NT" > when I tried to reply. I'm not sure if I sent it to the right > address, so I'll send a "ping" first with one file to see if it > passes - the three rpm's are ~ 7.5 mb and I wouldn't > like to see them flooding my own mailbox :> Give me about 10 minutes from now (13:48 PDT) to turn the mail scanner off. Your now the second to tell me mail is bouncing, and the first to indicate the cause. Unfortunately, I'm now open for about 30 mostly Korean spams daily (but procmail sends them all to my wife :) ) It's probably better to send one rpm per email given the size. I'm not sure where they'll end up yet, but I'll try to get agreement on a location and post them in the next few days. Jim From rjones at ekit-inc.com Fri Aug 23 00:04:01 2002 From: rjones at ekit-inc.com (Richard Jones) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] drag'n drop in pykless. In-Reply-To: References: Message-ID: <200208230803.08846.rjones@ekit-inc.com> On Fri, 23 Aug 2002 12:52 am, Jim Bublitz wrote: > Thanks for the input! I'm just about to write another message to > the list announcing the next release and apologizing for the > quality of the stuff in examples/ and test/. I hope to have this > stuff cleaned up and a number of additions by the next major KDE > release (3.1), probably later this fall. Is there any chance of this stuff making it into the actual KDE CVS, and hence KDE releases? That would be sweet, and given that there's (minimal) python support already in there, it seems logical to me. That would enable a _lot_ more users to hack up KDE applications who otherwise haven't heard of PyKDE (*shock*, but I'm sure they exist :) Richard From scs at di.org Fri Aug 23 02:52:01 2002 From: scs at di.org (Steve Simmons) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] atoll conversion problem in PyKDE-3.3.2 Message-ID: <20020823004025.GA16727@lokkur.dexter.mi.us> I'm getting compile errors from at attempt to build PyKDE-3.3.2: . . . cd kio && "/usr/bin/make" -f Makefile g++ -c -pipe -w -O -pipe -march=pentiumpro -pthread -D_THREAD_SAFE -fPIC -DSIP_MAKE_MODULE_DLL -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -fno-exceptions -I-I -I../extraH -I. -I/usr/local/include/python2.2 -I/usr/local/include/python2.2 -I/usr/X11R6/include -I/usr/local/include -I-I -I/usr/local/include/kio -I-I -I../kdecore -I/usr/local/include -I/usr/X11R6/include -I/usr/X11R6/mkspecs/default -o kiohuge.o kiohuge.cpp sip/filesize_t.sip: In function `int sipConvertTo_kiofilesize_t(PyObject *, long long int **, int *)': sip/filesize_t.sip:54: implicit declaration of function `int atoll(...)' *** Error code 1 It appears that atoll() is a function present in stdlib in NetBSD but not FreeBSD. Is there a missing switch or spec I need here? -- "Deconstruction is [when] a work is interpreted as a statement about itself, using a literary version of the same cheap trick that Kurt Godel used to try to frighten mathematicians back in the thirties." -- Chip Morningstar in From scs at di.org Fri Aug 23 04:43:01 2002 From: scs at di.org (Steve Simmons) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] atoll conversion problem in PyKDE-3.3.2 Message-ID: <20020823023130.GA19049@lokkur.dexter.mi.us> I wrote: > It appears that atoll() is a function present in stdlib in NetBSD but > not FreeBSD. Is there a missing switch or spec I need here? To make a long story short, atoll() is coming into FreeBSD but isn't there yet. The source shows it to be a one-liner, so adding this to the appropriate kio module did the trick: inline kiofilesize_t atoll( char * s ) { return (kiofilesize_t) strtoll(s, (char **)NULL, 10); } Now, on to the next show-stopper . . . :-) -- "Deconstruction is [when] a work is interpreted as a statement about itself, using a literary version of the same cheap trick that Kurt Godel used to try to frighten mathematicians back in the thirties." -- Chip Morningstar in From scs at di.org Fri Aug 23 05:06:01 2002 From: scs at di.org (Steve Simmons) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Root vs. non-root builds Message-ID: <20020823025434.GA19075@lokkur.dexter.mi.us> I find the PyKDE/PyQt/sip insistance on being *built* as root disturbing. Yes, it's a bit easier to build as root than as a user, but only a bit. Speaking as a 20-year UNIX admin and author of the influential paper 'Life Without Root', I would strongly argue that the only part of the process which should require root is the cp of the final files to their destinations. For the moment, let's assume that we all understand the risks of running large, complex, arbitrary scripts as root, and that we think it's a habit we should not cultivate. Instead, I'm going to address the opposite questions, ie: o How can we modify the build/install mechanisms to avoid root. o Is anybody else interested. The answer to the first is generally that the build process should look locally and deposit locally all the subsidiary items required for the build. As an example, a ${BUILD}/{lib,bin,man,include,...} tree is where things should be placed during build -I ${BUILD} and -L ${BUILD} switches should be added to the makefiles appropriately. The install process then consists primarily of copying ${BUILD} to ${REAL}. Yes, I know I'm handwaving past a few things. The answer to the second is what I'd like to hear from others. If nobody cares, then I'm not gonna worry about it. But if others think the ability to do most of the build sans root is a good idea, let me know. -- "Deconstruction is [when] a work is interpreted as a statement about itself, using a literary version of the same cheap trick that Kurt Godel used to try to frighten mathematicians back in the thirties." -- Chip Morningstar in From jbublitz at nwinternet.com Fri Aug 23 06:04:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] atoll conversion problem in PyKDE-3.3.2 In-Reply-To: <20020823004025.GA16727@lokkur.dexter.mi.us> Message-ID: On 23-Aug-02 Steve Simmons wrote: > I'm getting compile errors from at attempt to build PyKDE-3.3.2: > It appears that atoll() is a function present in stdlib in NetBSD > but not FreeBSD. Is there a missing switch or spec I need here? The line causing the error in filesize_t.sip is: long long val = atoll (s); As you point out, atoll() is defined in stdlib.h in Linux. I don't have access to FreeBSD, so I can't suggest an alternative. If I remember correctly, the problem is that there isn't any guarantee that the long long conversion code in Python is compiled in (it's conditionally compiled), so in filesize_t.sip the PyLong is converted to a string and then to a long long using atoll(). If you can't find a replacement for atoll() (and the proper include file) to edit into filesize_t.sip, you can try replacing the %ConvertToTypeCode block with: %ConvertToTypeCode // Convert a Python long integer to a C++ long long if (sipIsErr == NULL) return PyLong_Check (sipPy); long long val = PyLong_AsLongLong (sipPy); *sipCppPtr = (kiofilesize_t *) &val; return 1; %End There is also a PyLong_AsUnsignedLongLong (), although I doubt it will make a difference. Whether this works, depends on whether your Python was compiled with HAVE_LONG_LONG #defined (see longobject.h in the Python Include subdirectory). It also depends on whether FreeBSD defines a long long type. Of course it also depends on the above code being correct - I believe it is, but haven't tried it. A final (unatractive) alternative if you have neither atoll() or PyLong_AsLongLong would be to replace the above code with: long long val = 0; *sipCppPtr = (kiofilesize_t *) &val; but then 0 will always be passed to C++ when you pass filesize_t. Normally the value returned to Python (which is generated in %ConvertFromTypeCode in the same file) is what you'd be interested in for most cases. A Python 'long' is only limited by available memory. There is no platform-based conditional code (or defines or switches) in PyKDE at the moment. Jim From jbublitz at nwinternet.com Fri Aug 23 08:02:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Root vs. non-root builds In-Reply-To: <20020823025434.GA19075@lokkur.dexter.mi.us> Message-ID: On 23-Aug-02 Steve Simmons wrote: > I find the PyKDE/PyQt/sip insistance on being *built* as root > disturbing. Yes, it's a bit easier to build as root than as a > user, but only a bit. Ahh - a chance to expound on the PyKDE build system! (Sorry guys, but the more I type the less I smoke and I'm trying to quit) There are a number of inter-related factors in the build system: 1. It's easier (in terms of BW, patches, packaging, other stuff) to distribute PyKDE as .sip files instead of .cpp files. 2. With GNU tools (the traditional ./configure make su make install) (1) becomes very kludgy and the GNU tools are incompatible from version to version (not to mention an extra few hundred K of code). 3. The solution to (2) is tmake/qmake plus some Python code to establish the configuration (build.py) 4. To reduce the compile time from an hour to under ten minutes (over 80% reduction) we concatenate all of the cpp files generated by sip into a single huge file (thanks to Debian for the idea). (3) and (4) are potential problems for users, since PyKDE's build system is only tested (by me) on a single platform (SuSE). It's probably not rocket science, but there are a lot of details to the build system, so my current goal is simply to get it working and at the same time try to keep up with the KDE release schedule. So far it seems to work very well - one major bug in some code I stole from Phil's (sip/PyQt) build.py because Qt 3.0.5 change versioning after I had my code 'written'. So why do you need to be root to run make in this system? I actually haven't looked that far yet, being pleased just to have the whole thing working. I suspect it's because the 'all' target (the one 'make' runs) in the module-level Makefiles includes the target that performs the deletion of old libs and copy-to-destination of new libs, and the destination directory is owned by root and only root has write privileges there (as it should be). I only think this because someone asked a question here a day or two ago which led me to look at the Makefiles and form the impression that that is in fact the case. I haven't looked any further, and might still be wrong about that. The Makefiles are structured this way not because I chose to write them in this fashion, but because tmake/qmake generate the Makefiles in this fashion. To fix the problem, I have to edit the Makefiles after tmake/qmake generate them, but the Makefiles don't exist until the end-user runs the build.py script. Maybe this will be an easy fix to build.py (to edit the generated Makefiles automatically) and maybe it won't. The benefit of approaching the build system incrementally is that there is one less piece of code to worry about at the present, so it's more likely to work (which seems to be the case) and users get to upgrade KDE more quickly (important since KDE 3.0.3 includes real security patches) - which is also the case, since the release went out today. While I'm not happy with requiring root privs to run make for PyKDE, I don't think it's the end of the world. I'd like to fix it for the next release or the one after that *after* I feel any other potential problems with the build system have either not occurred or have been resolved. > o How can we modify the build/install mechanisms to avoid > root. You can certainly edit the Makefile after build.py has run to completion, or you can edit build.py and submit a patch. You might also temporarily change the privileges on python/site-packages and wouldn't need to be root ever (I'm guessing) except to change the privileges of course. > o Is anybody else interested. I'm interested and will get to it eventually. In the scheme of things (which includes 3 other major projects at the moment, one of which "pays the bills" for the time I spend on PyKDE), it just doesn't feel that important to me - not important enough to delay the last two releases and not important enough to be a top priority. I really don't like it (the su before make causes me other problems), but I don't think it's that big a problem for most users as long as you remember to type 'exit' after 'make install' completes. OTOH, the tarballs have dropped from 3MB+ to under 600KB (Phil pays for the bandwidth) and from one tarball per version to one tarball for all versions. The compile time, as noted, is 80% less for most users. And, in a previous message, I could suggest edits to you to fix a problem as opposed to having to generate a complete new tarball (which was the situation in the past). I don't mind running make as root for a short time for those kinds of improvements. Damn! I still have 70 minutes to go 'til the next cigarette. Jim From jbublitz at nwinternet.com Fri Aug 23 08:02:21 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] drag'n drop in pykless. In-Reply-To: <200208230803.08846.rjones@ekit-inc.com> Message-ID: On 22-Aug-02 Richard Jones wrote: > On Fri, 23 Aug 2002 12:52 am, Jim Bublitz wrote: >> Thanks for the input! I'm just about to write another message to >> the list announcing the next release and apologizing for the >> quality of the stuff in examples/ and test/. I hope to have this >> stuff cleaned up and a number of additions by the next major KDE >> release (3.1), probably later this fall. > Is there any chance of this stuff making it into the actual KDE > CVS, and hence KDE releases? That would be sweet, and given > that there's (minimal) python support already in there, it > seems logical to me. That would enable a _lot_ more users to > hack up KDE applications who otherwise haven't heard of PyKDE > (*shock*, but I'm sure they exist :) The short answer is that doesn't work very well for me (can't speak for Phil, and he owns sip and PyQt which are also required, and still has rights to big chunks of PyKDE). I can provide the long answer (I'm still trying to quit smoking) if you're interested. I don't necessarily think this is a bad idea - especially being on the KDE ftp sites. CVS is what I have problems with, and it's unlikely that PyKDE will ever keep up with the KDE release schedule while I'm maintaining it. My understanding is you only get KDE ftp if you use KDE CVS. If there's really a lot of interest in this, the way to make it happen is to have someone fork PyKDE development and work out a deal with KDE. I'll be happy to provide assistance. This isn't some "I'll take my ball and go home" - I personally am not comfortable with putting PyKDE on KDE's CVS, but I am comfortable with forking the project. Forking doesn't mean I'll stop developing it (at least not until the fork is as good as what I'm doing, at which point I'd be happy to let someone else do all the work). The license for PyKDE is not very restrictive. Jim From rjones at ekit-inc.com Fri Aug 23 08:12:01 2002 From: rjones at ekit-inc.com (Richard Jones) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] drag'n drop in pykless. In-Reply-To: References: Message-ID: <200208231610.47975.rjones@ekit-inc.com> On Fri, 23 Aug 2002 3:42 pm, Jim Bublitz wrote: > On 22-Aug-02 Richard Jones wrote: > > On Fri, 23 Aug 2002 12:52 am, Jim Bublitz wrote: > >> Thanks for the input! I'm just about to write another message to > >> the list announcing the next release and apologizing for the > >> quality of the stuff in examples/ and test/. I hope to have this > >> stuff cleaned up and a number of additions by the next major KDE > >> release (3.1), probably later this fall. > > > > Is there any chance of this stuff making it into the actual KDE > > CVS, and hence KDE releases? That would be sweet, and given > > that there's (minimal) python support already in there, it > > seems logical to me. That would enable a _lot_ more users to > > hack up KDE applications who otherwise haven't heard of PyKDE > > (*shock*, but I'm sure they exist :) > > The short answer is that doesn't work very well for me (can't speak > for Phil, and he owns sip and PyQt which are also required, and > still has rights to big chunks of PyKDE). I can provide the long > answer (I'm still trying to quit smoking) if you're interested. You realise that your brain is subconsciously relating discussing PyKDE and a lack of nicotene, don't you :) > I don't necessarily think this is a bad idea - especially being on > the KDE ftp sites. CVS is what I have problems with, and it's > unlikely that PyKDE will ever keep up with the KDE release schedule > while I'm maintaining it. My understanding is you only get KDE ftp > if you use KDE CVS. I presume the CVS issue is due to a lack of control? Guidelines may be written (even if they say "oi, it's under my control!" and that's all) and if it all goes awry, they end up with a half-finished fork version :) > If there's really a lot of interest in this, the way to make it > happen is to have someone fork PyKDE development and work out a > deal with KDE. I personally can't stand programming in Java, let alone the horror (to me) that is C++ :) ... if I could just start plugging away at KDE/Qt apps right there using my KDE install. Wow. And I'm going to make a wild, unfounded statement -- I'm sure there's other people out there who are in a similar frame of mind :) > I'll be happy to provide assistance. This isn't some > "I'll take my ball and go home" - I personally am not comfortable > with putting PyKDE on KDE's CVS, but I am comfortable with forking > the project. Perhaps it'd be enough for you to import the latest "stable" version of PyKDE into their CVS? Richard From cavallo at casa.darktech.org Fri Aug 23 09:46:00 2002 From: cavallo at casa.darktech.org (Antonio Cavallo) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Root vs. non-root builds and RPMS In-Reply-To: Message-ID: I've posted few hours/day ago some spec file to build a rpm pyqt and sip distro but i forgotten to explain better them;-) Quick recipe to build an rpm as non-root: export BDIR=$HOME/usr/src/packages mkdir -p $BDIR/{BUILD,RPMS,SOURCES,SPECS,SRPMS} mkdir -p $BDIR/RPMS/{athlon,i386,i486,i586,i686,noarch} # modify (!) and save the file attached as $HOME/.rpmmacros: * change the %_tmppath pointing to an existant (!) directory * %_topdir should point to $BDIR # Then move the spec file i've posted under $BDIR/SPECS, the pyqt and sip (snapshoot) under $BDIR/SOURCES # Go into $BDIR/SPECS and: rpm -ba sip-xxx.spec # As root (you should be root for install it) rpm -i $BDIR/RPMS/i386/sip-xxx.i386.rpm # Repeat the same (as non root) for pyqt. i hope this will help to build better rpms (i hope this will help the mantainer to reduce the overhead): to modify for any other pyqt version is simple as changing the file list (and eventually the source dirs inside the specs) aloha, cav ps. I've put into the sip/pyqt rpm two define on the top: %define python_site %(echo `python -c "import sys; print (sys.prefix + '/lib/python' + sys.version[:3] + '/site-packages/')"`) %define python_include %(echo `python -c "import sys; print (sys.prefix + '/include/python' + sys.version[:3] )"`) These are defined at compile time, matching the python installed on the system (or user installed version). pps. there are more sofisticated tecniques to create a complete user self contained system (custome python different from teh system) based on rpm, but i never had time to fix it well, so let me know if someone is interestd. -------------- next part -------------- %packager Antonio Cavallo %distribution cavallinux %vendor none %_topdir /home/users/cavallo/usr/src/packages %_tmppath /var/tmp/cavallorpm %_rpmtopdir %{_topdir}/%{name} From rcardenes at debian.org Fri Aug 23 10:16:00 2002 From: rcardenes at debian.org (Ricardo Javier Cardenes Medina) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Root vs. non-root builds In-Reply-To: References: <20020823025434.GA19075@lokkur.dexter.mi.us> Message-ID: <20020823081529.GB10549@bifrost.ddts.net> On Thu, Aug 22, 2002 at 10:27:11PM -0700, Jim Bublitz wrote: > On 23-Aug-02 Steve Simmons wrote: > So why do you need to be root to run make in this system? I > actually haven't looked that far yet, being pleased just to have > the whole thing working. I suspect it's because the 'all' target > (the one 'make' runs) in the module-level Makefiles includes the > target that performs the deletion of old libs and > copy-to-destination of new libs, and the destination directory is > owned by root and only root has write privileges there (as it > should be). I only think this because someone asked a question here > a day or two ago which led me to look at the Makefiles and form the > impression that that is in fact the case. I haven't looked any > further, and might still be wrong about that. Well... The only reason for being root at compile time is that right now you're looking for libqtcmodule.so to find out which Qt version (threaded or not) PyQt were compiled against. You expect it to be in the same place where PyKDE is to be installed (modDir), and that is often the site-packages inside your favorite Python version's directory, which uses to be owned by root. Of course, if you set a ~/python/site-packages (for example) and set that path as the install directory at compile time (-d option) for sip, PyQt and PyKDE, there will be no need to be root at compile time. That's a solution for local compilations :-) For packagers (as myself), it use to be a little more tricky, as the destination directory (I can't speak for rpm, because I only know the Debian packaging style) is a fake root directory inside the package's build path, and is likely to be compiled by a non-root user (in my case, Debian policy forbids me the use of root privileges for anything during build/installation time). I'll send you later a tiny patch with the changes I've made for this behaviour. From rcardenes at debian.org Fri Aug 23 11:40:01 2002 From: rcardenes at debian.org (Ricardo Javier Cardenes Medina) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Patch for PyKDE build.py In-Reply-To: References: <20020823025434.GA19075@lokkur.dexter.mi.us> Message-ID: <20020823093942.GA11870@bifrost.ddts.net> Comes attached. -------------- next part -------------- --- build.py 2002-08-21 19:08:38.000000000 +0100 +++ build.py.new 2002-08-23 10:30:12.000000000 +0100 @@ -48,6 +48,7 @@ sipBin = None modDir = None +modQtDir = None pyFullVers = None makefileGen = None makeBin = None @@ -95,7 +96,8 @@ rcode is the return code passed back to the calling process. """ - global progName, platBinDir, platMake, modDir, platQTDIRName, sipIncDir + global progName, platBinDir, platMake, modDir, modQtDir, platQTDIRName + global sipIncDir print "Usage:" print " %s [-h] " % (progName) @@ -106,6 +108,7 @@ print " options:\n" print " -c concatenate each module's C++ source files" print " -d dir where PyKDE will be installed [default %s]" % (modDir) + print " -D dir where PyQt will is installed [default %s]" % (modQtDir) print " -e dir the directory containing the SIP header files [default %s]" % (sipIncDir) print " -g prog the name of the Makefile generator" print " -i dir the directory containing the Qt header files [default %s%sinclude]" % (platQTDIRName,os.sep) @@ -186,7 +189,7 @@ """ global platMake, platCopy, platPyScriptDir, platPyDLLDir, platPySiteDir global platPyIncDir, platPyLib, platQTDIRName, platBinDir, platMkdir - global modDir, pyFullVers, sipIncDir, platKDEDIRName + global modDir, modQtDir, pyFullVers, sipIncDir, platKDEDIRName pyFullVers = string.split(sys.version)[0] @@ -212,6 +215,7 @@ platBinDir = "/usr/local/bin" modDir = platPySiteDir + modQtDir = platPySiteDir sipIncDir = platPyIncDir @@ -598,7 +602,7 @@ def checkThreading (): - qtmodlib = modDir + '/libqtcmodule.so' + qtmodlib = modQtDir + '/libqtcmodule.so' os.system ('ldd ' + qtmodlib + ' > lddtmp') f = open ('lddtmp', 'r') buff = f.read () @@ -1270,7 +1274,7 @@ initGlobals() try: - optlist, args = getopt.getopt(argv[1:],"hcd:e:g:i:k:l:m:p:q:s:t:u:v:z:") + optlist, args = getopt.getopt(argv[1:],"hcd:D:e:g:i:k:l:m:p:q:s:t:u:v:z:") except getopt.GetoptError: usage() @@ -1293,6 +1297,12 @@ elif opt == "-d": global modDir modDir = arg + elif opt == "-D": + global modQtDir + modQtDir = arg + # Asuming modDir = modQtDir if it hasn't been modified + if modDir == platPySiteDir: + modDir = arg elif opt == "-e": global sipIncDir sipIncDir = arg From rcardenes at debian.org Fri Aug 23 14:08:00 2002 From: rcardenes at debian.org (Ricardo Javier Cardenes Medina) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Patch for build.py, take 2 In-Reply-To: <20020823093942.GA11870@bifrost.ddts.net> References: <20020823025434.GA19075@lokkur.dexter.mi.us> <20020823093942.GA11870@bifrost.ddts.net> Message-ID: <20020823120701.GA19592@bifrost.ddts.net> I forgot to modify the build.py to include the libsip*/libqt* directory at linking path... and then realized that the script had yet a way to set that piece of info (option -s) so, please discard the previous patch. This should be enough: --- build.py 2002-08-21 19:08:38.000000000 +0100 +++ build.py.new 2002-08-23 13:00:29.000000000 +0100 @@ -598,7 +598,7 @@ def checkThreading (): - qtmodlib = modDir + '/libqtcmodule.so' + qtmodlib = sipModuleDir + '/libqtcmodule.so' os.system ('ldd ' + qtmodlib + ' > lddtmp') f = open ('lddtmp', 'r') buff = f.read () I'm trying this right now... From littlewisp at gmx.net Fri Aug 23 14:13:00 2002 From: littlewisp at gmx.net (Marc Schmitt) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] precompiled rpm-Packages - some links (very soon) In-Reply-To: References: Message-ID: <200208231408.54649.littlewisp@gmx.net> AAARRRGGGH .... *bounce* *bounce* *bounce* ****** Message from InterScan E-Mail VirusWall NT ****** Sent >>> MAIL FROM: Received <<< 550 5.7.1 ... Access denied Could not deliver mail to this user. ***************** End of message *************** I tried it two times. One time from my account, one time from a colleague's. I didn't get your mail in time because I went home before it arrived. I'll try to upload them to a ftp-able freehoster and post the login + password in here ... From littlewisp at gmx.net Fri Aug 23 14:53:01 2002 From: littlewisp at gmx.net (Marc Schmitt) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Temporary rpm-packages Message-ID: <200208231448.19165.littlewisp@gmx.net> Go and grab it : http://littlewisp.tripod.com/ Anyway, I hope they move soon because uploading via browser is a pita ... -Marc From scs at di.org Fri Aug 23 17:23:01 2002 From: scs at di.org (Steve Simmons) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Root vs. non-root builds In-Reply-To: Message-ID: <20020823151044.GA808@lokkur.dexter.mi.us> Jim Bublitz wrote: >Ahh - a chance to expound on the PyKDE build system! >(Sorry guys, but the more I type the less I smoke and I'm trying to >quit) Hey, go for it. >3. The solution to (2) is tmake/qmake plus some Python code to >establish the configuration (build.py) >4. To reduce the compile time from an hour to under ten minutes >(over 80% reduction) we concatenate all of the cpp files generated >by sip into a single huge file (thanks to Debian for the idea). >(3) and (4) are potential problems for users, since PyKDE's build >system is only tested (by me) on a single platform (SuSE) . . . This is indeed a weakness, but not (IMHO) weak enough that we should change it. We've got existance proofs that it mostly works on freebsd. The tweakage needed to remove 'mostly' probably very small. >So why do you need to be root to run make in this system? . . . >. . . I suspect it's because the 'all' target >(the one 'make' runs) in the module-level Makefiles includes the >target that performs the deletion of old libs and >copy-to-destination of new libs . . . This was my impression -- the early builds I did as non-root failed for just those reasons. >The Makefiles are structured this way not because I chose to write >them in this fashion, but because tmake/qmake generate the >Makefiles in this fashion . . . This may be a show-stopper for the moment. >While I'm not happy with requiring root privs to run make for >PyKDE, I don't think it's the end of the world. I'd like to fix it >for the next release . . . Agreed. I think the right approach from here is to determine why tmake/qmake insist on installing prematurely. From jbublitz at nwinternet.com Fri Aug 23 17:31:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Root vs. non-root builds In-Reply-To: <20020823081529.GB10549@bifrost.ddts.net> Message-ID: On 23-Aug-02 Ricardo Javier Cardenes Medina wrote: > On Thu, Aug 22, 2002 at 10:27:11PM -0700, Jim Bublitz wrote: > Well... The only reason for being root at compile time is that > right now you're looking for libqtcmodule.so to find out which > Qt version (threaded or not) PyQt were compiled against. You > expect it to be in the same place where PyKDE is to be installed > (modDir), and that is often the site-packages inside your > favorite Python version's directory, which uses to be owned by > root. Nope, that behaviour occurs in build.py which doesn't require root privs - all of the relevant directories are world readable. I haven't really looked into this carefully, but on another project I just converted over to qmake/tmake, I noticed that running 'make' as a non-root user only fails after compilation when the Makefile is actually deleting/installing the generated libs. I believe that comes from the target I mentioned (the second referenced in 'all'), so that would probably be the fix. Anyway, it's easy to try (a little harder to fix) so if I get a chance later today I'll try it. > Of course, if you set a ~/python/site-packages (for example) and > set that path as the install directory at compile time (-d > option) for sip, PyQt and PyKDE, there will be no need to be > root at compile time. That's true - I wouldn't want to make a /home directory the default for install. I'm not sure if the present set of switches will allow that or what the Python path implications are. If it's easy I'll add a switch to allow it. > That's a solution for local compilations :-) For packagers (as > myself), it use to be a little more tricky, as the destination > directory (I can't speak for rpm, because I only know the Debian > packaging style) is a fake root directory inside the package's > build path, and is likely to be compiled by a non-root user (in > my case, Debian policy forbids me the use of root privileges for > anything during build/installation time). > I'll send you later a tiny patch with the changes I've made for > this behaviour. I'll watch for that - I'm always interested in improvements. Jim From jbublitz at nwinternet.com Fri Aug 23 17:31:13 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Patch for build.py, take 2 In-Reply-To: <20020823120701.GA19592@bifrost.ddts.net> Message-ID: On 23-Aug-02 Ricardo Javier Cardenes Medina wrote: > I forgot to modify the build.py to include the libsip*/libqt* > directory at linking path... and then realized that the script > had yet a way to set that piece of info (option -s) so, please > discard the previous patch. This should be enough: > --- build.py 2002-08-21 19:08:38.000000000 +0100 > +++ build.py.new 2002-08-23 13:00:29.000000000 +0100 > @@ -598,7 +598,7 @@ > > > def checkThreading (): > - qtmodlib = modDir + '/libqtcmodule.so' > + qtmodlib = sipModuleDir + '/libqtcmodule.so' > os.system ('ldd ' + qtmodlib + ' > lddtmp') > f = open ('lddtmp', 'r') > buff = f.read () > > I'm trying this right now... I haven't looked at -s yet, but thought that would be the place to start. There probably should be a switch for specifying the read directory and another for the write (install) directory for the greatest flexibility. That has some potential confusion attached though - I'll have to think about it a little. Jim From jbublitz at nwinternet.com Fri Aug 23 18:01:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Temporary rpm-packages In-Reply-To: <200208231448.19165.littlewisp@gmx.net> Message-ID: On 23-Aug-02 Marc Schmitt wrote: > Go and grab it : > http://littlewisp.tripod.com/ > Anyway, I hope they move soon because uploading via browser is a > pita ... I get "page not found" for the URL above ? Jim From rcardenes at debian.org Fri Aug 23 18:43:00 2002 From: rcardenes at debian.org (Ricardo Javier Cardenes Medina) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Root vs. non-root builds In-Reply-To: References: <20020823081529.GB10549@bifrost.ddts.net> Message-ID: <20020823164207.GA25825@bifrost.ddts.net> On Fri, Aug 23, 2002 at 08:17:09AM -0700, Jim Bublitz wrote: > On 23-Aug-02 Ricardo Javier Cardenes Medina wrote: > > On Thu, Aug 22, 2002 at 10:27:11PM -0700, Jim Bublitz wrote: > > Well... The only reason for being root at compile time is that > > right now you're looking for libqtcmodule.so to find out which > > Qt version (threaded or not) PyQt were compiled against. You > > expect it to be in the same place where PyKDE is to be installed > > (modDir), and that is often the site-packages inside your > > favorite Python version's directory, which uses to be owned by > > root. > > Nope, that behaviour occurs in build.py which doesn't require root > privs - all of the relevant directories are world readable. I Er... Yes, that's true. I explained it bad. Of course, there's no problem at all _reading_ the files but when, once compiled, you try to install the files on that place (which is owned by root) :-), as you noticed. > > I'll send you later a tiny patch with the changes I've made for > > this behaviour. > > I'll watch for that - I'm always interested in improvements. I've compiled PyKDE applying the second patch I sent to the list this morning. No problems so far. I did: python2.1 build.py -d /the/fake/inst/directory/while/building/package -s /usr/lib/python2.1/site-packages So, now it looks for sip and PyQt modules at /usr/lib/python2.1/site-packages, and installs PyKDE's modules at the other directory. Without that tiny change, build.py would search for libtq* on the PyKDE installation path. From jbublitz at nwinternet.com Fri Aug 23 19:31:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] drag'n drop in pykless. In-Reply-To: <200208231610.47975.rjones@ekit-inc.com> Message-ID: On 23-Aug-02 Richard Jones wrote: > On Fri, 23 Aug 2002 3:42 pm, Jim Bublitz wrote: >> On 22-Aug-02 Richard Jones wrote: >> > On Fri, 23 Aug 2002 12:52 am, Jim Bublitz wrote: >> >> Thanks for the input! I'm just about to write another message >> >> to >> >> the list announcing the next release and apologizing for the >> >> quality of the stuff in examples/ and test/. I hope to have >> >> this >> >> stuff cleaned up and a number of additions by the next major >> >> KDE >> >> release (3.1), probably later this fall. >> > Is there any chance of this stuff making it into the actual >> > KDE CVS, and hence KDE releases? That would be sweet, and >> > given that there's (minimal) python support already in >> > there, it seems logical to me. That would enable a _lot_ >> > more users to hack up KDE applications who otherwise >> > haven't heard of PyKDE (*shock*, but I'm sure they exist :) >> The short answer is that doesn't work very well for me (can't >> speak for Phil, and he owns sip and PyQt which are also >> required, and still has rights to big chunks of PyKDE). I can >> provide the long answer (I'm still trying to quit smoking) if >> you're interested. > You realise that your brain is subconsciously relating discussing > PyKDE and a lack of nicotene, don't you :) That and I cut way back on caffeine/sugar, so I'm really desperate. I'm amazed I can still code (no cheap shots, please). >> I don't necessarily think this is a bad idea - especially being >> on the KDE ftp sites. CVS is what I have problems with, and >> it's unlikely that PyKDE will ever keep up with the KDE release >> schedule while I'm maintaining it. My understanding is you >> only get KDE ftp if you use KDE CVS. > I presume the CVS issue is due to a lack of control? Guidelines > may be written (even if they say "oi, it's under my control!" > and that's all) and if it all goes awry, they end up with a > half-finished fork version :) Yeah, that's part of it. Synchronization with KDE releases is another problem - it'd need to be on more of a KOffice-like schedule decoupled from the KDE releases - which defeats some of what you want to accomplish; maintaining CVS is another problem - I'm not very good at it, it's really slow, and the way PyKDE gets developed doesn't make CVS useful for anything. My uplink is really slow (satellite - d/l's at >100KB/s though) - right now I mail releases, which is even slower but happens transparently via the mail server. There might be concerns about the way PyKDE builds - I don't want to go back to autoconfig, etc. Patch releases are another concern, lack of adequete testing is another. This also needs Phil's input, since sip and PyQt are pre-requisite to PyKDE. I hate it when projects have half the libs you need and you have to go out and search for the other half (KDE has done some of that over the years, but seems better now). riverbankcomputing offers "one-stop" shopping. I haven't discussed it with Phil, but I suspect he has some legitimate concerns/objections as well. The bottom line is that I can't guarantee delivery on schedule, don't want to spend the extra time/work, can't promise a complete package, and don't want to deal with (perhaps imaginary) additional restrictions and politics. If someone else wants to pursue it though, I'm willing to assist with the understanding that I don't plan to change the things I do much from the way I do them now. >> If there's really a lot of interest in this, the way to make it >> happen is to have someone fork PyKDE development and work out a >> deal with KDE. > > I personally can't stand programming in Java, let alone the > horror (to me) that is C++ :) ... if I could just start > plugging away at KDE/Qt apps right there using my KDE install. > Wow. And I'm going to make a wild, unfounded statement -- I'm > sure there's other people out there who are in a similar frame > of mind :) If there aren't already there should be IMHO. I think the other thing that impacts this is having available some better examples, templates for getting started, and similar things, so I intend to work on some of that in the near future. >> I'll be happy to provide assistance. This isn't some >> "I'll take my ball and go home" - I personally am not >> comfortable with putting PyKDE on KDE's CVS, but I am >> comfortable with forking the project. > Perhaps it'd be enough for you to import the latest "stable" > version of PyKDE into their CVS? That's always somewhat of a moving target :) I think that might be workable, but don't know how the KDE people would feel about. Jim From jbublitz at nwinternet.com Fri Aug 23 21:01:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Root vs. non-root builds In-Reply-To: <20020823164207.GA25825@bifrost.ddts.net> Message-ID: On 23-Aug-02 Ricardo Javier Cardenes Medina wrote: > I've compiled PyKDE applying the second patch I sent to the list > this morning. No problems so far. I did: > python2.1 build.py > -d /the/fake/inst/directory/while/building/package > -s /usr/lib/python2.1/site-packages > So, now it looks for sip and PyQt modules at > /usr/lib/python2.1/site-packages, and installs PyKDE's modules at > the other directory. Without that tiny change, build.py would > search for libtq* on the PyKDE installation path. OK - here's what works for PyKDE --- In each of the module level Makefiles, change the following lines: all: Makefile /usr/lib/python2.2/site-packages/$(TARGET) /usr/lib/python2.2/site-packages/$(TARGET): $(UICDECLS)\ $(OBJECTS) $(OBJMOC) $(SUBLIBS) .... install: all To: all: Makefile $(UICDECLS) $(OBJECTS) $(OBJMOC) $(SUBLIBS) /usr/lib/python2.2/site-packages/$(TARGET): .... install: all /usr/lib/python2.2/site-packages/$(TARGET) This changes it to a "standard" make - su - make install instead of su - make - make install and it seems to work fine (although I haven't tested/examined the results real thoroughly yet). I also haven't looked at sip or PyQt yet (Phil would need to change those anyway), but for PyKDE the changes should be easily scriptable in build.py. I also need to examine how this affects rebuild.py, but I think the main difference there will be that it won't link everything twice. The patch is still a few days off - it'll probably be a new release (PyKDE-3.3.2-4) I'll also review Ricardo's patches and see if I can do something that makes sense for Debian. Steve - let me know if you need any other changes for FreeBSD. I didn't think it would be this easy (OTOH, I don't have a working script for this yet either). Jim From rcardenes at debian.org Fri Aug 23 21:35:00 2002 From: rcardenes at debian.org (Ricardo Javier Cardenes Medina) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Root vs. non-root builds In-Reply-To: References: <20020823164207.GA25825@bifrost.ddts.net> Message-ID: <20020823193445.GA29749@bifrost.ddts.net> On Fri, Aug 23, 2002 at 11:37:16AM -0700, Jim Bublitz wrote: > OK - here's what works for PyKDE --- [snip] This has a problem: some modules depends on other at link time. You need to include their location (yet uninstalled) on the linking path. From jbublitz at nwinternet.com Sat Aug 24 00:02:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Root vs. non-root builds In-Reply-To: <20020823193445.GA29749@bifrost.ddts.net> Message-ID: On 23-Aug-02 Ricardo Javier Cardenes Medina wrote: > On Fri, Aug 23, 2002 at 11:37:16AM -0700, Jim Bublitz wrote: >> OK - here's what works for PyKDE --- > [snip] > > This has a problem: some modules depends on other at link time. > You need to include their location (yet uninstalled) on the > linking path. That was my first thought too, but the link order is the same as the compile/link order, so the same dependencies exist in the same order either way. It's either: original: [su] compile a, link a, install a, compile b, link b, install b ... or as modified: compile a, compile b, ... [su] link a, install a, link b, ... The top level Makefile sets the ordering. Unlike the original build system, there isn't any link during the compile phase followed by a relink to install. Link errors are detected later, but most link problems are undefined symbols which don't get detected until runtime anyway (assuming we don't release really poorly done code). Given the lib dependencies, you have to be root to do the link chain anyway - all I've done is move the chain. For most users, installing elsewhere than site-packages/ isn't acceptable IMO, and site-packages/ needs to writable only by root as is the case now. Reduces the compile time too :) (not the total build time though) I'll send you a patch later today if I get that far. Jim From jgardn at alumni.washington.edu Sat Aug 24 07:48:01 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] I am building RPMs... any hints? Message-ID: <200208232248.30243.jgardn@alumni.washington.edu> I am going to build some RPMs for RedHat 7.3 I am shooting for python2 first. This is mostly to scratch an itch. I thought that RedHat would distribute the PyQt stuff for Python 2.2 as well as Python 1.5... but NO, they didn't, and I am stuck! If anyone has any hints, or if anyone has attempted this before, let's compare notes and work together. -- Jonathan Gardner jgardn@alumni.washington.edu From jgardn at alumni.washington.edu Sat Aug 24 17:54:01 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Place to upload RPMs Message-ID: <200208240854.34374.jgardn@alumni.washington.edu> Is there a place to upload the RPMs I have created? I have the sip and PyQt RPMs working, apparently, and the PyKDE one is being built as I write this. -- Jonathan Gardner jgardn@alumni.washington.edu From jbublitz at nwinternet.com Sat Aug 24 18:36:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Place to upload RPMs In-Reply-To: <200208240854.34374.jgardn@alumni.washington.edu> Message-ID: On 24-Aug-02 Jonathan Gardner wrote: > Is there a place to upload the RPMs I have created? > I have the sip and PyQt RPMs working, apparently, and the PyKDE > one is being built as I write this. I haven't heard anything from Phil on where he wants these finally. It just occurred to me however that anyone can upload to sourceforge and the pykde2 site is still active there. 1. ftp to upload.sourceforge.net, cd to 'incoming' and upload - I believe anyone can upload there. If not, this won't work at all. 2. email me (directly or via the list) with the following info: - the exact names of files uploaded - the exact name of any aborted uploads (so I can remove those) - the nature of each file - sip version (should be 3.3.2), Qt version, KDE version, Python version, distribution (RH, SuSE, etc) 3. Once I have the info above, I can pull the files off the sf incoming queue and put them on the site: http://www.sourceforge.net/projects/pykde2 This step requires privileges. Please keep in mind I'm not at the computer as much on weekends as I am during the week, so it may take a while longer to do the transfer to the pykde2 site. Marc Schmitt: I still get 'page not found' on the URL you provided for your RPMs - you might want to upload them to sourceforge as well. Jim From jgardn at alumni.washington.edu Sat Aug 24 19:03:00 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] PyKDE-3.3.2-2 build problems on stock Red Hat 7.3 system. Message-ID: <200208241003.50067.jgardn@alumni.washington.edu> I am trying to compile the PyKDE package from PyKDE-3.3.2-2.tar.gz. I have already downloaded and installed (successfully?) sip-3.3.2, PyQt-3.3.2, and such. It seems everything on that end is working well. I have installed Qt 3.0.3, and $QTDIR points to '/usr/lib/qt3-gcc2.96'. I noticed that Qt 3.0.3 seems to be missing from the 'qttag' in build.py. I have installed KDE 3.0.0, and $KDEDIR is not defined. Red Hat didn't put it into /opt. they spread it around the regular filesystem (parts are in /usr/include/kde, /usr/lib, etc...) I untarred the source, read through README, and README.Linux, and ran the following sequence of commands: # python2 build.py -c -l qt-mt -m /usr/bin/make -k /usr -t /usr/include/kde -v /usr/share/sip/qt -u /usr/lib | tee build.log Attached is the build.log. I don't know which parts are important... # make | tee make.log I am able to identify the important part here... ... cd kdecore && "/usr/bin/make" -f Makefile make[1]: Entering directory `/home/Downloads/PyKDE-3.3.2/kdecore' g++ -c -pipe -w -I/usr/include/freetype2 -O2 -march=i386 -mcpu=i686 -fno-exceptions -D_REENTRANT -fPIC -DSIP_MAKE_MODULE_DLL -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -fno-exceptions -I-I -I../extraH -I. -I/usr/include/python2.2 -I/usr/include/kde -I-I -I/usr/X11R6/include -I/usr/lib/qt3-gcc2.96/include -I/usr/lib/qt3-gcc2.96/mkspecs/default -o kdecorehuge.o kdecorehuge.cpp sipkdecoreKURLList.cpp: In function `PyObject *sipDo_KURL_htmlURL (PyObject *, PyObject *)': sipkdecoreKURLList.cpp:509: no matching function for call to `KURL::htmlURL ()' make[1]: *** [kdecorehuge.o] Error 1 make[1]: Leaving directory `/home/Downloads/PyKDE-3.3.2/kdecore' make: *** [sub-kdecore] Error 2 examining /usr/include/kde/kurl.h, I noticed that the KURL class has no method "htmlURL". -- Jonathan Gardner jgardn@alumni.washington.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: build.log Type: text/x-log Size: 3744 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020824/cd74e417/build.bin From littlewisp at gmx.net Sat Aug 24 19:36:00 2002 From: littlewisp at gmx.net (Marc Schmitt) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Place to upload RPMs In-Reply-To: References: Message-ID: <200208242145.18970.littlewisp@gmx.net> > Marc Schmitt: I still get 'page not found' on the URL you provided > for your RPMs - you might want to upload them to sourceforge as > well. O PyKDE, PyKDE ! wherefore art thou PyKDE? Deny thy homepage and refuse thy code; Or, if thou wilt not, be but sworn my python, And I'll no longer be a programmer. I've been away on a short trip, and in the meantime they deleted the page ... Probably I should have given them my real address, telephone number, fingerprints and sexual preferences .... no, not really :) Ok, I'm now uploading the rpms onto the sourceforge/incomming folder. I hope it works, because my 56k connection isn't the most reliable one ... As soon as there are any .src.rpms somewhere I'll recompile everything available, the stuff without .src.rpms with checkinstall - just to provide 'cleaner' packages. The packages I'm currently uploading are sip-3.3.2-1.SuSE-8.0.i386.rpm PyKDE-3.3.2-1.SuSE-8.0.i386.rpm PyQt-3.3.2-1.SuSE-8.0.i386.rpm for out of the box SuSE 8.0 + YOU update to kde 3.0.2 python 2.2 (python-2.2-105) qt-3.0.3 (qt3-3.0.3-15) kde 3.0.2 (kdebase3-3.0.2-38) I also think we should reenable sourceforge, or at least keep the package list up to date as well as the the project-homepage (might be a referrer to riverbank.) What about renaming the procjet from pykde2 to pykde ? IMHO is sourceforge the starting point for lots of people to look (including me), and if they find a project with an activity of 0% and a last update of half a year ago it probably doesn't make the best first impression. -Marc From jgardn at alumni.washington.edu Sat Aug 24 19:58:01 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Place to upload RPMs In-Reply-To: <200208242145.18970.littlewisp@gmx.net> References: <200208242145.18970.littlewisp@gmx.net> Message-ID: <200208241058.20850.jgardn@alumni.washington.edu> On Saturday 24 August 2002 12:45 pm, Marc Schmitt wrote: > > O PyKDE, PyKDE ! wherefore art thou PyKDE? > Deny thy homepage and refuse thy code; > Or, if thou wilt not, be but sworn my python, > And I'll no longer be a programmer. > Lovely, lovely. I just wrote a bit of that same play in perl a few days ago. I'll spare you all the agony or seeing perl code, and let you know that a Rose by any other name does in fact smell just as sweet. Of course, in python, a rose by any other name may in fact be the same rose... > I also think we should reenable sourceforge, or at least keep the package > list up to date as well as the the project-homepage (might be a referrer to > riverbank.) What about renaming the procjet from pykde2 to pykde ? IMHO is > sourceforge the starting point for lots of people to look (including me), > and if they find a project with an activity of 0% and a last update of half > a year ago it probably doesn't make the best first impression. > Has anyone thought of moving over to FSF's free version of Sourceforge - http://savannah.gnu.org/? At least we won't have to worry about a-certain-company-that-used-to-have-linux-in-its-name doing something nasty... But using Sourceforge (or a savannah) will be really nice because the admins (Like Jim or Phil) could *assign* someone to keep the latest releases on the site whenever they come up with a new version. Also, the cvs and bug tracking facilities, not to mention the email list archiving is useful as well. It'll leave Phil and Jim more hackin' time, and let us who aren't as wizardly do something useful. -- Jonathan Gardner jgardn@alumni.washington.edu From littlewisp at gmx.net Sat Aug 24 20:57:00 2002 From: littlewisp at gmx.net (Marc Schmitt) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Place to upload RPMs In-Reply-To: <200208241058.20850.jgardn@alumni.washington.edu> References: <200208242145.18970.littlewisp@gmx.net> <200208241058.20850.jgardn@alumni.washington.edu> Message-ID: <200208242306.35924.littlewisp@gmx.net> On Samstag, 24. August 2002 19:58, Jonathan Gardner wrote: > Lovely, lovely. I just wrote a bit of that same play in perl a few days Ehm, didn't meant to immitate you :) > ago. I'll spare you all the agony or seeing perl code, and let you know > that a Rose by any other name does in fact smell just as sweet. Of course, > in python, a rose by any other name may in fact be the same rose... Ok, I really tried it. But with all imagination - the only smell my python reminds me of is pringles cheese & onion ... > Has anyone thought of moving over to FSF's free version of Sourceforge - > http://savannah.gnu.org/? At least we won't have to worry about > a-certain-company-that-used-to-have-linux-in-its-name doing something > nasty... Primarily I don't care where a project is hosted, if has a high availability and some sophisticated interfaces to maintain it. Savannah seems to be a sourceforge-fork, so the interfaces are likely to be the same. I don't know anything about sf's availabilty but I haven't had any problems accessing them, from savannah I have no experience at all (but I guess they have a good connection too). But personally I've two points that make me savannah.gnu.org a little "suspect". First the colors. I really, really don't like them. The whole page looks like mud, pale brown boxes "nailed" together. Though sf has more ads, it looks much brighter and more open - and I can read the text better. Another, more imporant point, is "gnu" itself. Yes, I *know* open source leads to better and more trustworthy code, and I do use lot's of tools they maintain, but I consider myself more as "Mercutio" then "Friar Lawrence" - and the gnu guys are some sort of priests. In the end it probably won't matter where it's really going (and i won't complain (i don't even have the right to) if it moves to savannah) but just very personally I had a better feeling to see it at sf. > But using Sourceforge (or a savannah) will be really nice because the > admins (Like Jim or Phil) could *assign* someone to keep the latest > releases on the site whenever they come up with a new version. Also, the > cvs and bug tracking facilities, not to mention the email list archiving is > useful as well. It'll leave Phil and Jim more hackin' time, and let us who > aren't as wizardly do something useful. full ack. Jim, the packages are up now. I had to resubmit pykde, and appended a -1 suffix after the package name - just take the larger one of both. -Marc From jgardn at alumni.washington.edu Sat Aug 24 23:51:01 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] PyKDE-3.3.2-2 build problems on stock Red Hat 7.3 system RESOLVED In-Reply-To: <200208241003.50067.jgardn@alumni.washington.edu> References: <200208241003.50067.jgardn@alumni.washington.edu> Message-ID: <200208241451.27069.jgardn@alumni.washington.edu> On Saturday 24 August 2002 10:03 am, Jonathan Gardner wrote: > cd kdecore && "/usr/bin/make" -f Makefile > make[1]: Entering directory `/home/Downloads/PyKDE-3.3.2/kdecore' > g++ -c -pipe -w -I/usr/include/freetype2 -O2 -march=i386 -mcpu=i686 > -fno-exceptions -D_REENTRANT -fPIC -DSIP_MAKE_MODULE_DLL -DQT_NO_DEBUG > -DQT_THREAD_SUPPORT -fno-exceptions -I-I -I../extraH -I. > -I/usr/include/python2.2 -I/usr/include/kde -I-I -I/usr/X11R6/include > -I/usr/lib/qt3-gcc2.96/include -I/usr/lib/qt3-gcc2.96/mkspecs/default -o > kdecorehuge.o kdecorehuge.cpp > sipkdecoreKURLList.cpp: In function `PyObject *sipDo_KURL_htmlURL > (PyObject *, PyObject *)': > sipkdecoreKURLList.cpp:509: no matching function for call to > `KURL::htmlURL ()' > make[1]: *** [kdecorehuge.o] Error 1 > make[1]: Leaving directory `/home/Downloads/PyKDE-3.3.2/kdecore' > make: *** [sub-kdecore] Error 2 > > examining /usr/include/kde/kurl.h, I noticed that the KURL class has no > method "htmlURL". I also examined /usr/include/kde/kdeversion.h. What I found was a bit disturbing: #define KDE_VERSION 301 #define KDE_VERSION_STRING "3.0.0-10" #define KDE_VERSION_MAJOR 3 #define KDE_VERSION_MINOR 0 #define KDE_VERSION_RELEASE 1 So, someone's bright idea is to make version "3.0.0-10" the same as "3.0.1". Cute. This triggers build.py to believe that I am really running KDE 3.0.1, which I am not (otherwise I would have htmlURL defined, right?) So I tinkered around, and manually removed the htmlURL part from the sip/kurl.sip file. However, recompiling everything, I only ran into more problems... this is not the way to go... So what I did next is I changed /usr/include/kde/kdeversion.h so that it read thus: #define KDE_VERSION 300 #define KDE_VERSION_STRING "3.0.0-10" #define KDE_VERSION_MAJOR 3 #define KDE_VERSION_MINOR 0 #define KDE_VERSION_RELEASE 0 And, gratefully, everything worked. I am appending a file that may be added to the distribution - README.RedHat7.3 I am writing a patch that will allow you to specify the kdeversion manually. I'll submit this after I get the first RPM up. -- Jonathan Gardner jgardn@alumni.washington.edu -------------- next part -------------- When compiling for Red Hat 7.3, the stock system, make sure you modify the file /usr/include/kde/kdeversion.h to read the following: #define KDE_VERSION 300 #define KDE_VERSION_STRING "3.0.0-10" #define KDE_VERSION_MAJOR 3 #define KDE_VERSION_MINOR 0 #define KDE_VERSION_RELEASE 0 I am not sure what else this will break, but PyKDE compiles fine. Jonathan Gardner, August 24, 2002. From jgardn at alumni.washington.edu Sun Aug 25 00:06:00 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] RPM building notes Message-ID: <200208241506.07732.jgardn@alumni.washington.edu> Marc, Let's compare our spec files. Here's what I have got so far. Any suggestions? I am a real newbie at building RPMs, but it is a lot easier than I expected it. I'd like to see what you are doing in the spec files. Could you upload the source RPMs as well? Also, how does SuSE divide up the rpms? Do they try to keep the -devel packages seperate? RedHat tries, but they don't do so well. -- Jonathan Gardner jgardn@alumni.washington.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: sip-3.spec Type: text/x-c++src Size: 1121 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020825/eb940745/sip-3.bin -------------- next part -------------- Summary: Python bindings for Qt Name: PyQt Version: 3.3.2 Release: 1 Source0: %{name}-%{version}.tar.gz License: GPL Group: Development/Languages %description These are the Python bindings for Qt. Also included is 'pyuic', a tool to compile uic files into Python code, and 'eric', an awesome debugging tool. %prep %setup -q %build python2 build.py -b /usr/bin -c -l qt-mt -m /usr/bin/make make %install make install make install-eric install -d /usr/share/sip/qt install -m 0644 sip/* /usr/share/sip/qt %files %defattr(-,root,root) /usr/lib/python2.2/site-packages/qt.py /usr/lib/python2.2/site-packages/qt.pyc /usr/lib/python2.2/site-packages/qtcanvas.py /usr/lib/python2.2/site-packages/qtcanvas.pyc /usr/lib/python2.2/site-packages/qtgl.py /usr/lib/python2.2/site-packages/qtgl.pyc /usr/lib/python2.2/site-packages/qtnetwork.py /usr/lib/python2.2/site-packages/qtnetwork.pyc /usr/lib/python2.2/site-packages/qttable.py /usr/lib/python2.2/site-packages/qttable.pyc /usr/lib/python2.2/site-packages/qtxml.py /usr/lib/python2.2/site-packages/qtxml.pyc /usr/lib/python2.2/site-packages/qtsql.py /usr/lib/python2.2/site-packages/qtsql.pyc /usr/lib/python2.2/site-packages/eric/* /usr/bin/pyuic /usr/bin/eric %doc LICENSE README README.Linux NEWS THANKS doc/PyQt/*.html -------------- next part -------------- Summary: Python bindings for KDE Name: PyKDE Version: 3.3.2 Release: 1 Source0: %{name}-%{version}-2.tar.gz License: GPL Group: Development/Languages %description These are the Python bindings for KDE. %prep %setup -q %build python2 build.py -c -l qt-mt -m /usr/bin/make -k /usr -t /usr/include/kde -v /usr/share/sip/qt -u /usr/lib make %install make install install -d /usr/share/sip/kde install -m 0644 sip/*.sip /usr/share/sip/kde install -d /usr/share/sip/kde/kde30 install -m 0644 sip/kde30/*.sip /usr/share/sip/kde/kde30 %files %defattr(-,root,root) /usr/lib/python2.2/site-packages/libdcopcmodule.so.1.0.0 /usr/lib/python2.2/site-packages/libdcopcmodule.so /usr/lib/python2.2/site-packages/libdcopcmodule.so.1 /usr/lib/python2.2/site-packages/libdcopcmodule.so.1.0 /usr/lib/python2.2/site-packages/dcop.py /usr/lib/python2.2/site-packages/dcop.pyc /usr/lib/python2.2/site-packages/libkdecorecmodule.so.1.0.0 /usr/lib/python2.2/site-packages/libkdecorecmodule.so /usr/lib/python2.2/site-packages/libkdecorecmodule.so.1 /usr/lib/python2.2/site-packages/libkdecorecmodule.so.1.0 /usr/lib/python2.2/site-packages/libkdesucmodule.so.1.0.0 /usr/lib/python2.2/site-packages/libkdesucmodule.so /usr/lib/python2.2/site-packages/libkdesucmodule.so.1 /usr/lib/python2.2/site-packages/libkdesucmodule.so.1.0 /usr/lib/python2.2/site-packages/libkdefxcmodule.so.1.0.0 /usr/lib/python2.2/site-packages/libkdefxcmodule.so /usr/lib/python2.2/site-packages/libkdefxcmodule.so.1 /usr/lib/python2.2/site-packages/libkdefxcmodule.so.1.0 /usr/lib/python2.2/site-packages/libkdeuicmodule.so.1.0.0 /usr/lib/python2.2/site-packages/libkdeuicmodule.so /usr/lib/python2.2/site-packages/libkdeuicmodule.so.1 /usr/lib/python2.2/site-packages/libkdeuicmodule.so.1.0 /usr/lib/python2.2/site-packages/libkiocmodule.so.1.0.0 /usr/lib/python2.2/site-packages/libkiocmodule.so /usr/lib/python2.2/site-packages/libkiocmodule.so.1 /usr/lib/python2.2/site-packages/libkiocmodule.so.1.0 /usr/lib/python2.2/site-packages/libkfilecmodule.so.1.0.0 /usr/lib/python2.2/site-packages/libkfilecmodule.so /usr/lib/python2.2/site-packages/libkfilecmodule.so.1 /usr/lib/python2.2/site-packages/libkfilecmodule.so.1.0 /usr/lib/python2.2/site-packages/libkpartscmodule.so.1.0.0 /usr/lib/python2.2/site-packages/libkpartscmodule.so /usr/lib/python2.2/site-packages/libkpartscmodule.so.1 /usr/lib/python2.2/site-packages/libkpartscmodule.so.1.0 /usr/lib/python2.2/site-packages/libkhtmlcmodule.so.1.0.0 /usr/lib/python2.2/site-packages/libkhtmlcmodule.so /usr/lib/python2.2/site-packages/libkhtmlcmodule.so.1 /usr/lib/python2.2/site-packages/libkhtmlcmodule.so.1.0 /usr/lib/python2.2/site-packages/libkjscmodule.so.1.0.0 /usr/lib/python2.2/site-packages/libkjscmodule.so /usr/lib/python2.2/site-packages/libkjscmodule.so.1 /usr/lib/python2.2/site-packages/libkjscmodule.so.1.0 /usr/lib/python2.2/site-packages/libkspellcmodule.so.1.0.0 /usr/lib/python2.2/site-packages/libkspellcmodule.so /usr/lib/python2.2/site-packages/libkspellcmodule.so.1 /usr/lib/python2.2/site-packages/libkspellcmodule.so.1.0 /usr/lib/python2.2/site-packages/libkdeprintcmodule.so.1.0.0 /usr/lib/python2.2/site-packages/libkdeprintcmodule.so /usr/lib/python2.2/site-packages/libkdeprintcmodule.so.1 /usr/lib/python2.2/site-packages/libkdeprintcmodule.so.1.0 /usr/lib/python2.2/site-packages/kdecore.py /usr/lib/python2.2/site-packages/kdecore.pyc /usr/lib/python2.2/site-packages/kdesu.py /usr/lib/python2.2/site-packages/kdesu.pyc /usr/lib/python2.2/site-packages/kdefx.py /usr/lib/python2.2/site-packages/kdefx.pyc /usr/lib/python2.2/site-packages/kdeui.py /usr/lib/python2.2/site-packages/kdeui.pyc /usr/lib/python2.2/site-packages/kio.py /usr/lib/python2.2/site-packages/kio.pyc /usr/lib/python2.2/site-packages/kfile.py /usr/lib/python2.2/site-packages/kfile.pyc /usr/lib/python2.2/site-packages/kparts.py /usr/lib/python2.2/site-packages/kparts.pyc /usr/lib/python2.2/site-packages/khtml.py /usr/lib/python2.2/site-packages/khtml.pyc /usr/lib/python2.2/site-packages/kjs.py /usr/lib/python2.2/site-packages/kjs.pyc /usr/lib/python2.2/site-packages/kspell.py /usr/lib/python2.2/site-packages/kspell.pyc /usr/lib/python2.2/site-packages/kdeprint.py /usr/lib/python2.2/site-packages/kdeprint.pyc %doc LICENSE README README.RedHat7.3 NEWS THANKS doc/*.html doc/PyKDE/\@15653/*.html From jbublitz at nwinternet.com Sun Aug 25 01:16:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Place to upload RPMs In-Reply-To: <200208242145.18970.littlewisp@gmx.net> Message-ID: On 24-Aug-02 Marc Schmitt wrote: > I've been away on a short trip, and in the meantime they deleted > the page ... Probably I should have given them my real address, > telephone number, fingerprints and sexual preferences .... no, > not really :) I should've realized anyone can upload to sf sooner :( > Ok, I'm now uploading the rpms onto the sourceforge/incomming > folder. I hope it works, because my 56k connection isn't the > most reliable one ... As soon as there are any .src.rpms > somewhere I'll recompile everything available, the > stuff without .src.rpms with checkinstall - just to provide > 'cleaner' packages. > The packages I'm currently uploading are > sip-3.3.2-1.SuSE-8.0.i386.rpm > PyKDE-3.3.2-1.SuSE-8.0.i386.rpm > PyQt-3.3.2-1.SuSE-8.0.i386.rpm > for > out of the box SuSE 8.0 + YOU update to kde 3.0.2 > python 2.2 (python-2.2-105) > qt-3.0.3 (qt3-3.0.3-15) > kde 3.0.2 (kdebase3-3.0.2-38) Perhaps I should point out YOU is not the pronoun, but "Yast Online Update" (although I guess "you" still have to do some of the update). > I also think we should reenable sourceforge, or at least keep the > package list up to date as well as the the project-homepage > (might be a referrer to riverbank.) What about renaming the > procjet from pykde2 to pykde ? IMHO is sourceforge the starting > point for lots of people to look (including me), and if they > find a project with an activity of 0% and a last update of half > a year ago it probably doesn't make the best first impression. While theKompany was still hosting the origninal PyKDE (KDE1) the PyKDE2 name still made sense. It seems to make the numbering easier to read to drop the '2' now. I'm ambivalent about the sf site - it was setup when I had to transfer 10MB or more to Phil for releases, but uploading is a pain for me (my satellite link probably doesn't do as well as your 56K dialup for uploads). I'm not sure if sf will let me rename - acutally it might be better to just start over, as the stuff on PyKDE2 is old and useless but I don't believe there's a way to delete it. There's some politics involved in using sf to refer to the riverbankcomputing site - I need to check that out too. I'll probably do something with it, as I have some other stuff I want to host there eventually, and the larger files (like rpms) really hit the riverbank site for BW charges. I'll post when I have your rpms and Jonathan's RH rpms transferred over. Jim From jbublitz at nwinternet.com Sun Aug 25 01:47:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] PyKDE-3.3.2-2 build problems on stock Red Hat 7.3 sy In-Reply-To: <200208241451.27069.jgardn@alumni.washington.edu> Message-ID: On 24-Aug-02 Jonathan Gardner wrote: > I also examined /usr/include/kde/kdeversion.h. What I found was a > bit disturbing: >#define KDE_VERSION 301 >#define KDE_VERSION_STRING "3.0.0-10" >#define KDE_VERSION_MAJOR 3 >#define KDE_VERSION_MINOR 0 >#define KDE_VERSION_RELEASE 1 > So, someone's bright idea is to make version "3.0.0-10" the same > as "3.0.1". > Cute. > This triggers build.py to believe that I am really running KDE > 3.0.1, which I > am not (otherwise I would have htmlURL defined, right?) > So I tinkered around, and manually removed the htmlURL part from > the sip/kurl.sip file. However, recompiling everything, I only > ran into more problems... this is not the way to go... > So what I did next is I changed /usr/include/kde/kdeversion.h so > that it read thus: >#define KDE_VERSION 300 >#define KDE_VERSION_STRING "3.0.0-10" >#define KDE_VERSION_MAJOR 3 >#define KDE_VERSION_MINOR 0 >#define KDE_VERSION_RELEASE 0 > And, gratefully, everything worked. > I am appending a file that may be added to the distribution - > README.RedHat7.3 > I am writing a patch that will allow you to specify the > kdeversion manually. I'll submit this after I get the first > RPM up. Ack! the info I had was that KDE_VERSION was wrong, but MAJOR/MINOR/RELEASE were correct (or maybe that's the next release). build.py checks MAJOR/MINOR/RELEASE at the moment and assembles the version from that. Thought I had it fixed, so didn't add a note in README. That'll teach me. Jim From jbublitz at nwinternet.com Sun Aug 25 01:47:15 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] Place to upload RPMs In-Reply-To: <200208241058.20850.jgardn@alumni.washington.edu> Message-ID: On 24-Aug-02 Jonathan Gardner wrote: > Has anyone thought of moving over to FSF's free version of > Sourceforge - http://savannah.gnu.org/? At least we won't have > to worry about a > certain-company-that-used-to-have-linux-in-its-name doing > something nasty... > But using Sourceforge (or a savannah) will be really nice because > the admins (Like Jim or Phil) could *assign* someone to keep > the latest releases on the site whenever they come up with a > new version. Also, the cvs and bug tracking facilities, not to > mention the email list archiving is useful as well. It'll > leave Phil and Jim more hackin' time, and let us who aren't as > wizardly do something useful. Your admin password is in the mail :) Seriously, I don't enjoy the web site part of this at all and if you want the job (or several people do) it's yours. If you (or Marc, or anyone else is interested) drop me a msg offlist and we can discuss it. I just went to sf and PyKDE-3.3.2-1-SuSE-8.0-1.rpm was the only file available for posting - nothing else shows in incoming/ (and usually you have visibility of all files). Might be a sf glitch, someone might have 'stolen' our files (it can happen, especially by mistake), or something else might have occurred. I'll check again tonight and tomorrow AM - if the other files don't reappear, you may have to upload again, but wait until I've checked a few more times. From littlewisp at gmx.net Sun Aug 25 09:19:00 2002 From: littlewisp at gmx.net (Marc Schmitt) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] RPM building notes In-Reply-To: <200208241506.07732.jgardn@alumni.washington.edu> References: <200208241506.07732.jgardn@alumni.washington.edu> Message-ID: <200208250916.26476.littlewisp@gmx.net> On Sonntag, 25. August 2002 00:06, Jonathan Gardner wrote: > Let's compare our spec files. Here's what I have got so far. Any > suggestions? I am a real newbie at building RPMs, but it is a lot easier > than I expected it. I'd like to see what you are doing in the spec files. > Could you upload the source RPMs as well? Hehe ... ehm, there are no .src.rpms. I'm a complete specfile-newbie too, so I avoided the whole stuff and used "checkinstall". You can find a quick and dirty manual under my post [PyKDE] precompiled rpm-Packages - some links (very soon) about four days ago on this list. But since you provided some specfiles, I'll look at them and try to merge them with what I can find on my CDs. I'll post the results asap. Jim, again I'm just resubmitting the PyQt and sip packages I build via checkinstall. -Marc From lists at gregfortune.com Sun Aug 25 09:42:00 2002 From: lists at gregfortune.com (Greg Fortune) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] deadlock with QThread Message-ID: <200208250741.g7P7fH149853@steamteam.com> Phil, We've managed to create a very nasty deadlock using the QThread class in an application we are developing. I've attached some sample python code that demonstrates several cases in which QThread does work and one case in which it does not. Our application's code is closest to test case 4, but our code still does not work. Regardless, test case 2 needs addressed and probably fixed :) It is also possible that we just aren't using the QThread stuff correctly and in that case, I'd love to know what we've missed. btw, the deadlock occurs when trying to import any module inside the QThread.run call. Any function level imports in any code called by QThread.run lock up the thread and any imports directly in the QThread.run call lock up the thread. Oddly enough, imp.load_module() allows us to get around the bug, but only for standard python modules (perhaps because they are loaded as an .so??). 3rd party modules fail even in an imp.load_module() even though imp.find_module is successful. Also, removing any function level imports also fixes the problems, but the imports that cause problems are not in our code. They are actually in the MySQLdb module, but any module doing a function level import will cause the lock... I'm still trying to determine what makes our code different from test case 4, which runs. If I figure that out, I'll send another test case that does not work... Until then, let me know what you find out with regards to test case 2. To execute test case 2, just run ./threadtest.py 2 Thanks for any help, Greg Fortune -------------- next part -------------- A non-text attachment was scrubbed... Name: threadtest.tgz Type: application/x-gzip Size: 1942 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020825/a2da52a8/threadtest.tgz From ryan at michel.com.au Sun Aug 25 15:21:01 2002 From: ryan at michel.com.au (Ryan Michel) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] GUI and console question Message-ID: I am new to GUI programming and to Python but am suprised at how quickly I was able to get into the GUI side of things. I am currently studying at university out here in Australia and all I can learn is C++, Java, Prolog and x86 Assembler, so I decided to teach myself Python. I am using pyqt to write my GUI programs and have got them to work fine but when they run a console also pops up in the background and echos some information during the programs execution. For example when some signals and slots are connected and at a few other times. My question is how to get rid of this console as it is driving me batty. The pyqt help files are rather limited and the only tutorial I can find has all its examples to the exact same thing. There is also nothing I can find for a switch to turn this off. ryan --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.360 / Virus Database: 199 - Release Date: 7/05/2002 From coy.krill at verizon.net Sun Aug 25 18:13:00 2002 From: coy.krill at verizon.net (Coy Krill) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] GUI and console question In-Reply-To: References: Message-ID: <200208250911.33142.coy.krill@verizon.net> On Sunday 25 August 2002 06:21 am, Ryan Michel wrote: > My question is how to get rid of this console as it is driving me > batty. The pyqt help files are rather limited and the only tutorial I > can find has all its examples to the exact same thing. There is also > nothing I can find for a switch to turn this off. Change the file extension from .py to .pyw and Python will not start a console window. Coy From doug101 at xecu.net Sun Aug 25 18:40:01 2002 From: doug101 at xecu.net (Doug Bell) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] GUI and console question In-Reply-To: References: Message-ID: <20020825163955.GA1555@dougbell.xecu.net> On Sun, Aug 25, 2002 at 11:21:24PM +1000, Ryan Michel wrote: > I am new to GUI programming and to Python but am suprised at how quickly I > was able to get into the GUI side of things. I am currently studying at > university out here in Australia and all I can learn is C++, Java, Prolog > and x86 Assembler, so I decided to teach myself Python. > > I am using pyqt to write my GUI programs and have got them to work fine but > when they run a console also pops up in the background and echos some > information during the programs execution. For example when some signals > and slots are connected and at a few other times. > > My question is how to get rid of this console as it is driving me batty. > The pyqt help files are rather limited and the only tutorial I can find has > all its examples to the exact same thing. There is also nothing I can find > for a switch to turn this off. Judging by your post, it looks like you're running from Windows. Simply make a shortcut to the python script and use pythonw.exe in place of python.exe for the command line ("pythonw scriptName.py"). Doug. From douard at magic.fr Sun Aug 25 18:42:00 2002 From: douard at magic.fr (David Douard) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] about QPEApplication and QMainWindow In-Reply-To: <3D5E1A3F.6000906@river-bank.demon.co.uk> References: <200208131334.23858.douard@magic.fr> <3D5E1A3F.6000906@river-bank.demon.co.uk> Message-ID: <200208251802.05061.douard@magic.fr> Hi ! Le Samedi 17 Ao?t 2002 11:41, vous avez ?crit : > David Douard wrote: <...snip...> > > > > Last, I use a QMainWindow derived class as main widget. But the problem > > is that the QMainApplication does NOT declare slots which are used by > > QApplication to send messages like "newDocument" or "accept". In the C++ > > world, you just have to subclass QMainApplication declaring thoses > > fuctions... But if I subclass it with a python class, messages are not > > transmited... I haven't looked deeply, but I guess it is not possible > > for a C++ class to send a message (at the c++ level. When I say send, I > > mean calling the slot function as done in QPEApplication code for > > "setDocument", for example) to a purely python defined slot... (Am I > > wrong ?) > > Yes you are wrong. You can connect a C++ signal to any Python callable > object (ie. a function or a method). If your Python slots are not being > called then the problem is probably elsewhere. > > > In this case you (I mean Phil) should provide a QPEMainApplication class > > with an associated python binding which just declare thoses required > > slot functions as virtual, so user can redefine them at Python level. It > > is what I have done for my little app, but it would be nice to have that > > explained and implemented in PyQt... > > This isn't necessary. Ok, so have you any idea why my code does not receive the setDocument messages ? The main widget (the one passed to QPEApp::showMainDocumentWidget), is derived from QMainWindow, with a defined setDocument function (which takes the doc name as arg). For your info, this is an extract of the code in my (GPL) version of qtopia: _________________________________________________________ qpeapplication.cpp: void QPEApplication::pidMessage( const QCString &msg, const QByteArray & data) { ... ... } else if ( msg == "setDocument(QString)" ) { d->keep_running = TRUE; QDataStream stream( data, IO_ReadOnly ); QString doc; stream >> doc; QWidget *mw = mainWidget(); if ( !mw ) mw = d->qpe_main_widget; if ( mw ) Global::setDocument( mw, doc ); } else if ( msg == "nextView()" ) { ... } PS: global::setDocument is also called when starting the app, but it is in a very similar way. _________________________________________________________ global.cpp: void Global::setDocument( QWidget* receiver, const QString& document ) { Emitter emitter(receiver,document); } class Emitter : public QObject { Q_OBJECT public: Emitter( QWidget* receiver, const QString& document ) { connect(this, SIGNAL(setDocument(const QString&)), receiver, SLOT(setDocument(const QString&))); emit setDocument(document); disconnect(this, SIGNAL(setDocument(const QString&)), receiver, SLOT(setDocument(const QString&))); } signals: void setDocument(const QString&); }; __________________________________________________________ Again, when I am using the standard above code, I do not receive any "setDocument" message... I have also written an almost empty QPEMainWindow class (and it's PyQT wrapper) like this : __________________________________________________________ qpemainwindow.h: class QPEMainWindow : public QMainWindow { Q_OBJECT public: QPEMainWindow( QWidget * parent = 0, const char * name = 0, WFlags f = WType_TopLevel ) : QMainWindow(parent, name, f); public slots: virtual void setDocument(const QString &) {}; virtual void accept() {}; }; ____________________________________________________________ When I use this code (my main widget is then a subclass of QPEMainWindow), I DO receive all setDocument messages... This is why I suggested you to provide this class as a part of QtPy... Have you any idea why this code works, while the with the original QMainWindow, it does not work ? Thanks, David From douard at magic.fr Sun Aug 25 18:43:00 2002 From: douard at magic.fr (David Douard) Date: Thu Mar 8 10:26:44 2007 Subject: [PyKDE] QtPE Missing features In-Reply-To: <3D5E1CE8.1020607@river-bank.demon.co.uk> References: <200208131334.21289.douard@magic.fr> <3D5E1CE8.1020607@river-bank.demon.co.uk> Message-ID: <200208251825.31314.douard@magic.fr> Le Samedi 17 Ao?t 2002 11:52, Phil Thompson a ?crit : > David Douard wrote: > > Hi list, > > Hi Phil > > > > I know there are many things to do for such a wrapper, but I am using > > Qtopia classes (TrollTech's 1.5.0 GPL version) in my PyQt application for > > the Zaurus which are not included in PyQt, and quite easy to add, namely: > > > > Config > > AppLnk/DocLnk (and Sets) > > FileManager > > FileSelector > > Resource > > > > All thoses are really easy to add to PyQt (what I did). Should I send you > > (Phil) a patch for these, so they can be included in PyQt ? (But these > > are really trivial changes). > > A patch would be great. Here is my patch... It has not been heavily tested, and I am sure there should be version controls I do not test... It does not include my QPEMainWindow hack (see my other message). It does not implement the QCopEnvelope too, cause it is a little more complicated, and I do not have time for it now (see below). > > > I have not tried other Qtopia classes, but I think they must but also > > easy to add... > > The problem I have encountered is with the DCopEnvelope. The normal use > > of it is to call the constructor with 2 params (channel and message). But > > you then have to call the operator << on the created object to pass > > arguments, and the message is actually sent when the object it deleted > > (almost all the code of the object is in the destructor). > > > > What is the right way to wrap it ? I have tried to write a wrapp Member > > Code so you give the 2 required params and an optional list of strings... > > But I does not work, and I don't have time to guess the way Sip works in > > details... Anoyone did something ? > > You can implement __lshift__() for the class - see how QStringList > implements __len__(), __getitem__() etc. Well I don't think using __lshift__ is a very good idea... The << of C++ used here is the stream operator, not the numeric shift. It might be really confusing. More, as the class code of DCopEnvelope is mainly included in the destructor, IMHO, the best way to do the job is to provide the user a function which takes the required 2 params (channel and message) and an optional thrid param : a list a args. A class instance should not be kept at python level, it makes no sense. So how can I implement such a function ? It is not a wrapper like others class wrappers. Are there examples of similar things in PyQt code ? David -------------- next part -------------- A non-text attachment was scrubbed... Name: sippatch.gz Type: application/x-gzip Size: 5413 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020825/94e13c01/sippatch.gz From ryan at michel.com.au Sun Aug 25 23:40:01 2002 From: ryan at michel.com.au (Ryan Michel) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] GUI and console question In-Reply-To: <20020825163955.GA1555@dougbell.xecu.net> Message-ID: thank you very much and yes I am running under win 2000 and some under Red Hat. ryan -----Original Message----- From: Doug Bell [mailto:doug101@xecu.net] Sent: Monday, 26 August 2002 2:40 AM To: pykde@mats.gmd.de Cc: Ryan Michel Subject: Re: [PyKDE] GUI and console question On Sun, Aug 25, 2002 at 11:21:24PM +1000, Ryan Michel wrote: > I am new to GUI programming and to Python but am suprised at how quickly I > was able to get into the GUI side of things. I am currently studying at > university out here in Australia and all I can learn is C++, Java, Prolog > and x86 Assembler, so I decided to teach myself Python. > > I am using pyqt to write my GUI programs and have got them to work fine but > when they run a console also pops up in the background and echos some > information during the programs execution. For example when some signals > and slots are connected and at a few other times. > > My question is how to get rid of this console as it is driving me batty. > The pyqt help files are rather limited and the only tutorial I can find has > all its examples to the exact same thing. There is also nothing I can find > for a switch to turn this off. Judging by your post, it looks like you're running from Windows. Simply make a shortcut to the python script and use pythonw.exe in place of python.exe for the command line ("pythonw scriptName.py"). Doug. --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.360 / Virus Database: 199 - Release Date: 7/05/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.360 / Virus Database: 199 - Release Date: 7/05/2002 From jgardn at alumni.washington.edu Mon Aug 26 06:56:01 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Place to upload RPMs In-Reply-To: References: Message-ID: <200208252156.59625.jgardn@alumni.washington.edu> On Saturday 24 August 2002 04:39 pm, Jim Bublitz wrote: > On 24-Aug-02 Jonathan Gardner wrote: > > Has anyone thought of moving over to FSF's free version of > > Sourceforge - http://savannah.gnu.org/? At least we won't have > > to worry about a > > certain-company-that-used-to-have-linux-in-its-name doing > > something nasty... > > > > But using Sourceforge (or a savannah) will be really nice because > > the admins (Like Jim or Phil) could *assign* someone to keep > > the latest releases on the site whenever they come up with a > > new version. Also, the cvs and bug tracking facilities, not to > > mention the email list archiving is useful as well. It'll > > leave Phil and Jim more hackin' time, and let us who aren't as > > wizardly do something useful. > > Your admin password is in the mail :) > > Seriously, I don't enjoy the web site part of this at all and if > you want the job (or several people do) it's yours. If you (or > Marc, or anyone else is interested) drop me a msg offlist and we > can discuss it. > I have a bit of experience putting together files for release at sourceforge. I can go ahead and shoulder that. As far as the website, I do have significant experience in that area, but I have no talent for it. If someone else enjoys making nice websites that are easily navigatable... I would hate to steal their chance. > I just went to sf and PyKDE-3.3.2-1-SuSE-8.0-1.rpm was the only > file available for posting - nothing else shows in incoming/ (and > usually you have visibility of all files). Might be a sf glitch, > someone might have 'stolen' our files (it can happen, especially by > mistake), or something else might have occurred. I'll check again > tonight and tomorrow AM - if the other files don't reappear, you > may have to upload again, but wait until I've checked a few more > times. Sourceforge will clean up old files. You have to grab them in a couple of hours or they go away. I have a new set I'll upload tomorrow. -- Jonathan Gardner jgardn@alumni.washington.edu From phil at river-bank.demon.co.uk Mon Aug 26 19:58:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] drag'n drop in pykless. References: Message-ID: <3D6A6BFE.6060609@river-bank.demon.co.uk> Jim Bublitz wrote: > On 23-Aug-02 Richard Jones wrote: > >>On Fri, 23 Aug 2002 3:42 pm, Jim Bublitz wrote: >> >>>On 22-Aug-02 Richard Jones wrote: >>> >>>>On Fri, 23 Aug 2002 12:52 am, Jim Bublitz wrote: >>>> >>>>>Thanks for the input! I'm just about to write another message >>>>>to >>>>>the list announcing the next release and apologizing for the >>>>>quality of the stuff in examples/ and test/. I hope to have >>>>>this >>>>>stuff cleaned up and a number of additions by the next major >>>>>KDE >>>>>release (3.1), probably later this fall. >>>>> > >>>>Is there any chance of this stuff making it into the actual >>>>KDE CVS, and hence KDE releases? That would be sweet, and >>>>given that there's (minimal) python support already in >>>>there, it seems logical to me. That would enable a _lot_ >>>>more users to hack up KDE applications who otherwise >>>>haven't heard of PyKDE (*shock*, but I'm sure they exist :) >>>> > >>>The short answer is that doesn't work very well for me (can't >>>speak for Phil, and he owns sip and PyQt which are also >>>required, and still has rights to big chunks of PyKDE). I can >>>provide the long answer (I'm still trying to quit smoking) if >>>you're interested. >>> > > >>You realise that your brain is subconsciously relating discussing >>PyKDE and a lack of nicotene, don't you :) >> > > That and I cut way back on caffeine/sugar, so I'm really desperate. > I'm amazed I can still code (no cheap shots, please). > > >>>I don't necessarily think this is a bad idea - especially being >>>on the KDE ftp sites. CVS is what I have problems with, and >>>it's unlikely that PyKDE will ever keep up with the KDE release >>>schedule while I'm maintaining it. My understanding is you >>>only get KDE ftp if you use KDE CVS. >>> > > >>I presume the CVS issue is due to a lack of control? Guidelines >>may be written (even if they say "oi, it's under my control!" >>and that's all) and if it all goes awry, they end up with a >>half-finished fork version :) >> > > Yeah, that's part of it. Synchronization with KDE releases is > another problem - it'd need to be on more of a KOffice-like > schedule decoupled from the KDE releases - which defeats some of > what you want to accomplish; maintaining CVS is another problem - > I'm not very good at it, it's really slow, and the way PyKDE gets > developed doesn't make CVS useful for anything. My uplink is really > slow (satellite - d/l's at >100KB/s though) - right now I mail > releases, which is even slower but happens transparently via the > mail server. There might be concerns about the way PyKDE builds - I > don't want to go back to autoconfig, etc. Patch releases are another > concern, lack of adequete testing is another. > > This also needs Phil's input, since sip and PyQt are pre-requisite > to PyKDE. I hate it when projects have half the libs you need and > you have to go out and search for the other half (KDE has done some > of that over the years, but seems better now). riverbankcomputing > offers "one-stop" shopping. I haven't discussed it with Phil, but I > suspect he has some legitimate concerns/objections as well. SIP and PyQt have nothing to do with KDE so I have no interest in seeing it in the KDE CVS. In theory I have no objection to somebody else doing it. In practice it is likely that anybody who did do it would get bored of doing it after a couple of releases and the KDE CVS version would just get more and more out of date. In my opinion the distributors should be dealing with this problem - complain to your supplier if they don't include a version of PyKDE compatible with their copy of KDE. Phil From rjones at ekit-inc.com Mon Aug 26 23:46:01 2002 From: rjones at ekit-inc.com (Richard Jones) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] drag'n drop in pykless. In-Reply-To: <3D6A6BFE.6060609@river-bank.demon.co.uk> References: <3D6A6BFE.6060609@river-bank.demon.co.uk> Message-ID: <200208270745.27617.rjones@ekit-inc.com> On Tue, 27 Aug 2002 3:57 am, Phil Thompson wrote: > In my opinion the distributors should be dealing with this problem - > complain to your supplier if they don't include a version of PyKDE > compatible with their copy of KDE. Yep. Unfotunately Red Hat is Red Hat, and they have an aversion to supporting KDE and Qt in anything other than a most basic form :( Given your and Jim's (quite reasonable) stance, I'll live with loading up Red Hat with reasonable Qt, KDE, sip, PyQT and PyKDE versions manually. Hey, it's all free software :) Richard From phil at river-bank.demon.co.uk Tue Aug 27 00:06:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] drag'n drop in pykless. References: <3D6A6BFE.6060609@river-bank.demon.co.uk> <200208270745.27617.rjones@ekit-inc.com> Message-ID: <3D6AA631.9020806@river-bank.demon.co.uk> Richard Jones wrote: > On Tue, 27 Aug 2002 3:57 am, Phil Thompson wrote: > >>In my opinion the distributors should be dealing with this problem - >>complain to your supplier if they don't include a version of PyKDE >>compatible with their copy of KDE. >> > > Yep. Unfotunately Red Hat is Red Hat, and they have an aversion to supporting > KDE and Qt in anything other than a most basic form :( > > Given your and Jim's (quite reasonable) stance, I'll live with loading up Red > Hat with reasonable Qt, KDE, sip, PyQT and PyKDE versions manually. Hey, it's > all free software :) But don't forget to complain to Red Hat. Phil From rjones at ekit-inc.com Tue Aug 27 01:29:00 2002 From: rjones at ekit-inc.com (Richard Jones) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] drag'n drop in pykless. In-Reply-To: <3D6AA631.9020806@river-bank.demon.co.uk> References: <200208270745.27617.rjones@ekit-inc.com> <3D6AA631.9020806@river-bank.demon.co.uk> Message-ID: <200208270927.18115.rjones@ekit-inc.com> On Tue, 27 Aug 2002 8:05 am, Phil Thompson wrote: > Richard Jones wrote: > > On Tue, 27 Aug 2002 3:57 am, Phil Thompson wrote: > >>In my opinion the distributors should be dealing with this problem - > >>complain to your supplier if they don't include a version of PyKDE > >>compatible with their copy of KDE. > > > > Yep. Unfotunately Red Hat is Red Hat, and they have an aversion to > > supporting KDE and Qt in anything other than a most basic form :( > > > > Given your and Jim's (quite reasonable) stance, I'll live with loading up > > Red Hat with reasonable Qt, KDE, sip, PyQT and PyKDE versions manually. > > Hey, it's all free software :) > > But don't forget to complain to Red Hat. Oh, and don't forget to use Mandrake at home, where you control the installation :) Richard From alex at moreati.org.uk Tue Aug 27 02:46:01 2002 From: alex at moreati.org.uk (Alex Willmer) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] PyKDE-3.3.2-2 build problems on stock Red Hat 7.3 system RESOLVED References: <200208241003.50067.jgardn@alumni.washington.edu> <200208241451.27069.jgardn@alumni.washington.edu> Message-ID: <3D6AAB3A.3050604@moreati.org.uk> Jonathan Gardner wrote: > On Saturday 24 August 2002 10:03 am, Jonathan Gardner wrote: > >>cd kdecore && "/usr/bin/make" -f Makefile >>make[1]: Entering directory `/home/Downloads/PyKDE-3.3.2/kdecore' >>g++ -c -pipe -w -I/usr/include/freetype2 -O2 -march=i386 -mcpu=i686 >>-fno-exceptions -D_REENTRANT -fPIC -DSIP_MAKE_MODULE_DLL -DQT_NO_DEBUG >>-DQT_THREAD_SUPPORT -fno-exceptions -I-I -I../extraH -I. >>-I/usr/include/python2.2 -I/usr/include/kde -I-I -I/usr/X11R6/include >>-I/usr/lib/qt3-gcc2.96/include -I/usr/lib/qt3-gcc2.96/mkspecs/default -o >>kdecorehuge.o kdecorehuge.cpp >>sipkdecoreKURLList.cpp: In function `PyObject *sipDo_KURL_htmlURL >>(PyObject *, PyObject *)': >>sipkdecoreKURLList.cpp:509: no matching function for call to >>`KURL::htmlURL ()' >>make[1]: *** [kdecorehuge.o] Error 1 >>make[1]: Leaving directory `/home/Downloads/PyKDE-3.3.2/kdecore' >>make: *** [sub-kdecore] Error 2 >> >>examining /usr/include/kde/kurl.h, I noticed that the KURL class has no >>method "htmlURL". > > > I also examined /usr/include/kde/kdeversion.h. What I found was a bit > disturbing: > > #define KDE_VERSION 301 > #define KDE_VERSION_STRING "3.0.0-10" > #define KDE_VERSION_MAJOR 3 > #define KDE_VERSION_MINOR 0 > #define KDE_VERSION_RELEASE 1 > > So, someone's bright idea is to make version "3.0.0-10" the same as "3.0.1". > Cute. > > This triggers build.py to believe that I am really running KDE 3.0.1, which I > am not (otherwise I would have htmlURL defined, right?) > > So I tinkered around, and manually removed the htmlURL part from the > sip/kurl.sip file. However, recompiling everything, I only ran into more > problems... this is not the way to go... > > So what I did next is I changed /usr/include/kde/kdeversion.h so that it read > thus: > > #define KDE_VERSION 300 > #define KDE_VERSION_STRING "3.0.0-10" > #define KDE_VERSION_MAJOR 3 > #define KDE_VERSION_MINOR 0 > #define KDE_VERSION_RELEASE 0 > > And, gratefully, everything worked. > Sorry for leaving so long before I replied to this thread, I'va also been working on this, but on Mandrake 8.2. My system is definately KDE 3.0.1, and I received the same error. As far as I can tell KDE 3.0.1 doesn't include KURL::htmlURL(), this wasn't introduced until 3.0.2. However in the PyKDE sip files (kurl.sip, kfileiconview.sip, kfiledetailview.sip) this and the two constructors below are included for version 3.0.1. KFileIconViewItem::KFileIconViewItem(QIconView *parent, KFileItem *fi) KFileListViewItem::KFileListViewItem(QListView *parent, KFileItem *fi) (I think these might have been the cause of the further problems you reported Jonathon). Changing the %if KDE_3_0_1 lines to %if KDE_3_0_2 allows me to compile without error. I may be completely wrong, I'm still having a few problems which might have been caused by my guess work, but these pages seem to confirm my theory (apologies for the long urls). http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kdecore/kurl.h.diff?r1=1.92%3AKDE_3_0_1_RELEASE&tr1=1.1&r2=1.92.2.1%3AKDE_3_0_2_RELEASE&tr2=1.96&diff_format=h http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kio/kfile/kfileiconview.h.diff?r1=1.28.2.2%3AKDE_3_0_1_RELEASE&tr1=1.1&r2=1.28.2.3%3AKDE_3_0_2_RELEASE&tr2=1.33&diff_format=h http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kio/kfile/kfiledetailview.h.diff?r1=1.25.2.1%3AKDE_3_0_1_RELEASE&tr1=1.1&r2=1.25.2.2%3AKDE_3_0_2_RELEASE&tr2=1.25.2.2&diff_format=h I can provide patches if needed, but the changes are trivial & I'm not in Linux at the moment. Hope this helps. Regards Alex From jgardn at alumni.washington.edu Tue Aug 27 02:55:01 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] drag'n drop in pykless. In-Reply-To: <200208270745.27617.rjones@ekit-inc.com> References: <3D6A6BFE.6060609@river-bank.demon.co.uk> <200208270745.27617.rjones@ekit-inc.com> Message-ID: <200208261755.28432.jgardn@alumni.washington.edu> On Monday 26 August 2002 02:45 pm, Richard Jones wrote: > On Tue, 27 Aug 2002 3:57 am, Phil Thompson wrote: > > In my opinion the distributors should be dealing with this problem - > > complain to your supplier if they don't include a version of PyKDE > > compatible with their copy of KDE. > > Yep. Unfotunately Red Hat is Red Hat, and they have an aversion to > supporting KDE and Qt in anything other than a most basic form :( > > Given your and Jim's (quite reasonable) stance, I'll live with loading up > Red Hat with reasonable Qt, KDE, sip, PyQT and PyKDE versions manually. > Hey, it's all free software :) > My take on Red Hat is exactly the same. It's a great foundation, but they really do favor Gnome. And python 1.5. If you can get KDE compiled on your system, share the wealth and upload a few good RPMs. I wish I could figure out how to get a decent compilation... -- Jonathan Gardner jgardn@alumni.washington.edu From jgardn at alumni.washington.edu Tue Aug 27 03:01:00 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] PyKDE-3.3.2-2 build problems on stock Red Hat 7.3 system RESOLVED In-Reply-To: <3D6AAB3A.3050604@moreati.org.uk> References: <200208241003.50067.jgardn@alumni.washington.edu> <200208241451.27069.jgardn@alumni.washington.edu> <3D6AAB3A.3050604@moreati.org.uk> Message-ID: <200208261801.38791.jgardn@alumni.washington.edu> On Monday 26 August 2002 03:27 pm, Alex Willmer wrote: > Sorry for leaving so long before I replied to this thread, I'va also > been working on this, but on Mandrake 8.2. My system is definately KDE > 3.0.1, and I received the same error. > Could you make a few Mandrake RPMs? I posted earlier the spec for the Red Hat one. I figure we got a Red Hat guy, a SuSE guy, and if we get Mandrake working, all we'll be missing is Debian... > As far as I can tell KDE 3.0.1 doesn't include KURL::htmlURL(), this > wasn't introduced until 3.0.2. However in the PyKDE sip files (kurl.sip, > kfileiconview.sip, kfiledetailview.sip) this and the two constructors > below are included for version 3.0.1. > > KFileIconViewItem::KFileIconViewItem(QIconView *parent, KFileItem *fi) > KFileListViewItem::KFileListViewItem(QListView *parent, KFileItem *fi) > > (I think these might have been the cause of the further problems you > reported Jonathon). > > Changing the %if KDE_3_0_1 lines to %if KDE_3_0_2 allows me to compile > without error. > It wasn't just the other two errors you mention above, it was actually quite a few (closer to 20 or 40). The list was too long to present. I had the "-c" option on, so all the errors came out. However, I'll try this out, see what happens. -- Jonathan Gardner jgardn@alumni.washington.edu From rjones at ekit-inc.com Tue Aug 27 03:08:01 2002 From: rjones at ekit-inc.com (Richard Jones) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] drag'n drop in pykless. In-Reply-To: <200208261755.28432.jgardn@alumni.washington.edu> References: <200208270745.27617.rjones@ekit-inc.com> <200208261755.28432.jgardn@alumni.washington.edu> Message-ID: <200208271107.26741.rjones@ekit-inc.com> On Tue, 27 Aug 2002 10:55 am, Jonathan Gardner wrote: > On Monday 26 August 2002 02:45 pm, Richard Jones wrote: > > On Tue, 27 Aug 2002 3:57 am, Phil Thompson wrote: > > > In my opinion the distributors should be dealing with this problem - > > > complain to your supplier if they don't include a version of PyKDE > > > compatible with their copy of KDE. > > > > Yep. Unfotunately Red Hat is Red Hat, and they have an aversion to > > supporting KDE and Qt in anything other than a most basic form :( > > > > Given your and Jim's (quite reasonable) stance, I'll live with loading up > > Red Hat with reasonable Qt, KDE, sip, PyQT and PyKDE versions manually. > > Hey, it's all free software :) > > My take on Red Hat is exactly the same. It's a great foundation, but they > really do favor Gnome. And python 1.5. > > If you can get KDE compiled on your system, share the wealth and upload a > few good RPMs. I wish I could figure out how to get a decent compilation... My build environment is non-intrusive to RedHat. That is, I build in my system's /export directory: /export/qt-stable (QTDIR and source) /export/kde-stable (KDEDIR) /export/kde-3.0.2 (source) according to the instructions on: http://developer.kde.org/build/build2ver.html with "/usr/local" replaced by "/export" in my case, but everything else is the same. Note that I also edited /etc/X11/xinit/Xclients to have this at the top: # check to see if the user has a preferred desktop PREFERRED= if [ -f /etc/sysconfig/desktop ]; then if [ -n "`grep -i GNOME /etc/sysconfig/desktop`" ]; then PREFERRED=gnome-session elif [ -n "`grep -i KDE /etc/sysconfig/desktop`" ]; then QTDIR=/export/qt-stable KDEDIR=/export/kde-stable PATH=$QTDIR/bin:$KDEDIR/bin:${PATH} LD_LIBRARY_PATH=$QTDIR/lib:$KDEDIR/lib:${LD_LIBRARY_PATH} export QTDIR KDEDIR PATH LD_LIBRARY_PATH PREFERRED=/export/kde-stable/bin/startkde fi fi so my "startx" command worked properly (since modifying ~/.xinitrc didn't seem to do anything on my machine). Bundling this all up as RPMs is beyond me in both time and knowledge at present, sorry. Richard From jgardn at alumni.washington.edu Tue Aug 27 03:36:01 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] drag'n drop in pykless. In-Reply-To: <200208271107.26741.rjones@ekit-inc.com> References: <200208261755.28432.jgardn@alumni.washington.edu> <200208271107.26741.rjones@ekit-inc.com> Message-ID: <200208261836.25019.jgardn@alumni.washington.edu> On Monday 26 August 2002 06:07 pm, Richard Jones wrote: > My build environment is non-intrusive to RedHat. That is, I build in my > system's /export directory: > > /export/qt-stable (QTDIR and source) > /export/kde-stable (KDEDIR) > /export/kde-3.0.2 (source) > > according to the instructions on: > > http://developer.kde.org/build/build2ver.html > > with "/usr/local" replaced by "/export" in my case, but everything else is > the same. Note that I also edited /etc/X11/xinit/Xclients to have this at > the top: > > # check to see if the user has a preferred desktop > PREFERRED= > if [ -f /etc/sysconfig/desktop ]; then > if [ -n "`grep -i GNOME /etc/sysconfig/desktop`" ]; then > PREFERRED=gnome-session > elif [ -n "`grep -i KDE /etc/sysconfig/desktop`" ]; then > QTDIR=/export/qt-stable > KDEDIR=/export/kde-stable > PATH=$QTDIR/bin:$KDEDIR/bin:${PATH} > LD_LIBRARY_PATH=$QTDIR/lib:$KDEDIR/lib:${LD_LIBRARY_PATH} > export QTDIR KDEDIR PATH LD_LIBRARY_PATH > PREFERRED=/export/kde-stable/bin/startkde > fi > fi > > so my "startx" command worked properly (since modifying ~/.xinitrc didn't > seem to do anything on my machine). Bundling this all up as RPMs is beyond > me in both time and knowledge at present, sorry. I'll play with this. I had a problem of maintaing my old KDE stuff at the same time I was building an unstable version. I think the Xclients trick might do it, though. -- Jonathan Gardner jgardn@alumni.washington.edu From jgardn at alumni.washington.edu Tue Aug 27 05:06:00 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Mad rave about Eric! Message-ID: <200208262006.16762.jgardn@alumni.washington.edu> I just got eric to run properly on Red Hat 7.3. I am debugging my program right now, without the slightest hint of a problem. It is much better than I thought it could be. Kudos to those who have worked on it! Keep it up! -- Jonathan Gardner jgardn@alumni.washington.edu From jbublitz at nwinternet.com Tue Aug 27 08:02:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] PyKDE-3.3.2-2 build problems on stock Red Hat 7.3 sy In-Reply-To: <3D6AAB3A.3050604@moreati.org.uk> Message-ID: On 26-Aug-02 Alex Willmer wrote: > Sorry for leaving so long before I replied to this thread, I'va > also been working on this, but on Mandrake 8.2. My system is > definately KDE 3.0.1, and I received the same error. My guess would be that Mandrake 8.2 is based on RH 7.3 and would therefore have the same version problem - RH changed the version numbers (3.0.0 -> 3.0.1) on KDE 3.0.0. I've had that confirmed by RH and it was posted to the list a while ago. the problem was noted before KDE 3.0.1 was released. > As far as I can tell KDE 3.0.1 doesn't include KURL::htmlURL(), My copy of the kdelibs source for 3.0.1 does, I just checked again. > this wasn't introduced until 3.0.2. However in the PyKDE sip > files (kurl.sip, kfileiconview.sip, kfiledetailview.sip) this > and the two constructors below are included for version 3.0.1. > KFileIconViewItem::KFileIconViewItem(QIconView *parent, KFileItem > *fi) > KFileListViewItem::KFileListViewItem(QListView *parent, KFileItem > *fi) > (I think these might have been the cause of the further problems > you reported Jonathon). > Changing the %if KDE_3_0_1 lines to %if KDE_3_0_2 allows me to > compile without error. That'll probably work too - you're effectively moving the sip files back to 3.0.0 by versioning out the 3.0.1 changes. It's easier to correct kdeversion.h in the KDE includes, which is where the error is. It should be KDE_VERSION = 300 and KDE_RELEASE = 0. > I may be completely wrong, I'm still having a few problems which > might have been caused by my guess work, but these pages seem to > confirm my theory (apologies for the long urls). > http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kdecore/kurl.h.di > ff?r1=1.92%3AKDE_3_0_1_RELEASE&tr1=1.1&r2=1.92.2.1%3AKDE_3_0_2_REL > EASE&tr2=1.96&diff_format=h > > http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kio/kfile/kfileic > onview.h.diff?r1=1.28.2.2%3AKDE_3_0_1_RELEASE&tr1=1.1&r2=1.28.2.3% > 3AKDE_3_0_2_RELEASE&tr2=1.33&diff_format=h > > http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kio/kfile/kfilede > tailview.h.diff?r1=1.25.2.1%3AKDE_3_0_1_RELEASE&tr1=1.1&r2=1.25.2. > 2%3AKDE_3_0_2_RELEASE&tr2=1.25.2.2&diff_format=h > I can provide patches if needed, but the changes are trivial & > I'm not in Linux at the moment. Hope this helps. Jim From jbublitz at nwinternet.com Tue Aug 27 08:02:23 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] PyKDE-3.3.2-2 build problems on stock Red Hat 7.3 sy In-Reply-To: <200208261801.38791.jgardn@alumni.washington.edu> Message-ID: On 27-Aug-02 Jonathan Gardner wrote: > On Monday 26 August 2002 03:27 pm, Alex Willmer wrote: > Could you make a few Mandrake RPMs? I posted earlier the spec for > the Red Hat one. I figure we got a Red Hat guy, a SuSE guy, and > if we get Mandrake working, all we'll be missing is Debian... Debian is already handled by Ricardo, and there probably wouldn't be much benefit in hosting it, since Deb users would prefer to use Debian's distribution system. Same for FreeBSD (Steve Simmons has been working on putting sip/PyQt/PyKDE on 'ports'). Someone might try the RH rpms and see if they work on Mandrake - I'm not sure how much Mandrake moves things around, but they're fundamentally RH based. Jim From Roy.Dragseth at cc.uit.no Tue Aug 27 08:22:01 2002 From: Roy.Dragseth at cc.uit.no (Roy Dragseth) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] drag'n drop in pykless. In-Reply-To: <200208261755.28432.jgardn@alumni.washington.edu> References: <200208270745.27617.rjones@ekit-inc.com> <200208261755.28432.jgardn@alumni.washington.edu> Message-ID: <200208270821.36321.royd@cc.uit.no> On Tuesday 27 August 2002 02:55, Jonathan Gardner wrote: > My take on Red Hat is exactly the same. It's a great foundation, but they > really do favor Gnome. And python 1.5. Yes, but they do have python2 as a separate package. I think they are afraid of breaking their install/admin tools if they let python2 become the default. > > If you can get KDE compiled on your system, share the wealth and upload a > few good RPMs. I wish I could figure out how to get a decent compilation... You can find decent KDE 3.0.3 rpms here: http://www.math.unl.edu/~rdieter/ They are even apt enabled, see the description on that page. We should do an apt repository for pykde too, and all we had to do to upgrade would be apt-get update; apt-get install pykde (dreaming...) r. (the subject line of this thread isn't very descriptive of the, er.., subject anymore) -- The Computer Center, University of Troms?, N-9037 TROMS?, Norway. phone:+47 77 64 41 07, fax:+47 77 64 41 00 Roy Dragseth, High Performance Computing System Administrator Direct call: +47 77 64 62 56. email: royd@cc.uit.no From phil at river-bank.demon.co.uk Tue Aug 27 12:08:00 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Root vs. non-root builds References: <20020823025434.GA19075@lokkur.dexter.mi.us> Message-ID: <3D6B4F6C.5070206@river-bank.demon.co.uk> Steve Simmons wrote: > I find the PyKDE/PyQt/sip insistance on being *built* as root disturbing. > Yes, it's a bit easier to build as root than as a user, but only a bit. > Speaking as a 20-year UNIX admin and author of the influential paper 'Life > Without Root', I would strongly argue that the only part of the process > which should require root is the cp of the final files to their > destinations. > > For the moment, let's assume that we all understand the risks of running > large, complex, arbitrary scripts as root, and that we think it's a habit > we should not cultivate. Instead, I'm going to address the opposite > questions, ie: > > o How can we modify the build/install mechanisms to avoid root. > o Is anybody else interested. > > The answer to the first is generally that the build process should > look locally and deposit locally all the subsidiary items required > for the build. As an example, a ${BUILD}/{lib,bin,man,include,...} > tree is where things should be placed during build -I ${BUILD} and > -L ${BUILD} switches should be added to the makefiles appropriately. > The install process then consists primarily of copying ${BUILD} to > ${REAL}. Yes, I know I'm handwaving past a few things. > > The answer to the second is what I'd like to hear from others. If > nobody cares, then I'm not gonna worry about it. But if others think > the ability to do most of the build sans root is a good idea, let me > know. Apologies for my late response on this - I've been lying on a Greek beach. I agree that the root build is bad - but it's how the tmake/qmake generated Makefiles work when building libraries. I assume that this is done for a reason and that it is related to how shared libraries work on certain UNIX variants. If you look under the covers of how libtool works it performs some horrible contortions to allow portable non-root builds of libraries. I don't blame Trolltech for not bothering to try the same thing. The other thing is that I hope the problem will be temporary. With SIP v4 the generated code will be built as plugins/modules and not shared libraries. Phil From phil at river-bank.demon.co.uk Tue Aug 27 12:57:00 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] QTextDrag problems References: <35D93365CC362C40946B159819F5B761ECB996@XCH-NW-20.nw.nos.boeing.com> Message-ID: <3D6B5ADD.5050802@river-bank.demon.co.uk> Green, Gregory P wrote: > I am trying to decode the text in a QTextDrag object, received by a > QListView.contentsDropEvent method. The c++ signature of the object is: > > static bool decode(const QMimeSource*, QString&) > > The second argument is intended to receive the decoded text. PyQt copies > this signature exactly, so that a string needs to be passed, and a boolean > is received. That doesn't allow retrieval of the string though. Why doesn't it? The QString you pass is updated with the decoded string - or at least it should be. See dropsite.py in the examples directory. Phil From phil at river-bank.demon.co.uk Tue Aug 27 14:45:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] deadlock with QThread References: <200208250741.g7P7fH149853@steamteam.com> Message-ID: <3D6B7423.8000501@river-bank.demon.co.uk> Greg Fortune wrote: > Phil, > > We've managed to create a very nasty deadlock using the QThread class in an > application we are developing. I've attached some sample python code that > demonstrates several cases in which QThread does work and one case in which > it does not. > > Our application's code is closest to test case 4, but our code still does not > work. Regardless, test case 2 needs addressed and probably fixed :) It is > also possible that we just aren't using the QThread stuff correctly and in > that case, I'd love to know what we've missed. > > btw, the deadlock occurs when trying to import any module inside the > QThread.run call. Any function level imports in any code called by > QThread.run lock up the thread and any imports directly in the QThread.run > call lock up the thread. > > Oddly enough, imp.load_module() allows us to get around the bug, but only for > standard python modules (perhaps because they are loaded as an .so??). 3rd > party modules fail even in an imp.load_module() even though imp.find_module > is successful. Also, removing any function level imports also fixes the > problems, but the imports that cause problems are not in our code. They are > actually in the MySQLdb module, but any module doing a function level import > will cause the lock... > > I'm still trying to determine what makes our code different from test case 4, > which runs. If I figure that out, I'll send another test case that does not > work... Until then, let me know what you find out with regards to test case > 2. > > To execute test case 2, just run > ./threadtest.py 2 I haven't had a chance to look at this in detail, but here are some thoughts... In case 2 you are nesting imports, in case 3 you aren't. Python maintains an lock that prevents a module being imported by different threads at the same time. My guess is that the import lock is deadlocked. This then implies that the problem is a feature and unrelated to Qt's thread classes. My guess then would be that you would see the same problem if you used the standard Python thread module and didn't use PyQt at all. Phil From jgardn at alumni.washington.edu Tue Aug 27 17:27:00 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] PyKDE-3.3.2-2 build problems on stock Red Hat 7.3 sy In-Reply-To: References: Message-ID: <200208270819.40508.jgardn@alumni.washington.edu> On Monday 26 August 2002 09:56 pm, Jim Bublitz wrote: > On 27-Aug-02 Jonathan Gardner wrote: > > Could you make a few Mandrake RPMs? I posted earlier the spec for > > the Red Hat one. I figure we got a Red Hat guy, a SuSE guy, and > > if we get Mandrake working, all we'll be missing is Debian... > > Debian is already handled by Ricardo, and there probably wouldn't > be much benefit in hosting it, since Deb users would prefer to use > Debian's distribution system. Same for FreeBSD (Steve Simmons has > been working on putting sip/PyQt/PyKDE on 'ports'). I noticed I lost a few days worth of email. I looked up what I missed in the archives and I felt totally stupid and ignorant. I think that means that PyKDE and PyQt are now available for most everyone! > > Someone might try the RH rpms and see if they work on Mandrake - > I'm not sure how much Mandrake moves things around, but they're > fundamentally RH based. > I strongly doubt that the Red Hat RPMs will work with Mandrake. I believe that only Red Hat keeps python1.5 around, and they name it /usr/bin/python. From pete at bookware3000.ca Tue Aug 27 17:44:00 2002 From: pete at bookware3000.ca (Peter Osborne) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Mad rave about Eric! ....debs? In-Reply-To: <200208262006.16762.jgardn@alumni.washington.edu> References: <200208262006.16762.jgardn@alumni.washington.edu> Message-ID: <200208271150.47602.pete@bookware3000.ca> Is there a source for eric debs yet? -Pete On August 26, 2002 11:06 pm, Jonathan Gardner wrote: > I just got eric to run properly on Red Hat 7.3. I am debugging my program > right now, without the slightest hint of a problem. It is much better than > I thought it could be. > > Kudos to those who have worked on it! Keep it up! From tarlano at yahoo.com Tue Aug 27 18:17:00 2002 From: tarlano at yahoo.com (anthony tarlano) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Windows XP, PyQT and SIP Message-ID: <20020827161617.53375.qmail@web12701.mail.yahoo.com> I am trying to use PyQT with python.. I have the Microsoft Platform SDK on a window XP box, Python 2.2.1, SIP-3.3.2, the lastest QT download, and PyQT-3.3.2 The steps as far as I can tell is to nmake SIP and then nmake PyQT, not sure how I can use QT designer with python but I will get to that later... Now back to my big problem... And here it is.. Everytime I try to nmake the SIP distro I get the following error message c:\qt\include\qlist.h(105) : error C2491: 'QList::deleteItem' : definition of dllimport function not allowed NMAKE : fatal error U1077: 'cl' : return code '0x2' Any Suggestions???? The full output of the nmake is below... Thanks Anthony ------------------------------------------------------- C:\Python22\Lib\site-packages\sip-3.3.2>nmake Microsoft (R) Program Maintenance Utility Version 1.50 Copyright (c) Microsoft Corp 1988-94. All rights reserved. cd sipgen "c:\Program Files\Microsoft SDK\Bin\win64\nmake.exe" Microsoft (R) Program Maintenance Utility Version 7.10.2154.8 Copyright (C) Microsoft Corporation. All rights reserved. cd siplib "c:\Program Files\Microsoft SDK\Bin\win64\nmake.exe" Microsoft (R) Program Maintenance Utility Version 7.10.2154.8 Copyright (C) Microsoft Corporation. All rights reserved. cl -c -nologo -W0 -MD -O1 -DSIP_MAKE_DLL -DSIP_QT_SUPPORT -DQT_DLL -DQT_ THREAD_SUPPORT -DNO_DEBUG -I"." -I"c:\python22\include" -I"C:\qt\include" -I"c:\ Program Files\Microsoft SDK\include\win64\crt" -I"c:\Program Files\Microsoft SDK \include" -Foobjmap.obj objmap.c objmap.c cl -c -nologo -W0 -MD -O1 -DSIP_MAKE_DLL -DSIP_QT_SUPPORT -DQT_DLL -DQT_ THREAD_SUPPORT -DNO_DEBUG -I"." -I"c:\python22\include" -I"C:\qt\include" -I"c:\ Program Files\Microsoft SDK\include\win64\crt" -I"c:\Program Files\Microsoft SDK \include" -Foqtlib.obj qtlib.cpp qtlib.cpp c:\qt\include\qlist.h(105) : error C2491: 'QList::deleteItem' : definition of dllimport function not allowed NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x2' Stop. -------------------------------------------------- ===== Make it a great day!! __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com From eli.carter at inet.com Tue Aug 27 22:48:00 2002 From: eli.carter at inet.com (Eli Carter) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] newbie: QFileDialog Message-ID: <3D6BE549.2080503@inet.com> Ok, time for a dumb question. I've made a fleeting google attempt, and a cursory stroll through doc.trolltech.com/2.3 didn't turn up an answer. I want to use QFileDialog to let a user pick files on a remote system, such as over an ftp connection. I'm not really sure where to start. I expect to subclass it, but I don't know what internals would need to be overridden, where to find that out, or if that is possible in pyqt. A pointer to a discussion or documentation would be preferred, as this is something I expect I'll want to do more of in the future. (I want to learn the how's and why's so I can apply this in more than just this case.) TIA for any pointers, Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- From jgardn at u.washington.edu Wed Aug 28 00:16:00 2002 From: jgardn at u.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] New PyKDE Sourceforge Project Website Message-ID: <200208271508.37303.jgardn@u.washington.edu> With Jim's permission, I have set up a PyKDE website at Sourceforge. Hopefully, I can help Jim and Phil by letting them code more and worry about other things less. You can access the project page at: http://sf.net/projects/pykde You can access the downloads at: http://sourceforge.net/project/showfiles.php?group_id=61057 I am trying to assemble all the RPMs I can find. So far, I have Red Hat 7.3 and SuSE 8.0 rpms available. If anyone is running a different system (Mandrake!), you can email me and I'll help set up a spec file for the system. Older versions of Mandrake, Red Hat, and SuSE are acceptable (and encouraged!) as well. I am also putting the tar.gz's up, just to be complete. If you download a source rpms (src.rpm), you will get the tar.gz with that, so you don't need both the tars and the source rpms. My thought is that Python is so easy to use, Qt is so easy to use, and PyQt is so dang easy to use, that we should make the installation process easy to use as well. I am targetting newbies with these RPMs, so if you are having problems getting the RPMs installed, let me personally know, and I will help you. RPMs should install seamlessly, and I intend to do my best to make these RPMs do so. -- Jonathan Gardner jgardner@corp.classmates.com jgardn@u.washington.edu Wisdom from Slashdot... Changing between Linux distributions is like changing your underwear, but changing from Windows to Linux is more like getting a sex change. I know this, I've done both. I've migrated a server farm from Windows to Linux, that is, not gotten a sex change. I do change my underwear, though. I'll just stop typing now... From jgardn at alumni.washington.edu Wed Aug 28 05:45:01 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] PyKDE-3.3.2-2 build problems on stock Red Hat 7.3 sy In-Reply-To: References: Message-ID: <200208272045.33010.jgardn@alumni.washington.edu> On Monday 26 August 2002 09:51 pm, Jim Bublitz wrote: > On 26-Aug-02 Alex Willmer wrote: > > Sorry for leaving so long before I replied to this thread, I'va > > also been working on this, but on Mandrake 8.2. My system is > > definately KDE 3.0.1, and I received the same error. > > My guess would be that Mandrake 8.2 is based on RH 7.3 and would > therefore have the same version problem - RH changed the version > numbers (3.0.0 -> 3.0.1) on KDE 3.0.0. I've had that confirmed by > RH and it was posted to the list a while ago. the problem was noted > before KDE 3.0.1 was released. > I have found some spots where it won't work if I just pretend I have KDE 3.0.0. Some of the KDE_3_0_1 code is exactly the same as the header files I have on 7.3. Some of them are not. I am just going to make a patch and bundle it with the source RPMs. The patches will be useless for any other "well-built" KDE distro, but it will solve the Red Hat 7.3 headache. I have a question about some SIP code (more will follow): From boud at valdyas.org Wed Aug 28 07:20:01 2002 From: boud at valdyas.org (Boudewijn Rempt) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] newbie: QFileDialog In-Reply-To: <3D6BE549.2080503@inet.com> References: <3D6BE549.2080503@inet.com> Message-ID: <200208280718.49762.boud@valdyas.org> On Tuesday 27 August 2002 22:47, Eli Carter wrote: > Ok, time for a dumb question. I've made a fleeting google attempt, and > a cursory stroll through doc.trolltech.com/2.3 didn't turn up an answer. > > I want to use QFileDialog to let a user pick files on a remote system, > such as over an ftp connection. I'm not really sure where to start. I > expect to subclass it, but I don't know what internals would need to be > overridden, where to find that out, or if that is possible in pyqt. > > A pointer to a discussion or documentation would be preferred, as this > is something I expect I'll want to do more of in the future. (I want to > learn the how's and why's so I can apply this in more than just this case.) > The easiest solution might be to use PyKDE's filedialog which should provide most of this kind of behaviour. I think it would be hard to achieve what you want by just subclassing the existing dialog, since most of the file-system browsing code is private to the class. You might end up having to write your own filedialog that looks like the standard one. -- Boudewijn Rempt | http://www.valdyas.org From jbublitz at nwinternet.com Wed Aug 28 15:02:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] PyKDE-3.3.2-2 build problems on stock Red Hat 7.3 sy In-Reply-To: <200208272045.33010.jgardn@alumni.washington.edu> Message-ID: On 28-Aug-02 Jonathan Gardner wrote: > %If ( KDE_3_0_1 - ) "if KDE_VERSION >= 301" > enum CacheControl > { > CC_CacheOnly, > CC_Cache, > CC_Verify, > CC_Refresh, > CC_Reload > }; > %End > %If ( KDE_2_2_0 - KDE_3_0_1 ) "if KDE_VERSION >= 220 and KDE_VERSION < 301" > enum CacheControl > { > CC_CacheOnly, > CC_Cache, > CC_Verify, > CC_Reload > }; > %End > > Which block of code is used if I am running KDE_3_0_1? It's '>=' on the lower (left) limit and '<' on the upper (right) limit. Legal version values are defined in a %Timeline statement included somewhere in the sip files (dcop.sip for PyKDE). "Platform" conditionals (more in Qt) are "=" only (for example, WS_X11 or WS_WIN) Jim From david at sleepydog.net Wed Aug 28 15:30:00 2002 From: david at sleepydog.net (David Boddie) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] PyQt examples fail with QPaintDevice error Message-ID: <200208281429.29638.david@sleepydog.net> I hope that this isn't an FAQ... I've built PyQt with the following setup: python build.py -b /usr/bin -c -i /opt/qt/include -l qt-mt -p /usr/bin/sip -q /opt/qt -s /usr/lib/python2.1/site-packages Threaded Qt 3.0.3 is being used (I have libqt-mt.so.3.0.3 in /opt/qt/lib) and Python is installed in /usr/lib/python2.1. There appear to be no error in configuring PyQt, building it or installing it. However, when I try the examples in PyQt-3.3.2/examples3 I get, for example: [david@bunsen examples3]$ python tut1.py Loading required GL library /usr/X11R6/lib/libGL.so.1.2.030402 QPaintDevice: Must construct a QApplication before a QPaintDevice Aborted What have I done wrong? -- David ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ From pef at fluent.com Wed Aug 28 15:39:01 2002 From: pef at fluent.com (Paul Felix) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] newbie: QFileDialog References: <20020828100001.27654.12351.Mailman@mats> Message-ID: <3D6CD1DA.A989B2B3@fluent.com> > From: Eli Carter > > Ok, time for a dumb question. I've made a fleeting google attempt, and > a cursory stroll through doc.trolltech.com/2.3 didn't turn up an answer. > > I want to use QFileDialog to let a user pick files on a remote system, > such as over an ftp connection. I'm not really sure where to start. I > expect to subclass it, but I don't know what internals would need to be > overridden, where to find that out, or if that is possible in pyqt. > > A pointer to a discussion or documentation would be preferred, as this > is something I expect I'll want to do more of in the future. (I want to > learn the how's and why's so I can apply this in more than just this case.) > > TIA for any pointers, > Hi Eli, I believe the answer is QUrlOperator. Try this: from qt import * from qtnetwork import * qInitNetworkProtocols() op = QUrlOperator("ftp://ftp.trolltech.com") fd = QFileDialog() fd.setUrl(op) fd.exec_loop() Paul From jgardner at corp.classmates.com Wed Aug 28 17:47:01 2002 From: jgardner at corp.classmates.com (Jonathan Gardner) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Mad rave about Eric! ....debs? In-Reply-To: <200208271150.47602.pete@bookware3000.ca> References: <200208262006.16762.jgardn@alumni.washington.edu> <200208271150.47602.pete@bookware3000.ca> Message-ID: <200208271445.52944.jgardner@corp.classmates.com> On Tuesday 27 August 2002 08:50 am, Peter Osborne wrote: > Is there a source for eric debs yet? > Doesn't eric come with PyQt? It comes with PyQt with the default Red Hat, and it is part of the PyQt tar.gz. -- Jonathan Gardner jgardner@corp.classmates.com Wisdom from Slashdot... Changing between Linux distributions is like changing your underwear, but changing from Windows to Linux is more like getting a sex change. I know this, I've done both. I've migrated a server farm from Windows to Linux, that is, not gotten a sex change. I do change my underwear, though. I'll just stop typing now... From jgardn at alumni.washington.edu Thu Aug 29 02:47:01 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] New(er) PyKDE RPMs for Red Hat Message-ID: <200208281747.25131.jgardn@alumni.washington.edu> I put together some newer PyKDe RPMs for Red Hat. The PyKDE RPM is now split into three separate ones (devel and docs) and it includes a patch to insure that the PyKDE matches exactly with the KDE version in Red Hat. I also got Jim's latest version - PyKDE-3.3.2-3 - in there. You can download it from: http://sf.net/project/showfiles.php?group_id=61057 -- Jonathan Gardner jgardn@alumni.washington.edu From jgardn at alumni.washington.edu Thu Aug 29 03:12:01 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Licensing issues Message-ID: <200208281812.19987.jgardn@alumni.washington.edu> It seems I made a serious mistake. The Red Hat RPMs list PyKDE, PyQt, and sip as GPL, as do some erroneous websites. However, it seems like the license is more of a BSD or MIT license. Looking on the Sourceforge site Jim Bublitz set up, he lists PyKDE as MIT. Oops. I listed sip, PyQt and PyKDE as GPL without really thinking too much of it. I want to get a confirmation of PyKDE, PyQt, and sip all being MIT licensed. If so, I will go and fix everything up. -- Jonathan Gardner jgardn@alumni.washington.edu From jbublitz at nwinternet.com Thu Aug 29 06:04:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Licensing issues In-Reply-To: <200208281812.19987.jgardn@alumni.washington.edu> Message-ID: On 29-Aug-02 Jonathan Gardner wrote: > It seems I made a serious mistake. > > The Red Hat RPMs list PyKDE, PyQt, and sip as GPL, as do some > erroneous websites. However, it seems like the license is more > of a BSD or MIT license. Looking on the Sourceforge site Jim > Bublitz set up, he lists PyKDE as MIT. > Oops. I listed sip, PyQt and PyKDE as GPL without really thinking > too much of > it. > I want to get a confirmation of PyKDE, PyQt, and sip all being > MIT licensed. If so, I will go and fix everything up. PyKDE is licensed under the MIT or 'X' license - the license is included in the top level file for each module (eg dcop.sip, kdecore.sip, etc.). I'd assume you can license the rpms any way you want, as long as you include the copyrights and the license - that's pretty much what the license says. Jim From mickey at tm.informatik.uni-frankfurt.de Thu Aug 29 13:52:00 2002 From: mickey at tm.informatik.uni-frankfurt.de (Michael Lauer) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] QPEApplication.setStylusOperation() woes In-Reply-To: References: Message-ID: <1030621871.4620.13.camel@gandalf.tm.informatik.uni-frankfurt.de> Dear fellow PyQt'ers... did anyone have luck using QPEApplication.setStylusOperation( QPEApplication.RightOnHold)? It simply doesn't work for me: no right press event is emitted when it should be. I'm currently patching a libqpe.so to print out some debug information, maybe someone else can also shed some light onto this situation? Yours, -- :M: -------------------------------------------------------------------------- Dipl.-Inf. Michael 'Mickey' Lauer mickey@tm.informatik.uni-frankfurt.de Raum 10b - ++49 69 798 28358 Fachbereich Informatik und Biologie -------------------------------------------------------------------------- From tarlano at yahoo.com Thu Aug 29 14:14:01 2002 From: tarlano at yahoo.com (anthony tarlano) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Fwd: Windows XP, PyQT and SIP Message-ID: <20020829121336.28062.qmail@web12702.mail.yahoo.com> Please Help!! --- anthony tarlano wrote: > Date: Tue, 27 Aug 2002 09:16:17 -0700 (PDT) > From: anthony tarlano > Subject: Windows XP, PyQT and SIP > To: pykde@mats.gmd.de > > I am trying to use PyQT with python.. > > I have the Microsoft Platform SDK on a window XP > box, > Python 2.2.1, SIP-3.3.2, the lastest QT download, > and > PyQT-3.3.2 > > The steps as far as I can tell is to nmake SIP and > then nmake PyQT, not sure how I can use QT designer > with python but I will get to that later... Now back > to my big problem... And here it is.. Everytime I > try > to nmake the SIP distro I get the following error > message > > c:\qt\include\qlist.h(105) : error C2491: > 'QList::deleteItem' : definition > of dllimport function not allowed > NMAKE : fatal error U1077: 'cl' : return code '0x2' > > Any Suggestions???? The full output of the nmake is > below... Thanks Anthony > > > > ------------------------------------------------------- > > C:\Python22\Lib\site-packages\sip-3.3.2>nmake > > Microsoft (R) Program Maintenance Utility Version > 1.50 > Copyright (c) Microsoft Corp 1988-94. All rights > reserved. > > cd sipgen > "c:\Program Files\Microsoft > SDK\Bin\win64\nmake.exe" > > Microsoft (R) Program Maintenance Utility Version > 7.10.2154.8 > Copyright (C) Microsoft Corporation. All rights > reserved. > > cd siplib > "c:\Program Files\Microsoft > SDK\Bin\win64\nmake.exe" > > Microsoft (R) Program Maintenance Utility Version > 7.10.2154.8 > Copyright (C) Microsoft Corporation. All rights > reserved. > > cl -c -nologo -W0 -MD -O1 -DSIP_MAKE_DLL > -DSIP_QT_SUPPORT -DQT_DLL -DQT_ > THREAD_SUPPORT -DNO_DEBUG -I"." > -I"c:\python22\include" -I"C:\qt\include" -I"c:\ > Program Files\Microsoft SDK\include\win64\crt" > -I"c:\Program Files\Microsoft SDK > \include" -Foobjmap.obj objmap.c > objmap.c > cl -c -nologo -W0 -MD -O1 -DSIP_MAKE_DLL > -DSIP_QT_SUPPORT -DQT_DLL -DQT_ > THREAD_SUPPORT -DNO_DEBUG -I"." > -I"c:\python22\include" -I"C:\qt\include" -I"c:\ > Program Files\Microsoft SDK\include\win64\crt" > -I"c:\Program Files\Microsoft SDK > \include" -Foqtlib.obj qtlib.cpp > qtlib.cpp > c:\qt\include\qlist.h(105) : error C2491: > 'QList::deleteItem' : definition > of dllimport function not allowed > NMAKE : fatal error U1077: 'cl' : return code '0x2' > Stop. > NMAKE : fatal error U1077: > 'C:\WINDOWS\system32\cmd.exe' : return code '0x2' > Stop. > -------------------------------------------------- > > > > > ===== > Make it a great day!! > > __________________________________________________ > Do You Yahoo!? > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com > ===== Make it a great day!! __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com From soeren.fietzke at mscsoftware.com Thu Aug 29 15:03:00 2002 From: soeren.fietzke at mscsoftware.com (Soeren Fietzke) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Fwd: Windows XP, PyQT and SIP References: <20020829121336.28062.qmail@web12702.mail.yahoo.com> Message-ID: <004001c24f5c$03a0ca90$73c8a8c0@D10121> Anthony, in your original post, you left out the most important info: which compiler version and which *exact* Qt version are you using? Early versions of Qt 3.0 (up to 3.0.3) could not be used with MSVC.Net and would cause errors like the one you are seeing. Is "the latest Qt download" really 3.0.4 or later? Soeren > > > > I have the Microsoft Platform SDK on a window XP > > box, > > Python 2.2.1, SIP-3.3.2, the lastest QT download, > > and > > PyQT-3.3.2 > > > > c:\qt\include\qlist.h(105) : error C2491: > > 'QList::deleteItem' : definition > > of dllimport function not allowed > > NMAKE : fatal error U1077: 'cl' : return code '0x2' From cjm at ava.com.au Thu Aug 29 15:22:01 2002 From: cjm at ava.com.au (Chris Munchenberg) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] FreeBSD build problems error 23512 Message-ID: <001a01c24f5f$2ad0a740$0100a8c0@server> Hi, I'm looking for help building PyKDE on FreeBSD. I'm new at this, and blind, dumb luck has got me this far but no further. Versions etc: FreeBSD 4.6 QT 3.0.3 KDE 3.0.0 Python 2.2.1 PyQT 3.3.2 PyKDE 3.3.2 QTDIR = /usr/X11R6 KDEDIR = /usr/local PyQT built with no problems once I read the instructions, but this hasn't got me any further with PyKDE. I appreciate any help at this stage, or suggestions. I've looked through the last 3 months archives to try to ensure I'm not repeating a stupid mistake, but I can't guarrantee its an original stupid mistake. Thanks for any advice, Chris. The message I get is: /PyKDE-3.3.2#python build.py -z buildrc Building PyKDE 3.3 for Python 2.2.1 on freebsd4. /usr/local/lib/python2.2/site-packages is the PyKDE installation directory. /usr/local/include/python2.2 contains Python.h. /usr/local/bin/sip will be used as the SIP code generator. /usr/local/include/python2.2 contains sipQt.h. /usr/local/lib/python2.2/site-packages contains the SIP module. /usr/X11R6 is the Qt base directory. /usr/X11R6/include contains qglobal.h. Qt 3.0.3 is being used. /usr/local is the KDE base directory. /usr/local/include contains kdeversion.h. KDE 3.0.0 is being used. /usr/X11R6/bin/qmake will be used to generate Makefiles. The qt-mt Qt library was found. Qt thread support is enabled. Qt and KDE use compatible libs (threading) found libs for modules: dcop kdecore kdesu kdefx kdeui kio kfile (kio) kparts khtml kjs kspell kdeprint PyQt/sip directory found at ../PyQt-3.3.2/sip /usr/bin/make will be used as the make program. Checking to see if the C++ compiler supports -fno-exceptions. g++ -c -pipe -w -O2 -pthread -D_THREAD_SAFE -DQT_NO_DEBUG -DQT_THREAD_SUPPO RT -fno-exceptions -I. -I/us r/local/include/python2.2 -I/usr/local/include -I/usr/local/include -I/usr/X 11R6/include -I/usr/X11R6/mk specs/default -o qttest.o qttest.cpp g++ -pthread -o qttest qttest.o -L/usr/local/lib -Wl,-rpath,/usr/X11R6/lib -L/usr/X11R6/lib -L/u sr/X1 1R6/lib -lqt-mt -lXext -lX11 -lm The C++ compiler supports -fno-exceptions. Using existing features file. Copying sip module files for version KDE300 to sip directory Copying version specific h files for KDE300 to extraH directory Generating the C++ source for the dcop module. ./postproc: not found **************************************************************************** ** Error: ./postproc failed with an exit code of 32512 -- from line 1125 in build.py **************************************************************************** ** From tarlano at yahoo.com Thu Aug 29 15:27:00 2002 From: tarlano at yahoo.com (anthony tarlano) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Fwd: Windows XP, PyQT and SIP In-Reply-To: <004001c24f5c$03a0ca90$73c8a8c0@D10121> Message-ID: <20020829132650.27462.qmail@web12703.mail.yahoo.com> Soeren, Thanks for the reply, I didn't realize that I had forgot to include some information here is what I have: Microsoft (R) C/C++ Optimizing Compiler Version 13.10.2154.8 for IA-64 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] and Qt 2.3.0 Thanks, Anthony --- Soeren Fietzke wrote: > Anthony, > > in your original post, you left out the most > important info: which compiler version and which > *exact* Qt version are you using? > Early versions of Qt 3.0 (up to 3.0.3) could not be > used with MSVC.Net and would cause errors like the > one you are seeing. > Is "the latest Qt download" really 3.0.4 or later? > > Soeren > > > > > > > > I have the Microsoft Platform SDK on a window XP > > > box, > > > Python 2.2.1, SIP-3.3.2, the lastest QT > download, > > > and > > > PyQT-3.3.2 > > > > > > c:\qt\include\qlist.h(105) : error C2491: > > > 'QList::deleteItem' : definition > > > of dllimport function not allowed > > > NMAKE : fatal error U1077: 'cl' : return code > '0x2' > > > _______________________________________________ > PyKDE mailing list PyKDE@mats.gmd.de > http://mats.gmd.de/mailman/listinfo/pykde ===== Make it a great day!! __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com From soeren.fietzke at mscsoftware.com Thu Aug 29 16:05:00 2002 From: soeren.fietzke at mscsoftware.com (Soeren Fietzke) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Fwd: Windows XP, PyQT and SIP References: <20020829132650.27462.qmail@web12703.mail.yahoo.com> Message-ID: <005701c24f64$a71e4d20$73c8a8c0@D10121> Anthony, AFAIK, if you are using Qt 2.3 non-commercial, you cannot use MSVC.Net, due to a glitch in the Qt header files (template classes *must not* be exported from a DLL). If you are not using the non-commercial version, have access to the Qt source code and do not want to upgrade to Qt 3.0.5, you could try to fix the Qt header files and rebuild your Qt lib: http://lists.trolltech.com/qt-interest/2002-04/thread00621-0.html Otherwise, the only option that comes to mind is to revert to MSVC 6. Good luck, Soeren > Soeren, > > Thanks for the reply, I didn't realize that I had > forgot to include some information here is what I > have: > > > Microsoft (R) C/C++ Optimizing Compiler Version > 13.10.2154.8 for IA-64 > Copyright (C) Microsoft Corporation 1984-2002. All > rights reserved. > > usage: cl [ option... ] filename... [ /link > linkoption... ] > > and Qt 2.3.0 > > Thanks, > > Anthony From jbublitz at nwinternet.com Thu Aug 29 17:02:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] FreeBSD build problems error 23512 In-Reply-To: <001a01c24f5f$2ad0a740$0100a8c0@server> Message-ID: On 29-Aug-02 Chris Munchenberg wrote: > Generating the C++ source for the dcop module. > ./postproc: not found > ****************************************************************** > Error: ./postproc failed with an exit code of 32512 -- from line > 1125 in build.py > ****************************************************************** For some reason, build.py is unable to find the 'postproc' script, which should be in the toplevel directory of the tarball (I've just double-checked all of the 3.3.2 releases, and it's present in each one). Either the file is missing, you're not executing build.py from the top level PyKDE-3.3.2 directory, or there's some other problem (permissions?) preventing you from executing a program in the current directory. The error code is being returned by a call to os.system (). Jim From jgardn at alumni.washington.edu Thu Aug 29 17:22:00 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Re: Trouble with new RedHat SRPMS In-Reply-To: References: <200208281747.25131.jgardn@alumni.washington.edu> Message-ID: <200208290813.48410.jgardn@alumni.washington.edu> On Thursday 29 August 2002 06:59 am, Neal D. Becker wrote: > rpm --rebuild sip-3.3.2-6.src.rpm > Installing sip-3.3.2-6.src.rpm > error: failed build dependencies: > qt-devel = 3.0.3 is needed by sip-3.3.2-6 > [nbecker@rpppc1 ~]$ rpm -q qt-devel > qt-devel-3.0.5-7.11 > > Do we really have to have qt-devel = 3.0.3, not >=? I don't know. Go ahead and change that line in the spec, and give it another go. What version of Red Hat are you using? I am using a base Red Hat 7.3 with no modifications to the KDE and Qt libraries in the package. I can't test it on any other system, so I can't say whether Qt 3.0.5 will work or not. Jonathan From jgardn at alumni.washington.edu Thu Aug 29 17:58:00 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Re: Trouble with new RedHat SRPMS In-Reply-To: References: <200208281747.25131.jgardn@alumni.washington.edu> <200208290813.48410.jgardn@alumni.washington.edu> Message-ID: <200208290850.00969.jgardn@alumni.washington.edu> On Thursday 29 August 2002 08:22 am, Neal D. Becker wrote: > >>>>> "Jonathan" == Jonathan Gardner > >>>>> writes: > > > What version of Red Hat are you using? I am using a base Red Hat 7.3 > > with no modifications to the KDE and Qt libraries in the package. I > > can't test it on any other system, so I can't say whether Qt 3.0.5 will > > work or not. > > I have RH7.3 + updates + kde-3.0.3 Okay, I can guarantee that it won't build for you because of the patch I developed specifically for Red Hat 7.3 with no upgrades. I can also pretty much guarantee that it won't work if you forced the RPMs. You'll have to remove the patch from the spec file. If you install the SRPM (rpm -i), it should put the tar.gz and the path in the /usr/src/redhat/SOURCES directory, and put the spec file in the /usr/src/redhat/SPECS directory. Go ahead and edit the spec file(s) and then try to rebuild. There is one critical change that I made that you'll want to keep. I changed all the references to /usr/bin/python and /usr/bin/env python to point to python2. I'll make the two patches distinct in the next release (which should be today). -- Jonathan Gardner From polgardy at bodacion.com Thu Aug 29 18:40:01 2002 From: polgardy at bodacion.com (Frederick Polgardy Jr) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Quitting invokes crash handler Message-ID: <200208291138.41116.polgardy@bodacion.com> Can anyone explain to me why, in the following app, choosing Quit from the File menu invokes the crash handler, but closing the window terminates gracefully? Is there something about KDE or Python I'm unaware of? Thanks in advance, Fred Relevant versions: KDE 3.0.3 Python 2.2.1 SIP/PyQT/PyKDE 3.3.2 Code snippet: import sys from qt import SIGNAL, QObject from kdecore import KCmdLineArgs, KApplication from kdeui import KMainWindow, KPopupMenu, KActionCollection, KStdAction class stuff(KMainWindow): def __init__(self, parent = None, name = None, fl = 0): KMainWindow.__init__(self, parent, name, fl) # create a status bar self.statusBar() # create the menubar fileMenu = KPopupMenu(self) actionCollection = KActionCollection(self) quitAction = KStdAction.quit(self.fileQuit, actionCollection) quitAction.plug(fileMenu) self.menuBar().insertItem(self.trUtf8("&File"), fileMenu) def fileQuit(self): print "About to quit..." KApplication.kApplication().quit() if __name__ == "__main__": KCmdLineArgs.init(sys.argv, "stuff", "Crash Test", "0.1") a = KApplication() w = stuff() w.show() a.setMainWidget(w) a.connect(a, SIGNAL("lastWindowClosed()"), w.fileQuit) a.exec_loop() From nbecker at hns.com Thu Aug 29 18:41:01 2002 From: nbecker at hns.com (Neal D. Becker) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Re: Trouble with new RedHat SRPMS In-Reply-To: <200208290850.00969.jgardn@alumni.washington.edu> References: <200208281747.25131.jgardn@alumni.washington.edu> <200208290813.48410.jgardn@alumni.washington.edu> <200208290850.00969.jgardn@alumni.washington.edu> Message-ID: I link /usr/bin/python -> /usr/bin/python2, so I don't need the patch. FYI, on RH7.3 this is pretty safe - the only effect has been stupid warning messages about deprecated python modules in the system logs. From nbecker at hns.com Thu Aug 29 18:41:12 2002 From: nbecker at hns.com (Neal D. Becker) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Re: Trouble with new RedHat SRPMS In-Reply-To: <200208290813.48410.jgardn@alumni.washington.edu> References: <200208281747.25131.jgardn@alumni.washington.edu> <200208290813.48410.jgardn@alumni.washington.edu> Message-ID: >>>>> "Jonathan" == Jonathan Gardner writes: Jonathan> What version of Red Hat are you using? I am using a base Red Hat 7.3 with no Jonathan> modifications to the KDE and Qt libraries in the package. I can't test it Jonathan> on any other system, so I can't say whether Qt 3.0.5 will work or not. I have RH7.3 + updates + kde-3.0.3 From nbecker at hns.com Thu Aug 29 18:41:23 2002 From: nbecker at hns.com (Neal D. Becker) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Trouble with new RedHat SRPMS In-Reply-To: <200208281747.25131.jgardn@alumni.washington.edu> References: <200208281747.25131.jgardn@alumni.washington.edu> Message-ID: rpm --rebuild sip-3.3.2-6.src.rpm Installing sip-3.3.2-6.src.rpm error: failed build dependencies: qt-devel = 3.0.3 is needed by sip-3.3.2-6 [nbecker@rpppc1 ~]$ rpm -q qt-devel qt-devel-3.0.5-7.11 Do we really have to have qt-devel = 3.0.3, not >=? From polgardy at bodacion.com Thu Aug 29 19:16:00 2002 From: polgardy at bodacion.com (Frederick Polgardy Jr) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Quitting invokes crash handler In-Reply-To: <200208291138.41116.polgardy@bodacion.com> References: <200208291138.41116.polgardy@bodacion.com> Message-ID: <200208291214.37907.polgardy@bodacion.com> Fascinating. If I add a 'w = None' after returning from a.exec_loop(), the crash problem goes away.... It's also interesting that this wasn't happening with Python 2.1.3 yesterday (the Debian packages for 2.2 were uploaded last night). Ideas? Fred On Thursday 29 August 2002 11:38 am, Frederick Polgardy Jr wrote: > Can anyone explain to me why, in the following app, choosing Quit from > the File menu invokes the crash handler, but closing the window > terminates gracefully? Is there something about KDE or Python I'm > unaware of? > > Thanks in advance, > Fred > > Relevant versions: > > KDE 3.0.3 > Python 2.2.1 > SIP/PyQT/PyKDE 3.3.2 > > Code snippet: > > import sys > from qt import SIGNAL, QObject > from kdecore import KCmdLineArgs, KApplication > from kdeui import KMainWindow, KPopupMenu, KActionCollection, KStdAction > > class stuff(KMainWindow): > def __init__(self, parent = None, name = None, fl = 0): > KMainWindow.__init__(self, parent, name, fl) > > # create a status bar > self.statusBar() > > # create the menubar > fileMenu = KPopupMenu(self) > actionCollection = KActionCollection(self) > quitAction = KStdAction.quit(self.fileQuit, actionCollection) > quitAction.plug(fileMenu) > self.menuBar().insertItem(self.trUtf8("&File"), fileMenu) > > def fileQuit(self): > print "About to quit..." > KApplication.kApplication().quit() > > if __name__ == "__main__": > KCmdLineArgs.init(sys.argv, "stuff", "Crash Test", "0.1") > a = KApplication() > w = stuff() > w.show() > a.setMainWidget(w) > a.connect(a, SIGNAL("lastWindowClosed()"), w.fileQuit) > a.exec_loop() > > _______________________________________________ > PyKDE mailing list PyKDE@mats.gmd.de > http://mats.gmd.de/mailman/listinfo/pykde -- F R E D E R I C K P O L G A R D Y J R. Bodacion Technologies - A Virtual Media Company 18-3 E Dundee Road - Suite 300 - Barrington, IL 60010 Phone: 847/842.9008 - Fax: 847/842-1731 Web: http://www.bodacion.com From Brent.Burley at disney.com Thu Aug 29 21:04:01 2002 From: Brent.Burley at disney.com (Burley, Brent) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] PyQt not refing slot methods - bug? Message-ID: <3D6E6FD3.8D002912@fa.disney.com> I was trying to use a lambda method as a slot method like this: import sys from qt import * def hello(): print 'hello' app = QApplication(sys.argv) b = QPushButton('hello', None) QObject.connect(b, SIGNAL('clicked()'), lambda: hello()) app.setMainWidget(b) b.show() app.exec_loop() The lambda method never gets called. It appears that PyQt doesn't ref slot methods so the lambda method gets deleted before it can be used. If I change the code to keep a reference to the lambda, it works fine: l = lambda: hello() QObject.connect(b, SIGNAL('clicked()'), l) Is it a bug that PyQt isn't refing slot methods? Doesn't anyone use lambdas for slots? Brent Burley brent.burley@disney.com From gordon at doxxx.net Thu Aug 29 21:06:00 2002 From: gordon at doxxx.net (Gordon Tyler) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Quitting invokes crash handler References: <200208291138.41116.polgardy@bodacion.com> Message-ID: <3D6E708A.3000306@doxxx.net> Frederick Polgardy Jr wrote: > a.connect(a, SIGNAL("lastWindowClosed()"), w.fileQuit) I would write the above line like this (wordwrapped for reading): a.connect(a, SIGNAL("lastWindowClosed()"), KApplication.kApplication(), SLOT("quit()")) Isn't there a kApp global variable like there is qApp? Ciao, Gordon From scs at di.org Thu Aug 29 21:13:01 2002 From: scs at di.org (Steve Simmons) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] FreeBSD build problems error 23512 Message-ID: <20020829190027.GA8415@lokkur.dexter.mi.us> Chris Munchenberg writes: > I'm looking for help building PyKDE on FreeBSD. . . . [ snip ] > . . . > Generating the C++ source for the dcop module. > ./postproc: not found I had the same problem. The cause is that postproc is a python script which begins #!/usr/bin/python That's not where python is installed on FreeBSD. I changed it to #!/usr/local/bin/python and it worked fine. I'm working on a formal FreeBSD port for PyKDE, PyQt and sip. -- "The faster you go DEAF the more time you have to READ." edu-core heavy-metal band Bloodhag From scs at di.org Thu Aug 29 21:31:00 2002 From: scs at di.org (Steve Simmons) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] FreeBSD build problems error 23512 In-Reply-To: <20020829190027.GA8415@lokkur.dexter.mi.us> References: <20020829190027.GA8415@lokkur.dexter.mi.us> Message-ID: <20020829191831.GA8568@lokkur.dexter.mi.us> On Thu, Aug 29, 2002 at 03:00:27PM -0400, Steve Simmons wrote: > #!/usr/bin/python > > That's not where python is installed on FreeBSD. I changed it to > > #!/usr/local/bin/python > > and it worked fine. A couple of more notes on this. Jim B writes: > For some reason, build.py is unable to find the 'postproc' script . . . This is a common misconception. Any time you run a shell script and immediately get the message `scriptname: not found' the problem is almost certianly that whatever is on the #! line was not found. On a different note, python can determine where it is run from. We should mod the installation package for the various items so one of the early steps is # python -c 'import sys; print sys.executable' and use the response to build the #! lines. This may come for free with ./configure, that might be the right place to put it. From jbublitz at nwinternet.com Thu Aug 29 22:02:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Quitting invokes crash handler In-Reply-To: <200208291138.41116.polgardy@bodacion.com> Message-ID: On 29-Aug-02 Frederick Polgardy Jr wrote: > Can anyone explain to me why, in the following app, choosing Quit > from the File menu invokes the crash handler, but closing the > window terminates gracefully? Is there something about KDE or > Python I'm unaware of? > Relevant versions: > KDE 3.0.3 > Python 2.2.1 > SIP/PyQT/PyKDE 3.3.2 I used KDE 2.1.1. > Code snippet: > import sys > from qt import SIGNAL, QObject > from kdecore import KCmdLineArgs, KApplication > from kdeui import KMainWindow, KPopupMenu, KActionCollection, > KStdAction > class stuff(KMainWindow): > def __init__(self, parent = None, name = None, fl = 0): > KMainWindow.__init__(self, parent, name, fl) > > # create a status bar > self.statusBar() > > # create the menubar > fileMenu = KPopupMenu(self) > actionCollection = KActionCollection(self) > quitAction = KStdAction.quit(self.fileQuit, > actionCollection) > quitAction.plug(fileMenu) > self.menuBar().insertItem(self.trUtf8("&File"), fileMenu) The above line shouldn't run at all - 'trUtf8' is not a PyKDE method, and KDE is compiled with Qt translation functions disabled. You want to replace this with the static function i18n self.menuBar().insertItem(i18n("&File"), fileMenu) (and add i18n to kdecore's import list) > def fileQuit(self): > print "About to quit..." > KApplication.kApplication().quit() > > if __name__ == "__main__": > KCmdLineArgs.init(sys.argv, "stuff", "Crash Test", "0.1") > a = KApplication() > w = stuff() > w.show() Comment out these two lines: ># a.setMainWidget(w) ># a.connect(a, SIGNAL("lastWindowClosed()"), w.fileQuit) The first line is, I believe, not necessary; the second line's effect can be accomplished by overriding 'queryExit' or 'queryClose' in the KMainWindow descendant - you can have one of those call 'fileQuit'. I'm not sure what the problem is with the above lines. > a.exec_loop() Change the variable name 'a' to 'app' or 'ddd' or apparently any other name with *exactly* 3 characters. You probably think I'm either kidding or hallucinating by now - I'm not. For example, I can get 'ddd' to work, but not 'd', 'dd', 'dddd', or 'ddddd'. I have no explanation - other than performing an explicit test for the length of the variable name (which I'm assuming doesn't happen) I can't imagine how code could possibly work this way. Note that other than 3 character variable names will run - they'll just segfault at exit. I wish I knew where to begin looking for what causes this, because this will be a really stupid restriction if it proves necessary. If I take care of those three things, it runs fine on KDE 2.1.1/PyKDE 3.3.2 - I'll try it on KDE 3.0.2 and see if there's any difference. Let me know if you get the same results. Jim From jbublitz at nwinternet.com Thu Aug 29 22:02:24 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Quitting invokes crash handler In-Reply-To: <200208291214.37907.polgardy@bodacion.com> Message-ID: On 29-Aug-02 Frederick Polgardy Jr wrote: > Fascinating. If I add a 'w = None' after returning from > a.exec_loop(), the crash problem goes away.... It's also > interesting that this wasn't happening with Python 2.1.3 > yesterday (the Debian packages for 2.2 were uploaded last > night). > Ideas? w = None works for me too, and is much better than restricting KApplication variable names to three letters (I don't know why, but that worked). A 'del w' (which is effectively the same) will work also. The w = None is at least reasonable - it points to some problem with 'w' (KMainWindow) needing to be destroyed before the 'exit' code runs. Between that and the sensitivity to the length of a variable name, it appears to be some sort of memory allocation or pointer error - it could be a Python 2.2 problem also in that case. Once again, I'd love to fix this but have no idea where to begin. Jim From hpj at urpla.net Thu Aug 29 23:45:01 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Qt progress example with minor glitch Message-ID: <200208292343.50611.hpj@urpla.net> Hi PyQties, after returning from holiday, I needed something easy to start with: looking through the Qt examples, I hadn't touched before, I found progress. While the translation was pretty straight forward, I've come across these stranglets: - cancel a custom label progress dialog don't cancel its timer (although I've tried hard to kill it explicitly). - sometimes cancel triggers these messages: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 20 Resource id: 0x16bce29 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 15 Resource id: 0x16bce29 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 40 Resource id: 0x16bce29 It happens also with the c++ version, so I'm not really troubled... I couldn't resist from modifying its visual appearance slightly, and delayed the timer interval to behave a bit more cooperative (unlike its ancestor). Comments welcome! Hans-Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: progress.py Type: text/x-python Size: 9243 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020829/c4c14b3c/progress.py From jbublitz at nwinternet.com Fri Aug 30 00:05:02 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] FreeBSD build problems error 23512 In-Reply-To: <20020829191831.GA8568@lokkur.dexter.mi.us> Message-ID: On 29-Aug-02 Steve Simmons wrote: > On Thu, Aug 29, 2002 at 03:00:27PM -0400, Steve Simmons wrote: >> #!/usr/bin/python >> That's not where python is installed on FreeBSD. I changed it >> to >> #!/usr/local/bin/python >> and it worked fine. > A couple of more notes on this. Jim B writes: >> For some reason, build.py is unable to find the 'postproc' >> script . . . > This is a common misconception. Any time you run a shell script > and immediately get the message `scriptname: not found' the > problem is almost certianly that whatever is on the #! line was > not found. > On a different note, python can determine where it is run from. > We should mod the installation package for the various items so > one of the early steps is > # python -c 'import sys; print sys.executable' > and use the response to build the #! lines. This may come for > free with ./configure, that might be the right place to put it. Unless you're using configure to build for FreeBSD, there no longer is a ./configure for PyKDE, but that, in fact is where the problem originated. ./configure used to locate python and pass it to the Makefiles which then used it to invoke the scripts. build.py knows where python is (that's why you have to use 'python build.py ...' to run it), and should use the located interpreter to run postproc (eg - '/python postproc ...'), but doesn't. The #! in postproc really doesn't belong there - it's there as a convenience to me and is guaranteed to work on my system, but obviously is correct for all systems. However, having it there, I overlooked the need to invoke postproc correctly. I'll fix build.py for the next release. Jim From jbublitz at nwinternet.com Fri Aug 30 00:05:21 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Quitting invokes crash handler In-Reply-To: <3D6E708A.3000306@doxxx.net> Message-ID: On 29-Aug-02 Gordon Tyler wrote: > Frederick Polgardy Jr wrote: >> a.connect(a, SIGNAL("lastWindowClosed()"), w.fileQuit) > I would write the above line like this (wordwrapped for reading): > a.connect(a, SIGNAL("lastWindowClosed()"), > KApplication.kApplication(), SLOT("quit()")) The original line is both correct and different in function from your suggested rewrite. 'w.fileQuit' might actually do something useful (like save files, cleanup, etc) in a real program. > Isn't there a kApp global variable like there is qApp? No, there isn't (in PyKDE; it exists in KDE), because it causes problems between the sip generated code and gcc 2.96 on RH/Mandrake. (I'm not sure if qApp exists in PyQt either - I believe it was gone last time I checked, but I could be wrong). There is a static method KApplication.kApplication() that returns the same pointer as kApp, as used in your example above. Jim From jgardn at alumni.washington.edu Fri Aug 30 03:06:01 2002 From: jgardn at alumni.washington.edu (Jonathan Gardner) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] New RedHat 7.3 RPMs available Message-ID: <200208291805.54698.jgardn@alumni.washington.edu> You can grab them from the usual location: http://sf.net/project/showfiles.php?group_id=61057 Enjoy! -- Jonathan Gardner jgardn@alumni.washington.edu From boud at valdyas.org Fri Aug 30 07:17:01 2002 From: boud at valdyas.org (Boudewijn Rempt) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Qt progress example with minor glitch In-Reply-To: <200208292343.50611.hpj@urpla.net> References: <200208292343.50611.hpj@urpla.net> Message-ID: <200208300716.06457.boud@valdyas.org> On Thursday 29 August 2002 23:43, Hans-Peter Jansen wrote: > I couldn't resist from modifying its visual appearance slightly, and > delayed the timer interval to behave a bit more cooperative (unlike its > ancestor). > > Comments welcome! > Well, it seems to run without any glitch on my machine. I'm still using a fairly old version of PyQt, so I may not have the latests bugs... -- Boudewijn Rempt | http://www.valdyas.org From boud at valdyas.org Fri Aug 30 07:20:00 2002 From: boud at valdyas.org (Boudewijn Rempt) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] PyQt not refing slot methods - bug? In-Reply-To: <3D6E6FD3.8D002912@fa.disney.com> References: <3D6E6FD3.8D002912@fa.disney.com> Message-ID: <200208300719.18990.boud@valdyas.org> On Thursday 29 August 2002 21:02, Burley, Brent wrote: > > Is it a bug that PyQt isn't refing slot methods? Doesn't anyone use > lambdas for slots? > I don't think it's a bug -- it's certainly behaviour I would expect of PyQt, and no, I never use lambda's for slots. I feel a bit silly right now, because I can't think why using lambda is better than: import sys from qt import * def hello(): print 'hello' app = QApplication(sys.argv) b = QPushButton('hello', None) QObject.connect(b, SIGNAL('clicked()'), hello) app.setMainWidget(b) b.show() app.exec_loop() -- Boudewijn Rempt | http://www.valdyas.org From hpj at urpla.net Fri Aug 30 14:41:00 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Qt progress example with minor glitch In-Reply-To: <200208300716.06457.boud@valdyas.org> References: <200208292343.50611.hpj@urpla.net> <200208300716.06457.boud@valdyas.org> Message-ID: <200208301439.44067.hpj@urpla.net> On Friday 30 August 2002 07:16, Boudewijn Rempt wrote: > On Thursday 29 August 2002 23:43, Hans-Peter Jansen wrote: > > I couldn't resist from modifying its visual appearance slightly, and > > delayed the timer interval to behave a bit more cooperative (unlike its > > ancestor). > > > > Comments welcome! > > Well, it seems to run without any glitch on my machine. I'm still using a > fairly old version of PyQt, so I may not have the latests bugs... Hi Boudewijn, sure, that the AnimatedThingy is stopped properly on cancel? I left a print statement in _drawqix method as an indicator. if yes: would you do me a favour and comment out line 220/221: if not self.default_label: self.pb.killTimers() and check, if self.pb is stopped properly. This codepath is taken in timerDriven/customLabel mode only (default). The whole topic lead me to the question, how such custom dialogs are deconstructed properly? Also I forgot to mention in my former post, that QPainter.fillRect doesn't allow a QColor instance as 5th parameter, unlike Qt. One has always to wrap QColor with QBrush in PyQt. Phil? TIA, Hans-Peter From boud at valdyas.org Fri Aug 30 15:09:00 2002 From: boud at valdyas.org (Boudewijn Rempt) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Qt progress example with minor glitch In-Reply-To: <200208301439.44067.hpj@urpla.net> References: <200208292343.50611.hpj@urpla.net> <200208300716.06457.boud@valdyas.org> <200208301439.44067.hpj@urpla.net> Message-ID: <200208301508.38909.boud@valdyas.org> On Friday 30 August 2002 14:39, Hans-Peter Jansen wrote: > > sure, that the AnimatedThingy is stopped properly on cancel? > I left a print statement in _drawqix method as an indicator. No, the timer continues -- but I have never got the BadWindow message, and the dialog does disappear. > if yes: > would you do me a favour and comment out line 220/221: > if not self.default_label: > self.pb.killTimers() > and check, if self.pb is stopped properly. > This codepath is taken in timerDriven/customLabel mode only (default). > When I comment this out, it looks as if the timer restarts itself. > The whole topic lead me to the question, how such custom dialogs > are deconstructed properly? > Okay, I took a good long look at it. The first problem is in the show() method of the animated label -- this gets called when cancel is pressed. For the moment, don't ask me why, but it is, and it restarts your timer. Furthermore, when the dialog is deleted, the timers appear to be still running. Apparently, killTimers() doesn't descend into the dialog's children. So I kept a ref to the animated label and called killTimers() on it at the right place. See attached script. It kills that timer dead. As for the proper way to approach this problem -- I'm not sure. I think I would subclass QProgressDialog and have that handle the killing of the timer of the animated label. -- Boudewijn Rempt | http://www.valdyas.org -------------- next part -------------- A non-text attachment was scrubbed... Name: progress.py Type: text/x-python Size: 9384 bytes Desc: not available Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20020830/95f12e9b/progress.py From cjm at ava.com.au Fri Aug 30 16:07:01 2002 From: cjm at ava.com.au (Chris Munchenberg) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] FreeBSD build problems error 23512 Message-ID: <006001c2502e$99982d40$0100a8c0@server> Hi again Thanks for your help in fixing build.py/postproc so far. I can't say enough how much it is appreciated. I can now get build.py to complete successfully, but when I run make I get: #make cd dcop && "/usr/bin/make" -f Makefile [snip] cd kio && "/usr/bin/make" -f Makefile g++ -c -pipe -w -O2 -pthread -D_THREAD_SAFE -fPIC -DSIP_MAKE_MODULE_DLL -DQ T_NO_DEBUG -DQT_THREAD_SUPPO RT -fno-exceptions -I-I -I../extraH -I. -I/usr/local/include/python2.2 -I/us r/local/include -I-I -I/usr/ local/include/kio -I-I -I../kdecore -I/usr/local/include -I/usr/X11R6/includ e -I/usr/X11R6/mkspecs/defau lt -o kiohuge.o kiohuge.cpp sip/filesize_t.sip: In function `int sipConvertTo_kiofilesize_t(PyObject *, long long int **, int *)': sip/filesize_t.sip:54: implicit declaration of function `int atoll(...)' *** Error code 1 Stop in /usr/local/lib/python2.2/site-packages/PyKDE-3.3.2/kio. *** Error code 1 Stop in /usr/local/lib/python2.2/site-packages/PyKDE-3.3.2. I hope included the important information. Thanks in anticipation of your valuable input, Chris. From eli.carter at inet.com Fri Aug 30 16:31:00 2002 From: eli.carter at inet.com (Eli Carter) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] newbie: QFileDialog References: <3D6BE549.2080503@inet.com> <200208280718.49762.boud@valdyas.org> Message-ID: <3D6F817B.7050909@inet.com> Boudewijn Rempt wrote: > The easiest solution might be to use PyKDE's filedialog which should > provide most of this kind of behaviour. I think it would be hard to achieve > what you want by just subclassing the existing dialog, since most of the > file-system browsing code is private to the class. You might end up having to > write your own filedialog that looks like the standard one. For what I'm doing, I'd rather use QInputDialog.getText() than re-implement a file dialog. Call me lazy. ;) Thanks for the information on that! Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- From eli.carter at inet.com Fri Aug 30 16:36:00 2002 From: eli.carter at inet.com (Eli Carter) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Re: newbie: QFileDialog References: <20020828100001.27654.12351.Mailman@mats> <3D6CD1DA.A989B2B3@fluent.com> Message-ID: <3D6F82AB.80408@inet.com> Paul Felix wrote: >>From: Eli Carter [snip] >>I want to use QFileDialog to let a user pick files on a remote system, >>such as over an ftp connection. I'm not really sure where to start. I >>expect to subclass it, but I don't know what internals would need to be >>overridden, where to find that out, or if that is possible in pyqt. [snip] > I believe the answer is QUrlOperator. Try this: > > from qt import * > from qtnetwork import * > > qInitNetworkProtocols() > > op = QUrlOperator("ftp://ftp.trolltech.com") > > fd = QFileDialog() > fd.setUrl(op) > fd.exec_loop() Yeah, that looks like what I want. :) Particularly the ::copy() operator (http://doc.trolltech.com/2.3/qurloperator.html) and the fact that it can give a progress signal, which is something else I wanted to do but hadn't gotten to. Thanks for the excellent lead! :) Hrmm... RedHat 7.2 doesn't seem to have qtnetwork available, though Mandrake 8.2 does. I wonder if RH7.3 does... *mutter* Oh bother. Thanks again, Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- From polgardy at bodacion.com Fri Aug 30 16:38:01 2002 From: polgardy at bodacion.com (Frederick Polgardy Jr) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Quitting invokes crash handler In-Reply-To: <200208291138.41116.polgardy@bodacion.com> References: <200208291138.41116.polgardy@bodacion.com> Message-ID: <200208300937.14085.polgardy@bodacion.com> Jim, FYI, the corresponding PyQt code doesn't crash, even with 1-character variable names. ;-) Fred Relevant versions: KDE 3.0.3 Python 2.2.1 SIP/PyQT/PyKDE 3.3.2 Code snippet: import sys from qt import * class stuff(QMainWindow): def __init__(self, parent = None, name = None, fl = 0): QMainWindow.__init__(self, parent, name, fl) # create a status bar self.statusBar() # create the menubar fileMenu = QPopupMenu(self) quitAction = QAction("Quit", "&Quit", 0, self) QObject.connect(quitAction, SIGNAL("activated()"), self.fileQuit) quitAction.addTo(fileMenu) self.menuBar().insertItem("&File", fileMenu) def fileQuit(self): print "About to quit..." qApp.quit() if __name__ == "__main__": a = QApplication(sys.argv) w = stuff() QObject.connect(a, SIGNAL("lastWindowClosed()"), w.fileQuit) w.show() a.exec_loop() -- F R E D E R I C K P O L G A R D Y J R. Bodacion Technologies - A Virtual Media Company 18-3 E Dundee Road - Suite 300 - Barrington, IL 60010 Phone: 847/842.9008 - Fax: 847/842-1731 Web: http://www.bodacion.com From jbublitz at nwinternet.com Fri Aug 30 17:03:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] FreeBSD build problems error 23512 In-Reply-To: <006001c2502e$99982d40$0100a8c0@server> Message-ID: On 30-Aug-02 Chris Munchenberg wrote: > cd kio && "/usr/bin/make" -f Makefile > g++ -c -pipe -w -O2 -pthread -D_THREAD_SAFE -fPIC > -DSIP_MAKE_MODULE_DLL -DQT_NO_DEBUG -DQT_THREAD_SUPPORT > -fno-exceptions -I-I -I../extraH -I. > -I/usr/local/include/python2.2 -I/usr/local/include -I-I > -I/usr/local/include/kio -I-I -I../kdecore -I/usr/local/include > -I/usr/X11R6/include -I/usr/X11R6/mkspecs/default -o kiohuge.o > kiohuge.cpp > sip/filesize_t.sip: In function `int > sipConvertTo_kiofilesize_t(PyObject *, > long long int **, int *)': > sip/filesize_t.sip:54: implicit declaration of function `int > atoll(...)' > *** Error code 1 Quoting from an earlier post by Steve Simmons: """ To make a long story short, atoll() is coming into FreeBSD but isn't there yet. The source shows it to be a one-liner, so adding this to the appropriate kio module did the trick: inline kiofilesize_t atoll( char * s ) { return (kiofilesize_t) strtoll(s, (char **)NULL, 10); } """ From phil at river-bank.demon.co.uk Fri Aug 30 17:14:00 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Licensing issues References: <200208281812.19987.jgardn@alumni.washington.edu> Message-ID: <3D6F8BA9.20502@river-bank.demon.co.uk> Jonathan Gardner wrote: > It seems I made a serious mistake. > > The Red Hat RPMs list PyKDE, PyQt, and sip as GPL, as do some erroneous > websites. However, it seems like the license is more of a BSD or MIT license. > Looking on the Sourceforge site Jim Bublitz set up, he lists PyKDE as MIT. > > Oops. I listed sip, PyQt and PyKDE as GPL without really thinking too much of > it. > > I want to get a confirmation of PyKDE, PyQt, and sip all being MIT licensed. > If so, I will go and fix everything up. The current release of SIP and PyQt is MIT. The next release of both will be GPL. Phil From phil at river-bank.demon.co.uk Fri Aug 30 17:27:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Quitting invokes crash handler References: Message-ID: <3D6F8EA9.7090600@river-bank.demon.co.uk> Jim Bublitz wrote: > On 29-Aug-02 Frederick Polgardy Jr wrote: > >>Fascinating. If I add a 'w = None' after returning from >>a.exec_loop(), the crash problem goes away.... It's also >>interesting that this wasn't happening with Python 2.1.3 >>yesterday (the Debian packages for 2.2 were uploaded last >>night). >> > > >>Ideas? >> > > w = None works for me too, and is much better than restricting > KApplication variable names to three letters (I don't know why, but > that worked). A 'del w' (which is effectively the same) will work > also. > > The w = None is at least reasonable - it points to some problem > with 'w' (KMainWindow) needing to be destroyed before the 'exit' > code runs. Between that and the sensitivity to the length of a > variable name, it appears to be some sort of memory allocation or > pointer error - it could be a Python 2.2 problem also in that case. > > Once again, I'd love to fix this but have no idea where to begin. I haven't looked at the way you have implemented KApplication, but have a look at how I've implemented the QApplication dtor. You will need to do something similar - look at the comments at the start of PyQtDisownTopLevelWidgets(). Phil From phil at river-bank.demon.co.uk Fri Aug 30 17:32:00 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] PyQt not refing slot methods - bug? References: <3D6E6FD3.8D002912@fa.disney.com> Message-ID: <3D6F8FCD.5020301@river-bank.demon.co.uk> Burley, Brent wrote: > I was trying to use a lambda method as a slot method like this: > > import sys > from qt import * > def hello(): print 'hello' > app = QApplication(sys.argv) > b = QPushButton('hello', None) > QObject.connect(b, SIGNAL('clicked()'), lambda: hello()) > app.setMainWidget(b) > b.show() > app.exec_loop() > > > The lambda method never gets called. It appears that PyQt doesn't ref slot methods so the lambda method gets deleted before it can be used. If I change the code to keep a reference to the lambda, it works fine: > > l = lambda: hello() > QObject.connect(b, SIGNAL('clicked()'), l) > > > Is it a bug that PyQt isn't refing slot methods? Doesn't anyone use lambdas for slots? It's not a bug, it's designed that way so that you don't need to explicitly disconnect signals when you want to delete an object. Phil From phil at river-bank.demon.co.uk Fri Aug 30 17:39:00 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Qt progress example with minor glitch References: <200208292343.50611.hpj@urpla.net> <200208300716.06457.boud@valdyas.org> <200208301439.44067.hpj@urpla.net> Message-ID: <3D6F918F.5080701@river-bank.demon.co.uk> Hans-Peter Jansen wrote: > On Friday 30 August 2002 07:16, Boudewijn Rempt wrote: > >>On Thursday 29 August 2002 23:43, Hans-Peter Jansen wrote: >> >>>I couldn't resist from modifying its visual appearance slightly, and >>>delayed the timer interval to behave a bit more cooperative (unlike its >>>ancestor). >>> >>>Comments welcome! >>> >>Well, it seems to run without any glitch on my machine. I'm still using a >>fairly old version of PyQt, so I may not have the latests bugs... >> > > Hi Boudewijn, > > sure, that the AnimatedThingy is stopped properly on cancel? > I left a print statement in _drawqix method as an indicator. > if yes: > would you do me a favour and comment out line 220/221: > if not self.default_label: > self.pb.killTimers() > and check, if self.pb is stopped properly. > This codepath is taken in timerDriven/customLabel mode only (default). > > The whole topic lead me to the question, how such custom dialogs > are deconstructed properly? > > Also I forgot to mention in my former post, that QPainter.fillRect > doesn't allow a QColor instance as 5th parameter, unlike Qt. One has > always to wrap QColor with QBrush in PyQt. Phil? SIP generated code doesn't support the C++ feature of knowing it can call QBrush(QColor) when it needs a QBrush but is given a QColor. It's been on the TODO list for a long time - I may get around to it one day, but I think there are some "issues". Phil From eli.carter at inet.com Fri Aug 30 17:39:14 2002 From: eli.carter at inet.com (Eli Carter) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Licensing issues References: <200208281812.19987.jgardn@alumni.washington.edu> <3D6F8BA9.20502@river-bank.demon.co.uk> Message-ID: <3D6F914F.6060804@inet.com> Phil Thompson wrote: > Jonathan Gardner wrote: > >> It seems I made a serious mistake. >> >> The Red Hat RPMs list PyKDE, PyQt, and sip as GPL, as do some >> erroneous websites. However, it seems like the license is more of a >> BSD or MIT license. Looking on the Sourceforge site Jim Bublitz set >> up, he lists PyKDE as MIT. >> >> Oops. I listed sip, PyQt and PyKDE as GPL without really thinking too >> much of it. >> >> I want to get a confirmation of PyKDE, PyQt, and sip all being MIT >> licensed. If so, I will go and fix everything up. > > > The current release of SIP and PyQt is MIT. The next release of both > will be GPL. > > Phil No objection, but I was wondering what your reason for the change was? Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- From phil at river-bank.demon.co.uk Fri Aug 30 17:47:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Licensing issues References: <200208281812.19987.jgardn@alumni.washington.edu> <3D6F8BA9.20502@river-bank.demon.co.uk> <3D6F914F.6060804@inet.com> Message-ID: <3D6F9370.8090305@river-bank.demon.co.uk> Eli Carter wrote: > Phil Thompson wrote: > >> Jonathan Gardner wrote: >> >>> It seems I made a serious mistake. >>> >>> The Red Hat RPMs list PyKDE, PyQt, and sip as GPL, as do some >>> erroneous websites. However, it seems like the license is more of a >>> BSD or MIT license. Looking on the Sourceforge site Jim Bublitz set >>> up, he lists PyKDE as MIT. >>> >>> Oops. I listed sip, PyQt and PyKDE as GPL without really thinking too >>> much of it. >>> >>> I want to get a confirmation of PyKDE, PyQt, and sip all being MIT >>> licensed. If so, I will go and fix everything up. >> >> >> >> The current release of SIP and PyQt is MIT. The next release of both >> will be GPL. >> >> Phil > > > No objection, but I was wondering what your reason for the change was? To match Qt's licensing model - there will also be a commercial license. Phil From Brent.Burley at disney.com Fri Aug 30 17:52:01 2002 From: Brent.Burley at disney.com (Burley, Brent) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] PyQt not refing slot methods - bug? References: <3D6E6FD3.8D002912@fa.disney.com> <200208300719.18990.boud@valdyas.org> Message-ID: <3D6F9489.AFD36FCE@fa.disney.com> Boudewijn Rempt wrote: > On Thursday 29 August 2002 21:02, Burley, Brent wrote: > > Is it a bug that PyQt isn't refing slot methods? Doesn't anyone use > > lambdas for slots? > > I don't think it's a bug -- it's certainly behaviour I would expect of > PyQt, and no, I never use lambda's for slots. I feel a bit silly right now, > because I can't think why using lambda is better than: > > def hello(): print 'hello' > QObject.connect(b, SIGNAL('clicked()'), hello) I use lambda in a callback when I want to bind arguments to it. Consider: import sys from qt import * def buttonPressed(n): print 'button %d pressed' %n app = QApplication(sys.argv) box = QVBox() lambdaRefs = [] for i in range(1,11): b = QPushButton(str(i), box) l = lambda i=i: buttonPressed(i) lambdaRefs.append(l) # keep ref since Pyqt won't QObject.connect(b, SIGNAL('clicked()'), l) app.setMainWidget(box) box.show() app.exec_loop() If you don't use lambda, you either have to subclass the pushbutton or make a separate function object for each button. Lambda is often simpler. Note: if you were to use a function object, you would have the same problem as with the lambda in that you would have to hold the reference yourself. Lambdas are often used in Tkinter code for this purpose and Tkinter does in fact ref the lambda. Here's a page describing this: http://effbot.org/zone/tkinter-callbacks.htm Also, John Grayson discusses it and uses it extensively in "Python and Tkinter Programming". The fact that PyQt doesn't ref the slot method means that the common lambda/command object callback idiom does not work. This sort of behavior creates bugs that can be very difficult to find. [There's a similar behavior in Tkinter where setting an image on a label doesn't ref the image; this caused me a great deal of grief!] Given that the behavior of PyQt is as intended (and Phil's justification seems reasonable), and given that the use of lambdas (or command objects) is natural and common, especially for people coming from Tkinter, perhaps a note on the PyQt Signals and Slots page is warranted. Brent From polgardy at bodacion.com Fri Aug 30 17:58:01 2002 From: polgardy at bodacion.com (Frederick Polgardy Jr) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Quitting invokes crash handler In-Reply-To: <3D6F8EA9.7090600@river-bank.demon.co.uk> References: <3D6F8EA9.7090600@river-bank.demon.co.uk> Message-ID: <200208301056.24086.polgardy@bodacion.com> On Friday 30 August 2002 10:26 am, Phil Thompson wrote: > I haven't looked at the way you have implemented KApplication, but have > a look at how I've implemented the QApplication dtor. You will need to > do something similar - look at the comments at the start of > PyQtDisownTopLevelWidgets(). This is perfectly consistent with everything we've discovered so far: 1) Forcefully deleteing the main window before exiting fixes the problem 2) Changing the var names/lengths causes "unpredictable" behavior (i.e. since the order of keys in namespaces is undefined, a change in var name or length would affect whether the KApp gets destroyed before the main widget in Python) Good find. Fred -- F R E D E R I C K P O L G A R D Y J R. Bodacion Technologies - A Virtual Media Company 18-3 E Dundee Road - Suite 300 - Barrington, IL 60010 Phone: 847/842.9008 - Fax: 847/842-1731 Web: http://www.bodacion.com From jbublitz at nwinternet.com Fri Aug 30 18:31:00 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Quitting invokes crash handler In-Reply-To: <200208301056.24086.polgardy@bodacion.com> Message-ID: On 30-Aug-02 Frederick Polgardy Jr wrote: > On Friday 30 August 2002 10:26 am, Phil Thompson wrote: >> I haven't looked at the way you have implemented KApplication, >> but have a look at how I've implemented the QApplication dtor. >> You will need to do something similar - look at the comments >> at the start of PyQtDisownTopLevelWidgets(). > This is perfectly consistent with everything we've discovered so > far: > 1) Forcefully deleteing the main window before exiting fixes the > problem > 2) Changing the var names/lengths causes "unpredictable" behavior > (i.e. since the order of keys in namespaces is undefined, a > change in var name or length would affect whether the KApp gets > destroyed before the main widget in Python) Sounds reasonable to me - I'd expect the problem to be in that area. I'll check it out. Jim From scs at di.org Fri Aug 30 19:42:01 2002 From: scs at di.org (Steve Simmons) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] FreeBSD build problems error 23512 In-Reply-To: Message-ID: <20020830172940.GA29467@lokkur.dexter.mi.us> Jim Bublitz wrote: >Quoting from an earlier post by Steve Simmons: . . . >To make a long story short, atoll() is coming into FreeBSD but >isn't there yet. The source shows it to be a one-liner, so adding >this to the appropriate kio module did the trick: >inline kiofilesize_t atoll( char * s ) { return (kiofilesize_t) > strtoll(s, (char **)NULL, 10); } Sorry, I should have given a bit more detail when originally posting. After the atoll() error that Chris describes, I added the above inline definition at line 5493 to kio/kiohuge.cpp. Geez, I gotta take better notes. :-) It took 10 minutes to find where the change had been made. Please also note that adding the line there is a very shakey hack, not a long-term fix. I'm trying to figure out where the real fix goes, because (a) I strongly suspect that this line should *not* be applied when building on systems that already define atoll(), and (b) I think kiohuge.cpp gets built by other things so a new build will wipe out the fix. Over the weekend I'm going to try applying some test patches that Jim sent me and do a new build. We'll no doubt go back and forth a bit, but Chris, would you be willing to guinea pig the BSD port for me once we're ready? From hpj at urpla.net Fri Aug 30 19:44:00 2002 From: hpj at urpla.net (Hans-Peter Jansen) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Qt progress example with minor glitch In-Reply-To: <3D6F918F.5080701@river-bank.demon.co.uk> References: <200208292343.50611.hpj@urpla.net> <200208301439.44067.hpj@urpla.net> <3D6F918F.5080701@river-bank.demon.co.uk> Message-ID: <200208301942.54194.hpj@urpla.net> On Friday 30 August 2002 17:38, Phil Thompson wrote: > Hans-Peter Jansen wrote: > > > > Also I forgot to mention in my former post, that QPainter.fillRect > > doesn't allow a QColor instance as 5th parameter, unlike Qt. One has > > always to wrap QColor with QBrush in PyQt. Phil? > > SIP generated code doesn't support the C++ feature of knowing it can > call QBrush(QColor) when it needs a QBrush but is given a QColor. It's > been on the TODO list for a long time - I may get around to it one day, > but I think there are some "issues". > > Phil I see. BTW, how do you think about supporting pythons special methods? That is one of those things in the wxPython binding, I liked a lot. Look, how Robin got around this (with a patched SWIG, though...): class wxPointPtr : def __init__(self,this): self.this = this self.thisown = 0 def __del__(self,miscc=miscc): if self.thisown == 1 : miscc.delete_wxPoint(self) def Set(self, *_args, **_kwargs): val = apply(miscc.wxPoint_Set,(self,) + _args, _kwargs) return val def asTuple(self, *_args, **_kwargs): val = apply(miscc.wxPoint_asTuple,(self,) + _args, _kwargs) return val def __add__(self, *_args, **_kwargs): val = apply(miscc.wxPoint___add__,(self,) + _args, _kwargs) if val: val = wxPointPtr(val) ; val.thisown = 1 return val def __sub__(self, *_args, **_kwargs): val = apply(miscc.wxPoint___sub__,(self,) + _args, _kwargs) if val: val = wxPointPtr(val) ; val.thisown = 1 return val def __cmp__(self, *_args, **_kwargs): val = apply(miscc.wxPoint___cmp__,(self,) + _args, _kwargs) return val def __setattr__(self,name,value): if name == "x" : miscc.wxPoint_x_set(self,value) return if name == "y" : miscc.wxPoint_y_set(self,value) return self.__dict__[name] = value def __getattr__(self,name): if name == "x" :? return miscc.wxPoint_x_get(self) if name == "y" :? return miscc.wxPoint_y_get(self) raise AttributeError,name def __repr__(self): return "" % (self.this,) def __str__(self): return str(self.asTuple()) def __repr__(self): return str(self.asTuple()) def __len__(self): return len(self.asTuple()) def __getitem__(self, index): return self.asTuple()[index] def __setitem__(self, index, val): if index == 0: self.x = val elif index == 1: self.y = val else: raise IndexError class wxPoint(wxPointPtr): def __init__(self,*_args,**_kwargs): self.this = apply(miscc.new_wxPoint,_args,_kwargs) self.thisown = 1 Here is the corresponding SWIG source: class wxPoint { public: long x; long y; wxPoint(long x=0, long y=0); ~wxPoint(); %addmethods { void Set(long x, long y) { self->x = x; self->y = y; } PyObject* asTuple() { PyObject* tup = PyTuple_New(2); PyTuple_SET_ITEM(tup, 0, PyInt_FromLong(self->x)); PyTuple_SET_ITEM(tup, 1, PyInt_FromLong(self->y)); return tup; } wxPoint __add__(const wxPoint* p) { if (! p) return *self; return *self + *p; } wxPoint __sub__(const wxPoint* p) { if (! p) return *self; return *self - *p; } int __cmp__(const wxPoint* p) { if (! p) return 1; if (*self == *p) return 0; return -1; } } %pragma(python) addtoclass = " def __str__(self): return str(self.asTuple()) def __repr__(self): return str(self.asTuple()) def __len__(self): return len(self.asTuple()) def __getitem__(self, index): return self.asTuple()[index] def __setitem__(self, index, val): if index == 0: self.x = val elif index == 1: self.y = val else: raise IndexError " }; Are there any concerns besides missing time not to take this route to get more pythonic one day? Hans-Peter From phil at river-bank.demon.co.uk Fri Aug 30 20:35:01 2002 From: phil at river-bank.demon.co.uk (Phil Thompson) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Qt progress example with minor glitch References: <200208292343.50611.hpj@urpla.net> <200208301439.44067.hpj@urpla.net> <3D6F918F.5080701@river-bank.demon.co.uk> <200208301942.54194.hpj@urpla.net> Message-ID: <3D6FBAAC.4000800@river-bank.demon.co.uk> Hans-Peter Jansen wrote: > On Friday 30 August 2002 17:38, Phil Thompson wrote: > >>Hans-Peter Jansen wrote: >> >>>Also I forgot to mention in my former post, that QPainter.fillRect >>>doesn't allow a QColor instance as 5th parameter, unlike Qt. One has >>>always to wrap QColor with QBrush in PyQt. Phil? >>> >>SIP generated code doesn't support the C++ feature of knowing it can >>call QBrush(QColor) when it needs a QBrush but is given a QColor. It's >>been on the TODO list for a long time - I may get around to it one day, >>but I think there are some "issues". >> >>Phil >> > > I see. BTW, how do you think about supporting pythons special methods? > That is one of those things in the wxPython binding, I liked a lot. > Look, how Robin got around this (with a patched SWIG, though...): > > class wxPointPtr : > def __init__(self,this): > self.this = this > self.thisown = 0 > def __del__(self,miscc=miscc): > if self.thisown == 1 : > miscc.delete_wxPoint(self) > def Set(self, *_args, **_kwargs): > val = apply(miscc.wxPoint_Set,(self,) + _args, _kwargs) > return val > def asTuple(self, *_args, **_kwargs): > val = apply(miscc.wxPoint_asTuple,(self,) + _args, _kwargs) > return val > def __add__(self, *_args, **_kwargs): > val = apply(miscc.wxPoint___add__,(self,) + _args, _kwargs) > if val: val = wxPointPtr(val) ; val.thisown = 1 > return val > def __sub__(self, *_args, **_kwargs): > val = apply(miscc.wxPoint___sub__,(self,) + _args, _kwargs) > if val: val = wxPointPtr(val) ; val.thisown = 1 > return val > def __cmp__(self, *_args, **_kwargs): > val = apply(miscc.wxPoint___cmp__,(self,) + _args, _kwargs) > return val > def __setattr__(self,name,value): > if name == "x" : > miscc.wxPoint_x_set(self,value) > return > if name == "y" : > miscc.wxPoint_y_set(self,value) > return > self.__dict__[name] = value > def __getattr__(self,name): > if name == "x" :? > return miscc.wxPoint_x_get(self) > if name == "y" :? > return miscc.wxPoint_y_get(self) > raise AttributeError,name > def __repr__(self): > return "" % (self.this,) > > def __str__(self): return str(self.asTuple()) > def __repr__(self): return str(self.asTuple()) > def __len__(self): return len(self.asTuple()) > def __getitem__(self, index): return self.asTuple()[index] > def __setitem__(self, index, val): > if index == 0: self.x = val > elif index == 1: self.y = val > else: raise IndexError > > class wxPoint(wxPointPtr): > def __init__(self,*_args,**_kwargs): > self.this = apply(miscc.new_wxPoint,_args,_kwargs) > self.thisown = 1 > > Here is the corresponding SWIG source: > > class wxPoint { > public: > long x; > long y; > wxPoint(long x=0, long y=0); > ~wxPoint(); > > %addmethods { > void Set(long x, long y) { > self->x = x; > self->y = y; > } > PyObject* asTuple() { > PyObject* tup = PyTuple_New(2); > PyTuple_SET_ITEM(tup, 0, PyInt_FromLong(self->x)); > PyTuple_SET_ITEM(tup, 1, PyInt_FromLong(self->y)); > return tup; > } > > wxPoint __add__(const wxPoint* p) { > if (! p) return *self; > return *self + *p; > } > > wxPoint __sub__(const wxPoint* p) { > if (! p) return *self; > return *self - *p; > } > > int __cmp__(const wxPoint* p) { > if (! p) return 1; > if (*self == *p) return 0; > return -1; > } > } > %pragma(python) addtoclass = " > def __str__(self): return str(self.asTuple()) > def __repr__(self): return str(self.asTuple()) > def __len__(self): return len(self.asTuple()) > def __getitem__(self, index): return self.asTuple()[index] > def __setitem__(self, index, val): > if index == 0: self.x = val > elif index == 1: self.y = val > else: raise IndexError > " > }; > > Are there any concerns besides missing time not to take this route > to get more pythonic one day? SIP already supports them and they have been implemented in PyQt where a class would be useless without them - see QStringList. They could be exploited much more in PyQt than they are - I've just never got around to it. Phil From gordon at doxxx.net Fri Aug 30 20:51:00 2002 From: gordon at doxxx.net (Gordon Tyler) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Quitting invokes crash handler References: Message-ID: <3D6FBE6F.90808@doxxx.net> Jim Bublitz wrote: > On 29-Aug-02 Gordon Tyler wrote: > >>Frederick Polgardy Jr wrote: >> >>> a.connect(a, SIGNAL("lastWindowClosed()"), w.fileQuit) >> > > >>I would write the above line like this (wordwrapped for reading): > > >> a.connect(a, SIGNAL("lastWindowClosed()"), >> KApplication.kApplication(), SLOT("quit()")) > > > The original line is both correct and different in function from > your suggested rewrite. 'w.fileQuit' might actually do something > useful (like save files, cleanup, etc) in a real program. But wouldn't that connection be referring to a slot on an instance that no longer exists? w is the only window, when it is closed, the lastWindowClosed signal is fired, but the instance that it connects to is gone. Or am I misunderstanding the lifecycle of the w instance? Ciao, Gordon From jbublitz at nwinternet.com Fri Aug 30 21:32:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Quitting invokes crash handler In-Reply-To: <200208301056.24086.polgardy@bodacion.com> Message-ID: On 30-Aug-02 Frederick Polgardy Jr wrote: > On Friday 30 August 2002 10:26 am, Phil Thompson wrote: >> I haven't looked at the way you have implemented KApplication, >> but have a look at how I've implemented the QApplication dtor. >> You will need to do something similar - look at the comments >> at the start of PyQtDisownTopLevelWidgets(). > This is perfectly consistent with everything we've discovered so > far: > 1) Forcefully deleteing the main window before exiting fixes the > problem > 2) Changing the var names/lengths causes "unpredictable" behavior > (i.e. since the order of keys in namespaces is undefined, a > change in var name or length would affect whether the KApp gets > destroyed before the main widget in Python) Yep - that fixes it. Somewhere in the KApplication class (public section) add: ~KApplication(); %MemberCode PyQtDisownTopLevelWidgets(); %End Jim From jbublitz at nwinternet.com Fri Aug 30 22:01:01 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] FreeBSD build problems error 23512 In-Reply-To: <20020830172940.GA29467@lokkur.dexter.mi.us> Message-ID: On 30-Aug-02 Steve Simmons wrote: > Jim Bublitz wrote: >>Quoting from an earlier post by Steve Simmons: >>To make a long story short, atoll() is coming into FreeBSD but >>isn't there yet. The source shows it to be a one-liner, so >>adding this to the appropriate kio module did the trick: >>inline kiofilesize_t atoll( char * s ) { return (kiofilesize_t) >> strtoll(s, (char **)NULL, 10); } > Sorry, I should have given a bit more detail when originally > posting. After the atoll() error that Chris describes, I added > the above inline definition at line 5493 to kio/kiohuge.cpp. > Geez, I gotta take better notes. :-) It took 10 minutes to > find where the change had been made. > Please also note that adding the line there is a very shakey > hack, not a long-term fix. I'm trying to figure out where the > real fix goes, because (a) I strongly suspect that this line > should *not* be applied when building on systems that already > define atoll(), and (b) I think kiohuge.cpp gets built by other > things so a new build will wipe out the fix. kiohuge.cpp is (re)created by build.py on each run by concatenating together all of the the cpp files that sip creates, but *only* if the -c switch is used, so it isn't guaranteed to exist. The patch should probably go into filesize_t.sip. 'atoll' is called in the "%ConvertToTypeCode" block, and everything within that block is C++ code, so something in that block like: #ifdef no_atoll #define atoll(s) strtoll(s, (char **)NULL, 10) You can probably work out a way to #define no_atoll automatically in build.py by doing a test compile of a short program (see how -fno_exception is tested for). Let me know if you want me to throw something together - I don't have any way to test the FreeBSD performance of it though. Actually, it shouldn't be that hard, so I'll just go ahead and do it. In the meantime, why don't you stick the #define above in filesize_t.sip and see if it works. It'll take me a few days to modify build.py, and I'm at the point where I might as well throw a new release together (other build.py fixes, ~KApplication) - I'll wait until you've tested the build.py patches (no root stuff) before doing the release, so let me know on that and the #define above. Jim From jbublitz at nwinternet.com Fri Aug 30 22:01:24 2002 From: jbublitz at nwinternet.com (Jim Bublitz) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Quitting invokes crash handler In-Reply-To: <3D6FBE6F.90808@doxxx.net> Message-ID: On 30-Aug-02 Gordon Tyler wrote: > Jim Bublitz wrote: >> On 29-Aug-02 Gordon Tyler wrote: >>>Frederick Polgardy Jr wrote: >>>> a.connect(a, SIGNAL("lastWindowClosed()"), w.fileQuit) >>>I would write the above line like this (wordwrapped for >>>reading): >>> a.connect(a, SIGNAL("lastWindowClosed()"), >>> KApplication.kApplication(), SLOT("quit()")) >> The original line is both correct and different in function from >> your suggested rewrite. 'w.fileQuit' might actually do something >> useful (like save files, cleanup, etc) in a real program. > But wouldn't that connection be referring to a slot on an > instance that no longer exists? w is the only window, when it > is closed, the lastWindowClosed signal is fired, but the > instance that it connects to is gone. Or am I misunderstanding > the lifecycle of the w instance? I see your point and don't actually know the answer - that's another reason I'd opt for the 'queryClose' and 'queryExit' functions that are part of the KMainWindow class. I have seen the idiom above used in a number of places and it generally seems to work (it works when PyKDE is fixed by adding the KApplication dtor referenced in another post). It depends a lot on what 'lastWindowClosed' actually means (I haven't looked) and also on whether 'w' being closed (or removed from the app's widget list) == 'w' being destroyed - the two aren't necessarily the same. For example, 'dialog closed' != 'dialog destroyed'. Jim From gordon at doxxx.net Fri Aug 30 22:12:00 2002 From: gordon at doxxx.net (Gordon Tyler) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] Quitting invokes crash handler References: Message-ID: <3D6FD15A.70906@doxxx.net> Jim Bublitz wrote: > On 30-Aug-02 Gordon Tyler wrote: >>Jim Bublitz wrote: >>>On 29-Aug-02 Gordon Tyler wrote: >>>>Frederick Polgardy Jr wrote: >>>>> a.connect(a, SIGNAL("lastWindowClosed()"), w.fileQuit) >>>> >>>>I would write the above line like this (wordwrapped for >>>>reading): >>> >>>> a.connect(a, SIGNAL("lastWindowClosed()"), >>>> KApplication.kApplication(), SLOT("quit()")) >>> >>>The original line is both correct and different in function from >>>your suggested rewrite. 'w.fileQuit' might actually do something >>>useful (like save files, cleanup, etc) in a real program. >> >>But wouldn't that connection be referring to a slot on an >>instance that no longer exists? w is the only window, when it >>is closed, the lastWindowClosed signal is fired, but the >>instance that it connects to is gone. Or am I misunderstanding >>the lifecycle of the w instance? > > I see your point and don't actually know the answer - that's > another reason I'd opt for the 'queryClose' and 'queryExit' > functions that are part of the KMainWindow class. I agree. Those are more suitable for doing per-window cleanup or close verification. A fileClose slot that is normally connected to a menu item shouldn't do anything more than invoke self.close() because anything else that it does will not be executed if the user closes the window using the titlebar X button or if the system is shutting the app down because the user is logging out. The way I see it, KApplication::lastWindowClosed is a way of stopping the application event loop when the last window is closed. If necessary, a subclass of KApplication should be created with a custom slot like "shutdownApplication()" to which lastWindowClosed is connected that does global _application_ shutdown stuff and calls KApplication::quit(). > I have seen the idiom above used in a number of places and it > generally seems to work (it works when PyKDE is fixed by adding the > KApplication dtor referenced in another post). It depends a lot on > what 'lastWindowClosed' actually means (I haven't looked) and also > on whether 'w' being closed (or removed from the app's widget > list) == 'w' being destroyed - the two aren't necessarily the same. > For example, 'dialog closed' != 'dialog destroyed'. Which is why I think it's a bad idiom, and a bad habit to teach new (Py)KDE coders. Ciao, Gordon From doug101 at xecu.net Sat Aug 31 03:09:01 2002 From: doug101 at xecu.net (Doug Bell) Date: Thu Mar 8 10:26:45 2007 Subject: [PyKDE] RedHat Text Display Issue Message-ID: <20020831010835.GA2817@dougbell.xecu.net> Two users of my TreeLine program have had problems with the display of text in text edit and list view widgets. Both are using RedHat 7.3. Here's the description from one of the users: Yes the program is running, and appears to do everything properly, but the text is messed up. Between every letter there is the outline of a square box. Some sort of place holder I presume. The program does see these artifacts as actual letters. If, for example, you type in the word Tree, it looks fine as you type it. When you click to accept, the letters become separated by the squares and the string length remains at 4. The last 2 letters are lost. Many others have used my program without seeing this issue. My program uses unicode, including the strategy from Boudewijn Rempt's book of saving the sys.setdefaultencoding in sitecustomize.py and setting the encoding to utf-8. If anyone wants to test the program, it can be found at . Any ideas? Doug.