[PyKDE] Non-working Red Hat 7.3 RPMs
I have finally discovered what went wrong with the Red Hat 7.3 RPMs. Apparently, I was including old libraries (like libsip.so.9.1.0) instead of the newer ones. As I am still new at this, forgive me. I will have the new RPMs uploaded in a few hours. I am also running up2date on my system, to incorporate all of the changes to Red Hat's KDE due to the recent security flaws. If you plan on using my RPMs, it may be wise to do the same. -- Jonathan Gardner [EMAIL PROTECTED] ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] License + new release soon? :$
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 06 December 2002 05:05 pm, Bart Verwilst wrote: > On Saturday 07 December 2002 00:43, Kaleb Pederson wrote: > || -BEGIN PGP SIGNED MESSAGE- > || Hash: SHA1 > || > || As a note, I would love to see that done as well, or at least an option > || that can be specified on the command line. I'm a gentoo user and would > || like to see that. > || > || Of course, you can just get around it by doing a simple: > || > || $ echo "yes" | python build.py > || > || But it is better not to. > || > || Bart, do you have any interesting in building ebuilds for the > || snapshots? As I do most of my development using PyQt, I have had to > || build my own for the snapshots. Are these of any interest to you? Also, > || now that eric is a distinct package, I presume we will see an ebuild for > || it here upon the next release? I'll willing to help in these areas. > > Do you have your own eric ebuild already? > Otherwise, it would be great if you could send it to me, saves me some work > :p I'll make sure eric becomes a part of Portage, rest assured :o) I haven't built my own as I finally got around to getting the latest snapshots (through ebuilds) of SIP and PyQt up and running today. If I happen to build one over the next couple days, I'll be sure to send it to you. My PyQt snapshot ebuild does correctly remove the eric stuff though, as that was necessary to get it to install correctly (a fairly trivial modification). - --Kaleb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE98VFreAVt8Tl/2kURArbHAJ9m61m+SZ0Ln7JUMfO12Lv2begt5ACgxFVq QLNsrBZkcsJN8tvriORJN5E= =PDZg -END PGP SIGNATURE- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] License + new release soon? :$
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 06 December 2002 05:04 pm, Bart Verwilst wrote: > On Saturday 07 December 2002 01:30, Phil Thompson wrote: > || On Friday 06 December 2002 11:23 pm, Bart Verwilst wrote: > || > Hi! > || > > || > I'm the packager of pyQT + sip for Gentoo Linux. > || > Could it be possible to abandon the use of explicitly having the user > || > type "yes" before starting the install? Since Portage rules are not > || > to allow user input during the install process, it would be much > || > nicer just to have build.py list something like "By installing this, > || > you automatically accept our license." Or something like it was > || > before... I hope you take this into consideration... > || > || Doesn't Qt require you to do the same? > > Yeah, we patched that too.. > But i think it would be nicer if we wouldn't have to do this at all for > pyqt.. Pretty please? :o) Out of curiosity, how do you get away with that? Is it written somewhere in the license that anyone who installs/uses this program agrees to its license? It has always kind of bugged me (as a developer), but I never investigated as I do agree to their license. (Also, it seemed like someone took the long way around to do that when you could probably echo "Yes" or something to the configure script instead of having to sed it... but that's fairly irrelevant.) - --Kaleb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE98VB8eAVt8Tl/2kURArWIAJ4nLwXL1LcrIMQ72EO2a6ickQm9HACgvISn ubvf81i2uxn9OUgLq3NKxIs= =/ATV -END PGP SIGNATURE- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] License + new release soon? :$
On Saturday 07 December 2002 00:43, Kaleb Pederson wrote: || -BEGIN PGP SIGNED MESSAGE- || Hash: SHA1 || || As a note, I would love to see that done as well, or at least an option || that can be specified on the command line. I'm a gentoo user and would || like to see that. || || Of course, you can just get around it by doing a simple: || || $ echo "yes" | python build.py || || But it is better not to. || || Bart, do you have any interesting in building ebuilds for the snapshots? || As I do most of my development using PyQt, I have had to build my own for || the snapshots. Are these of any interest to you? Also, now that eric is a || distinct package, I presume we will see an ebuild for it here upon the || next release? I'll willing to help in these areas. || Do you have your own eric ebuild already? Otherwise, it would be great if you could send it to me, saves me some work :p I'll make sure eric becomes a part of Portage, rest assured :o) || - --Kaleb || || On Friday 06 December 2002 03:23 pm, Bart Verwilst wrote: || > Hi! || > || > I'm the packager of pyQT + sip for Gentoo Linux. || > Could it be possible to abandon the use of explicitly having the user || > type "yes" before starting the install? Since Portage rules are not to || > allow user input during the install process, it would be much nicer || > just to have build.py list something like "By installing this, you || > automatically accept our license." Or something like it was before... I || > hope you take this into consideration... || > || > And also, when is a new release due? So we can release Gentoo 1.4 with || > full and working pyQT support for QT 3.1. || > || > Thanks in advance! || || -BEGIN PGP SIGNATURE- || Version: GnuPG v1.0.7 (GNU/Linux) || || iD8DBQE98TYveAVt8Tl/2kURArhHAJ9yccagQCMF32TznQ7QdkuaEn+mVwCcC7wk || hh0WNG33245u6omJ3ckLkNs= || =XOWe || -END PGP SIGNATURE- || || ___ || PyKDE mailing list[EMAIL PROTECTED] || http://mats.gmd.de/mailman/listinfo/pykde -- Bart Verwilst Gentoo Linux Developer, Desktop Team Gent, Belgium ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] License + new release soon? :$
On Saturday 07 December 2002 01:30, Phil Thompson wrote: || On Friday 06 December 2002 11:23 pm, Bart Verwilst wrote: || > Hi! || > || > I'm the packager of pyQT + sip for Gentoo Linux. || > Could it be possible to abandon the use of explicitly having the user || > type "yes" before starting the install? Since Portage rules are not to || > allow user input during the install process, it would be much nicer || > just to have build.py list something like "By installing this, you || > automatically accept our license." Or something like it was before... I || > hope you take this into consideration... || || Doesn't Qt require you to do the same? || Yeah, we patched that too.. But i think it would be nicer if we wouldn't have to do this at all for pyqt.. Pretty please? :o) || > And also, when is a new release due? So we can release Gentoo 1.4 with || > full and working pyQT support for QT 3.1. || || Any day now - I'm just trying to fix a build problem with HP-UX. || || Phil Cool, thanks! I was going to put a snapshot into portage otherwise, but i'll wait for the official release now :o) || || ___ || PyKDE mailing list[EMAIL PROTECTED] || http://mats.gmd.de/mailman/listinfo/pykde -- Bart Verwilst Gentoo Linux Developer, Desktop Team Gent, Belgium ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Multithreaded GUI programming
On December 6, 2002 11:50 am, Michael Lauer wrote: > Our setup is a typical multithreaded one: We have a number of worker > threads and one GUI thread, > both communicating via a Queue. The problem is: How not to waste CPU > resources by using a timer > to poll the communication Queue from within the GUI thread. I don't imagine that the polling is going to be particularly expensive but I've never measured it. Have you? > Qt/E 2.3.4 > is _not_ thread-safe, so all calls to Qt must be done from same thread. > This also means, > it's unfortunately not possible to call QApplication.postEvent() from a > worker thread > to make the GUI thread to check for a new message in the Queue. Are you not able to use QApplication.lock() and unlock() around the postEvent? Ciao, Gordon ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] Broken QThread Support Under Windows
Qt v3.0.5 and later versions have broken threading in PyQt under Windows - Linux/Unix are fine. You can see the effect running the semaphore.py example. I had a brief email exchange with somebody when this was first noticed some months ago, who suggested what the change in Qt might have been to cause the problem. I'm now trying to get to the bottom of this - but I don't seem to have a record of the email exchange. Does this ring a bell with anybody - was it you? Thanks, Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] License + new release soon? :$
On Friday 06 December 2002 11:23 pm, Bart Verwilst wrote: > Hi! > > I'm the packager of pyQT + sip for Gentoo Linux. > Could it be possible to abandon the use of explicitly having the user type > "yes" before starting the install? Since Portage rules are not to allow > user input during the install process, it would be much nicer just to have > build.py list something like "By installing this, you automatically accept > our license." Or something like it was before... I hope you take this into > consideration... Doesn't Qt require you to do the same? > And also, when is a new release due? So we can release Gentoo 1.4 with full > and working pyQT support for QT 3.1. Any day now - I'm just trying to fix a build problem with HP-UX. Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] License + new release soon? :$
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As a note, I would love to see that done as well, or at least an option that can be specified on the command line. I'm a gentoo user and would like to see that. Of course, you can just get around it by doing a simple: $ echo "yes" | python build.py But it is better not to. Bart, do you have any interesting in building ebuilds for the snapshots? As I do most of my development using PyQt, I have had to build my own for the snapshots. Are these of any interest to you? Also, now that eric is a distinct package, I presume we will see an ebuild for it here upon the next release? I'll willing to help in these areas. - --Kaleb On Friday 06 December 2002 03:23 pm, Bart Verwilst wrote: > Hi! > > I'm the packager of pyQT + sip for Gentoo Linux. > Could it be possible to abandon the use of explicitly having the user type > "yes" before starting the install? Since Portage rules are not to allow > user input during the install process, it would be much nicer just to have > build.py list something like "By installing this, you automatically accept > our license." Or something like it was before... I hope you take this into > consideration... > > And also, when is a new release due? So we can release Gentoo 1.4 with full > and working pyQT support for QT 3.1. > > Thanks in advance! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE98TYveAVt8Tl/2kURArhHAJ9yccagQCMF32TznQ7QdkuaEn+mVwCcC7wk hh0WNG33245u6omJ3ckLkNs= =XOWe -END PGP SIGNATURE- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Multithreaded GUI programming
On Friday 06 December 2002 03:50 am, Michael Lauer wrote: > > Our setup is a typical multithreaded one: We have a number of worker > threads and one GUI thread, > both communicating via a Queue. The problem is: How not to waste CPU > resources by using a timer > to poll the communication Queue from within the GUI thread. > > Some more information: Since we're targetting a PDA with Qt/Embedded, > we're using PyQt. > The PDA runs a non-threaded Qt/Embedded 2.3.4 and will for quite a long > time. Qt/E 2.3.4 > is _not_ thread-safe, so all calls to Qt must be done from same thread. > This also means, > it's unfortunately not possible to call QApplication.postEvent() from a > worker thread > to make the GUI thread to check for a new message in the Queue. > I'd say you are stuck. I would imagine that the timer is pretty efficient, and if it isn't, well it should be. Since you don't have the option of using select(), it's the only way to go. I'd be pretty interested myself if there is a way around this. The other thought is to use a timer that doesn't tick every once in a while. Basically, you set it to tick after a set time when you launch the thread, or start the task in the thread. Then when it ticks, you can check to see if it is finished, show an update to the screen and do whatever you would normally do. Set it to tick again if the task isn't finished, and call the same routine. The only benefit of this is that when your app isn't doing anything, it won't be taking resources either. However, it will be using a little more when something is happening in the background. -- Jonathan Gardner [EMAIL PROTECTED] ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] License + new release soon? :$
Hi! I'm the packager of pyQT + sip for Gentoo Linux. Could it be possible to abandon the use of explicitly having the user type "yes" before starting the install? Since Portage rules are not to allow user input during the install process, it would be much nicer just to have build.py list something like "By installing this, you automatically accept our license." Or something like it was before... I hope you take this into consideration... And also, when is a new release due? So we can release Gentoo 1.4 with full and working pyQT support for QT 3.1. Thanks in advance! -- Bart Verwilst Gentoo Linux Developer, Desktop Team Gent, Belgium ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] Multithreaded GUI programming
Hi, I have a question regarding efficient programming in a multithreaded environment. Our scenario deals with Qt, but the problem is a general one. Our setup is a typical multithreaded one: We have a number of worker threads and one GUI thread, both communicating via a Queue. The problem is: How not to waste CPU resources by using a timer to poll the communication Queue from within the GUI thread. Some more information: Since we're targetting a PDA with Qt/Embedded, we're using PyQt. The PDA runs a non-threaded Qt/Embedded 2.3.4 and will for quite a long time. Qt/E 2.3.4 is _not_ thread-safe, so all calls to Qt must be done from same thread. This also means, it's unfortunately not possible to call QApplication.postEvent() from a worker thread to make the GUI thread to check for a new message in the Queue. How is this handled in low-level programs? In C++, I would use a pipe for the communication and would overload the main event loop adding a pipe file descriptor to the select() call. This way I can simultaneously wait for gui events and non-gui events without wasting CPU resources. In Python, the situation is different, since I can't overload the main loop - it would be much to slow (let alone, that the internal gui main loop functions are private and thus are not exported). Even if I could, in Python I'd rather use Queues than pipes - and a Queue is nothing which can just be added to a select call. Could you share some insights with me? Cheers, Mickey. -- :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
