[PyKDE] installing PyQt
Hi, I'd like to perform GUI's with PyQt and I unfortunately have to use the obsolete redhat 7.1. I can see that the new releases of SIP PyQt (3.5)are available. Could anyone describe the installation I have to do (softwares, versions...), and the environment variables I have to setplease ? With redhat 7.1 there is qt-2.3.0, should I have to remove it ? Thanks a lot, best regards, François CORRIHONSApside Technologies58, avenue du Général Leclerc92100 Boulogne-BillancourtGSM: 06.75.24.73.51[EMAIL PROTECTED]http://www.apside.fr
Re: [PyKDE] Seperate Qscintilla from PyQt
On Wed, Dec 11, 2002 at 11:18:50PM -0800, Jim Bublitz wrote: My concern with splitting the packages is the possible creation of dependency problems for third-party developers - eg those people using PyQt of PyKDE to develop their packages. They should be able to count on a basic integral PyQt or PyKDE when distributing *their* packages. I'd prefer to avoid a situation similar to libc (hypothetically) making the socket functions optional. An app like eric may not have problems, but database apps (or even apps that peripherally use databases) will certainly expect qtsql, and apps that include 3D might expect qtgl. Similar dependencies might exist with PyKDE. I was going to include extra information about the packages layout in their description, but probably I should at least be consistent with the logical layout of the other components on Debian, i.e.: if Debian's Qt comes with SQL and OpenGL in the same package (currently, it's that way, in the past we had a separate package for -gl), then there's no real gain excluding them from PyQt's one. The same comes for PyKDE, of course. Anyway, I'm getting Qt extensions in a separate package, as even if they come as an option at PyQt package, they depend on elements out of Qt, and would depend and force to install extra element (QScintilla libs, in this case). Thanks Jim. ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] Sharp Zaurus support
I'm considering putting together a PyQt based app for the Sharp Zaurus and would like to know what kind of success people have had. Is the Zaurus version of PyQt based on Qt 3.x or on one of the Qt 2.x series? Is the Zaurus version trimmed down in any way or do I get all the features that I would have available to a desktop app? From reading the Qtopia info on trolltech, it appears that Qt Embedded should support all the functionality of the main Qt library, but I still don't see anywhere explaining what version QtE is based on... Thanks for any info. Greg ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Sharp Zaurus support
On Thursday 12 December 2002 3:08 pm, Greg Fortune wrote: I'm considering putting together a PyQt based app for the Sharp Zaurus and would like to know what kind of success people have had. Is the Zaurus version of PyQt based on Qt 3.x or on one of the Qt 2.x series? Is the Zaurus version trimmed down in any way or do I get all the features that I would have available to a desktop app? From reading the Qtopia info on trolltech, it appears that Qt Embedded should support all the functionality of the main Qt library, but I still don't see anywhere explaining what version QtE is based on... Thanks for any info. The version of Qt is 2.3.3. However, a hardware vendor can fine tune the configuration any number of ways. The following is a list of disabled features on the Zaurus... QT_NO_CODECS QT_NO_COLORDIALOG QT_NO_DIAL QT_NO_DOM QT_NO_DRAGANDDROP QT_NO_IMAGE_TEXT QT_NO_INPUTDIALOG QT_NO_FILEDIALOG QT_NO_FONTDIALOG QT_NO_MIMECLIPBOARD QT_NO_NETWORKPROTOCOL QT_NO_PICTURE QT_NO_PRINTDIALOG QT_NO_PRINTER QT_NO_PROGRESSDIALOG QT_NO_PROPERTIES QT_NO_SEMIMODAL QT_NO_SIZEGRIP QT_NO_SPLITTER QT_NO_STYLE_CDE QT_NO_STYLE_INTERLACE QT_NO_STYLE_MOTIF QT_NO_STYLE_MOTIFPLUS QT_NO_STYLE_PLATINUM QT_NO_STYLE_SGI QT_NO_TRANSFORMATIONS QT_NO_WIZARD QT_NO_WORKSPACE QT_NO_THREAD_SUPPORT The only way to know how the detail of how each of these affects Qt is to look at the source - but most refer to whole classes so it's not too difficult to work out. Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Sharp Zaurus support
Greg Fortune [EMAIL PROTECTED] writes: I'm considering putting together a PyQt based app for the Sharp Zaurus and would like to know what kind of success people have had. Is the Zaurus version of PyQt based on Qt 3.x or on one of the Qt 2.x series? Is the The Zaurus has Qt/Embedded 2.3.2, with some limits on functionality. PyQt being just a wrapper around Qt, it doesn't lift those restrictions. I don't know if there is a list of restrictions somewhere. Here are the ones I discovered while porting code: - The QSplitter object does not exist. - QColor doesn't take string arguments, you have to specify a colour by RGB or use one of the predefined color objects. Another incompatibility I discovered is that QWidget.setBackgroundColor has no effect, at least for a plain widget. You have to paint the background yourself. All these are limitations due to Qt, so they apply no matter what tools you use for Zaurus programming. I haven't run into anything limitation due to Python or PyQt yet. It's rather the opposite: it is much easier to work with Python on the Zaurus as you can modify the code right on the Zaurus without having to worry about compilation. In fact, I developed substantial parts of code on the train. And speed is perfectly sufficient if you don't do number crunching. In summary, Python+PyQt is the best handheld programming system I have seen until now. Of course, as a longtime Python fan I might be biased ;-) Konrad. ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Sharp Zaurus support
On Thursday 12 December 2002 3:48 pm, Greg Fortune wrote: The version of Qt is 2.3.3. However, a hardware vendor can fine tune the configuration any number of ways. The following is a list of disabled features on the Zaurus... Bummer, but that's exactly what I needed to know. QT_NO_CODECS QT_NO_COLORDIALOG QT_NO_DIAL QT_NO_DOM QT_NO_DRAGANDDROP QT_NO_IMAGE_TEXT QT_NO_INPUTDIALOG QT_NO_FILEDIALOG QT_NO_FONTDIALOG QT_NO_MIMECLIPBOARD QT_NO_NETWORKPROTOCOL QT_NO_PICTURE QT_NO_PRINTDIALOG QT_NO_PRINTER QT_NO_PROGRESSDIALOG QT_NO_PROPERTIES QT_NO_SEMIMODAL QT_NO_SIZEGRIP QT_NO_SPLITTER QT_NO_STYLE_CDE QT_NO_STYLE_INTERLACE QT_NO_STYLE_MOTIF QT_NO_STYLE_MOTIFPLUS QT_NO_STYLE_PLATINUM QT_NO_STYLE_SGI QT_NO_TRANSFORMATIONS QT_NO_WIZARD QT_NO_WORKSPACE QT_NO_THREAD_SUPPORT I assume I could recompile Qtopia to re-enable any of these features I need, right? You are confusing Qt/Embedded with Qtopia. I don't know if you can compile your own Qt/Embedded as it would require knowledge of the Zaurus hardware. Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Sharp Zaurus support
Am Don, 2002-12-12 um 16.48 schrieb Greg Fortune: I assume I could recompile Qtopia to re-enable any of these features I need, right? You can recompile Qt/Embedded with less disabled features, however you will lose binary compatibility with stock Zaurii, of course. If you really really need a missing feature then it would be better to refactor this feature into a seperate library and enhance the PyQt build process to support this. If you want to go this way, let's join forces - I'd be interested. Cheers, -- :M: -- Dipl.-Inf. Michael 'Mickey' Lauer [EMAIL PROTECTED] Raum 10b - ++49 69 798 28358 Fachbereich Informatik und Biologie -- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] installing PyQt
On Thu, 12 Dec 2002 11:41:09 +0100, =?iso-8859-1?Q?Fran=E7ois_CORRIHONS?= [EMAIL PROTECTED] said: This is a multi-part message in MIME format. --Boundary_(ID_oPBOk6lYlJF2BOkJpVXeWA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Hi, I'd like to perform GUI's with PyQt and I unfortunately have to use the obsolete redhat 7.1. I can see that the new releases of SIP PyQt (3.5) are available. Could anyone describe the installation I have to do (softwares, versions...), and the environment variables I have to set please ? With redhat 7.1 there is qt-2.3.0, should I have to remove it ? No, just install Qt-3.1.0 in /usr/local. Then install sip, and finally PyQt. Follow the instructions in the INSTALL and/or README file for each package. ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Sharp Zaurus support
On Thursday 12 December 2002 10:50 am, Michael Lauer wrote: Am Don, 2002-12-12 um 19.45 schrieb Greg Fortune: snip I assume I could recompile Qtopia to re-enable any of these features I need, right? You are confusing Qt/Embedded with Qtopia. I don't know if you can compile your own Qt/Embedded as it would require knowledge of the Zaurus hardware. Perhaps Sharp provides something like a makefile for their platform. Luckily this is not needed. Qt/Embedded comes with all the necessary configurations. Simply configure Qt/Embedded with ./configure -xplatform linux-sharp-g++ and you're set. Note that you need a cross compilation environment. Cool :) Now all I need to do is spring the $430 for a Zaurus and a wireless card and I'm good to go. I just wish the price would drop a little. I'm about to give up and just order one :) Thanks for the help, Greg ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Sharp Zaurus support
Greg Fortune wrote: [snip] Cool :) Now all I need to do is spring the $430 for a Zaurus and a wireless card and I'm good to go. I just wish the price would drop a little. I'm about to give up and just order one :) Thanks for the help, Greg Greg, keep an eye on http://froogle.google.com/froogle?q=sharp+zaurusprice1=price2=375price=betweenbtnP=Go and http://froogle.google.com/froogle?q=cf+wirelessprice1=price2=70price=betweenbtnP=Go -- Tom Jenkins Development InfoStructure http://www.devis.com ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] PyKDE
Is PyKDE being maintained? I'd be interested if a KDE 3.1 version is under development, as I'd like to try to integrate PyKDE/QT into KDevelop 3.0 (Gideon). In my (humble, obviously) opinion, Python as a scripting language could be as important to Unix/Linux as VB was to Windows (and I mean that as a good thing...) Have there ever been discussions about whether to release PyKDE/QT with KDE's kdebindings package? cheers Julian ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] PyKDE
On Fri, 13 Dec 2002 11:14 am, Julian Rockey wrote: Is PyKDE being maintained? I'd be interested if a KDE 3.1 version is under development, as I'd like to try to integrate PyKDE/QT into KDevelop 3.0 (Gideon). That'll probably happen once 3.1 is actually released :) Have there ever been discussions about whether to release PyKDE/QT with KDE's kdebindings package? Yes - http://mats.gmd.de/pipermail/pykde/2002-August/003444.html Richard ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] ANN: SIP/PyQt v3.5 QScintilla v0.3 Released
On Friday 13 December 2002 12:00 am, Michael Lauer wrote: Phil, congratulations for this new release! I'm especially happy that the enhanced Qtopia support has made it into this release. One thing though (ya' know, some folks just can't get enough :)): Could you give me a hint how to wrap QCopEnvelope? I need it for our project since calling /opt/QtPalmtop/bin/qcop is way to slow. The issue came up on this list, once, and IIRC the problem was the support for the operator which QCopEnvelope relies on. Would it be difficult to implement QCopEnvelope using a simple class method, e.g. QCopEnvelope.post instead of the operator? There shouldn't be any problem implementing the operator by providing an __lshift__ method in the same way that __iadd__ is implemented for QSemaphore. Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] PyKDE
On 13-Dec-02 Julian Rockey wrote: Is PyKDE being maintained? I'd be interested if a KDE 3.1 version is under development, as I'd like to try to integrate PyKDE/QT into KDevelop 3.0 (Gideon). You must be new here - people familiar with the list know better than to ask that question, because it always leads to a long, boring explanation (see below) In my (humble, obviously) opinion, Python as a scripting language could be as important to Unix/Linux as VB was to Windows (and I mean that as a good thing...) Have there ever been discussions about whether to release PyKDE/QT with KDE's kdebindings package? Long, Boring Explanation (I actually answer your questions somewhere near the end) PyKDE is indeed still being maintained. There won't be a new release until after KDE3.1 final is released. Here's a status update, a really long, boring explanation: For some time the sip files which sip uses to generate PyKDE have been generated automatically via a very poorly written program that produced a lot of errors on output, but still saved a immense number of hours. About a month ago, I started rewriting that program, and it is now a nice modular, actually debuggable, semi-documented tool. At the moment, it will automatically generate (except for some handwritten code) a complete set of sip files (which means a complete set of bindings more or less) from a set of h files for a lib. It has a few bugs, but nothing major that I'm aware of. However, to be useful for PyKDE, the program has to be able to do versioning - ie take a set of sip files from the previous release and mix in the h files from the current KDE release to produce a set of sip files that supports the current and all previous KDE releases (PyKDE for KDE 2.1.1-3.1 consists of a single set of sip files, just like PyQt does for its set of Qt versions/platforms). For reasons that would take even longer to explain, it makes sense to rebuild PyKDE from 2.1.1 forward. If the tool works, this isn't as bad as it sounds - once I get the first version (2.1.1) working, each additional version should really only take about half a day, especially with compile times as fast as they are now, and having built everything through 3.0.4 once already. So the point I'm at now is I have a set of sip files generated for KDE 2.1.1. I need to clean those up (mostly handwrite some code - actually cut and paste handwritten code from PyKDE-3.3.2) to get a buildable PyKDE for KDE 2.1.1 (about 2/3 done). Next I need to finish up the versioning code of the generator program, so that I can produce more or less automatically KDE 2.1.2 ... KDE 3.1. The time frame to complete that is a few weeks. I was shooting for before the holidays, but it now looks like perhaps just after the holidays. One big help will be that Phil just released sip/PyQt 3.5, so for once the KDE release will be after the last sip/PyQt update - in the past it has made sense to wait for the sip/PyQt release before releasing a new PyKDE. There is kind of a master plan to all this (subject to very much drastic change) that fits very well with your question about KDevelop and comparison to VB. I agree completely that Python + bindings could be far superior to VB for KDE in particular and Linux/BSD in general. My goals (in chronological order) are: Step 1. Release PyKDE for KDE 3.0.5 and KDE 3.1 - as soon after the 3.1 final release as possible. Step 2. Clean up my sip file generator program, document it, document sip generally as much as possible (probably update Wilken's docs if he doesn't mind and perhaps add a tutorial). Every few weeks someone posts to c.l.p asking about generating bindings for some lib or other (the last was a few days ago for OpenH323). There is at the moment no easy way to generate bindings (unless you're familiar with sip, which at present is largely undocumented, although a dream to use once you become familiar with it). The basic idea is that if you have a lib/set of h files to bind, you can write a short, simple project description file and the sip file generator will automatically produce a set of sip files which can be submitted to sip to generate the actual bindings. The generator will also produce all the ancilliary files: build.py, Makefiles, docs (in the current PyQt/PyKDE style) - everything except a small amount of handwritten code (which should be covered exhaustively in a tutorial or HOW-TO). If when this is working the people doing packaging can see a way to add scripts to generate RPMs and deb files, that would make it nearly perfect (except for all the bugs I've probably coded in already). Target date is late Q1/early Q2 (lots of docs to write). Note that if this works, future PyKDE releases should be achieveable in a few days after a KDE release. (2) now means that any C/C++ libs can be bound for Python - in theory it should be able to generate bindings for any KDE lib (not just the basic libs as now - arts, games, whatever), or even
