Re: [PyKDE] 10.0 official rpms for PyKDE
Simon Edwards schrieb: On Monday 24 May 2004 08:04, Paul Evans wrote: Hi Simon, Have you made any moves that way or...? I was planning to spit RPMs out once PyKDE has been declared stable and released. Same with the unofficial SUSE RPMs. My target is to build a set of upgraded Qt/KDE Python tools including Python 2.3.4, SIP 4.0, the latest stable PyQt, PyKDE 3.11, and Eric 3.4.2. The problem is that during the last couple of weeks there was not a single day when all of the parts of the whole were stable at the same time ;-) It would be great if we could get the Python tools in sync with the next major KDE release (3.3), i.e. at the time KDE is released the upgreaded Python bindings are available, too ... If we are in sync with KDE (which implies that we are also in sync with the SUSE LINUX release schedules) I can make official SUSE packages. That's much harder (or even impossible) inbetween releases. My main focus here is on SIP/PyQt/PyKDE. Those should be in sync. Changing the Python version or updating to a new Eric is less pain ... As I can see from the KDE 3.3 feature plan that Simon has already opted to take care of this ;-) Cheers Joachim -- Joachim Werner SUSE RD-TPM ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QWaitCondition seems to cause deadlock
Hi, I found another one ... QThread.wait() dosen't have /ReleaseGIL/ as well. I hope this is the last. It looks like it's missing on QMutex.lock() as well. Tonight's snapshot should be fixed. __ Do You Yahoo!? http://bb.yahoo.co.jp/ ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Hoping this would be the correct forum for pyqt
Just wondering - did I join the correct forum? I'm looking for the PYQT list/forum - is this it? John ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Hoping this would be the correct forum for pyqt
On Tuesday 25 May 2004 2:39 pm, John Fabiani wrote: Just wondering - did I join the correct forum? I'm looking for the PYQT list/forum - is this it? John Yes. Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QWaitCondition seems to cause deadlock
On Tuesday 25 May 2004 1:14 pm, Shin-ichi MORITA wrote: Hi, I found another one ... QThread.wait() dosen't have /ReleaseGIL/ as well. I hope this is the last. Thanks - just made it for 3.12. Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] 10.0 official rpms for PyKDE
Same with the unofficial SUSE RPMs. My target is to build a set of upgraded Qt/KDE Python tools including Python 2.3.4, SIP 4.0, the latest stable PyQt, PyKDE 3.11, and Eric 3.4.2. The problem is that during the last couple of weeks there was not a single day when all of the parts of the whole were stable at the same time ;-) I believe you'll find that mentioned in the Book of Revelations as sign of the end of the world. :) It would be great if we could get the Python tools in sync with the next major KDE release (3.3), i.e. at the time KDE is released the upgreaded Python bindings are available, too ... KDE 3.2.3 is due in the next few weeks (last time I looked at the KDE release schedule), and the next PyKDE release should be ready very shortly after that. Phil has just released sip 3.10.2 (which the next PyKDE release will require) and hopefully the last sip4 rc (which PyKDE should work with), so sip 4.0 should be fairly close. Phil is also planning a PyQt update shortly. So everything should be in sync then. From what I've looked at, KDE 3.3 won't change a lot in kdelibs (which is all PyKDE cares about), and I'm planning on tracking the betas and rc releases. If the last kdelibs 3.3rc is binary compatible with the final release, I could have PyKDE complete *before* the final. But then in theory, 3.3 is supposed to be binary compatible with 3.2, I believe. The problem in doing that is that the final rpms from SuSE, Mankdrake and whatever RH/Fedora is doing now are never compatible with official KDE source code (I get the source either from kde.org or uk.kde.org) - eg KFileShare::setShared on SuSE 3.1.x later rpm releases, similar stuff on Mdk or RH, QXEmbed with some distros, etc. It only takes one modified or deleted method to make PyKDE essentially unusable - PyKDE binds nearly every method in the kdelibs modules it supports, which most apps don't do. That being the case, I'd be shooting myself in the foot by doing a release ahead of the official KDE 3.3 rpms and not testing against those. Usually, I only build against the latest KDE on SuSE, but test earlier versions against Mdk and RH. I have enough problems when I do test (eg, the current problems with kdeui not finding kdefx on Mdk 10.0, which doesn't happen on Mdk 9.x, any SuSE after 8.1 or RH9.x). With PyKDE now up-to-date with sip and PyQt and vice versa (which wasn't the case earlier in the year), it shouldn't take much more than a week to have a KDE3.3 version available. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Newbie MDI question
Hi, I'm a newbie (not only with PyQT but also Python). But I do have experience with M$ windows Visual FoxPro. So in the VFP world we use a MDI format for our programs. I'd like to continue this practice. So the question: When I create a QMainWindow (my main window) I add my menu's etc...from my menu actions I want to open a window in the space below the menu. The type of window is the question. Is the type of the new window also a QMainWindow (my child window)without menu's? If this is correct - can the child window receive events from the main window menu/toolbar etc... If not what is the correct type of window do I use? I know this may sound a little to simple but all the other GUI systems I have looked at used a different window type for child windows. TIA John ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Newbie MDI question
John Fabiani wrote: When I create a QMainWindow (my main window) I add my menu's etc...from my menu actions I want to open a window in the space below the menu. The type of window is the question. Is the type of the new window also a QMainWindow (my child window)without menu's? If this is correct - can the child window receive events from the main window menu/toolbar etc... If not what is the correct type of window do I use? Your main window should contain a single QWorkspace widget which is then the container for QWidgets which are rendered as MDI child windows. For more information: http://doc.trolltech.com/3.2/qworkspace.html Ciao, Gordn ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] 10.0 official rpms for PyKDE
On Tuesday 25 May 2004 10:03, Jim Bublitz wrote: The problem is that during the last couple of weeks there was not a single day when all of the parts of the whole were stable at the same time ;-) I believe you'll find that mentioned in the Book of Revelations as sign of the end of the world. :) I think it's actually '1st Bublitz, Ch 3, verses 7-9' :-) I was only asking, because I'm not as handy as many on this list and I often have a tough time compiling it all, so I really dread when I have to install something elsewhere. I've used chkinstall before to make rpms, but then the target box seems to need to be *just* like mine or it will fail to install. -- Regards, Paul Evans ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] 10.0 official rpms for PyKDE
On Tue, May 25, 2004 at 10:03:59AM -0700, Jim Bublitz wrote: That being the case, I'd be shooting myself in the foot by doing a release ahead of the official KDE 3.3 rpms and not testing against those. Usually, I only build against the latest KDE on SuSE, but test earlier versions against Mdk and RH. Well, if I wasn't convinced this was in good hands before I certianly am now. I'll wait patiently for SuSE rpms that will be ready, well, when they're ready. Thanks for the work, Jim. Steve Simmons -- Transported to a surreal landscape, a young girl kills the first woman she meets and then teams up with three complete stangers to kill again. -- TV listing for the movie, The Wizard of Oz, in the Marin Paper. ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Scribbling on QTextEdit/QTextBrowser
Hi, I'm playing with PyQT under Linux at the moment... I'm wondering - is there a way of mixing _something like_ QPainter with both/either QTextEdit/QTextBrowser. The scenario I'm thinking of is scribbling notes on these as annotations. (for example running on a PDA/tablet PC2) Something similar to DHTML layers would be the ideal sort of scenario... The question I have is this - is this possible with PyQT? I've looked at the QGL overlay stuff, but this seems to be very dependent on facilities in your display system. (That wouldn't be a problem, but it appears the X-Server for my graphics card is one of the ones that doesn't support overlay!) Failing that, does anyone know of a way of anchoring something like a QPainter widget inside QTextEdit/QTextBrowser in the same way you would anchor an image ? (This might actually be a more appropriate approach IMO) Any comments/pointers very much appreciated :) Michael. ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Implementing un-enabled Qt modules
Eron Lloyd wrote: How difficult would it be to provide wrappers for modules in Qt currently not enabled in PyQt, such as XML and Networking? In developing applications, I can see the benefits of having a single API for even these items as opposed to the python equivalents. Since your application is written in Python and will be the same across all platforms, why not use the Python XML and networking APIs? They're more pythonic and should be easier to use than the designed-for-C++ Qt APIs. Ciao, Gordon ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Systray icons in PyQt
Hello all, for a project of mine, I need a systray icon. I know that it is possible to get a one with PyKDE and there is a solution for PyGtk, but not for PyQt itself. But the code is rather easy and I found out that the ppl of qjackcontrol implemented a systray icon in Qt for themselves, using the spec + sample code from freedesktop.org (sorry, but I'm too lazy right know to find out all the links). All you need to do is to call some functions in libX11.so. For that, you need the Display (qt_x11_display()) and the WindowID (QWidget.winId()) So far, there are several ways to do the C calls from Python: - extension module - Pyrex - ctypes I chose the ctypes way and after some hassle (mostly typos!), I got it to actually work. It's not very advanced by now. To try it out, just replace the icon filename with something icon on your system. I put in all values in good faith and they are poorly documented right now, but I'll fix that later on. I'll go to bed now greetings Torsten -- Torsten Marek [EMAIL PROTECTED] ID: A244C858 -- FP: 1902 0002 5DFC 856B F146 894C 7CC5 451E A244 C858 www.keyserver.net -- wwwkeys.eu.pgp.net import sys import qt from ctypes import * class SystrayIcon(qt.QLabel): def __init__(self, parent = None, name = ): qt.QLabel.__init__(self, parent, name, qt.Qt.WMouseNoMask | qt.Qt.WRepaintNoErase | qt.Qt.WType_TopLevel | qt.Qt.WStyle_Customize | qt.Qt.WStyle_NoBorder | qt.Qt.WStyle_StaysOnTop) self.setMinimumSize(22, 22); self.setBackgroundMode(qt.Qt.X11ParentRelative) self.setBackgroundOrigin(qt.QWidget.WindowOrigin) libX11 = cdll.LoadLibrary(/usr/X11R6/lib/libX11.so) # get all functions, set arguments + return types XDefaultScreenOfDisplay = libX11.XDefaultScreenOfDisplay XDefaultScreenOfDisplay.argtypes = [c_void_p] XDefaultScreenOfDisplay.restype = c_void_p XScreenNumberOfScreen = libX11.XScreenNumberOfScreen XScreenNumberOfScreen.argtypes = [c_void_p] XInternAtom = libX11.XInternAtom XInternAtom.argtypes = [c_void_p, c_char_p, c_int] XGrabServer = libX11.XGrabServer XGrabServer.argtypes = [c_void_p] XGetSelectionOwner = libX11.XGetSelectionOwner XGetSelectionOwner.argtypes = [c_void_p, c_int] XSelectInput = libX11.XSelectInput XSelectInput.argtypes = [c_void_p, c_int, c_long] XUngrabServer = libX11.XUngrabServer XUngrabServer.argtypes = [c_void_p] XFlush = libX11.XFlush XFlush.argtypes = [c_void_p] # XClientMessageEvent class data(Union): _fields_ = [(b, c_char * 20), (s, c_short * 10), (l, c_long * 5)] class XClientMessageEvent(Structure): _fields_ = [(type, c_int), (serial, c_ulong), (send_event, c_int), (display, c_void_p), (window, c_int), (message_type, c_int), (format, c_int), (data, data)] # XEvent struct class XEvent(Union): _fields_ = [(xclient, XClientMessageEvent)] XSendEvent = libX11.XSendEvent XSendEvent.argtypes = [c_void_p, c_int, c_int, c_long, c_void_p] XSync = libX11.XSync XSync.argtypes = [c_void_p, c_int] dpy = int(qt.qt_xdisplay()) trayWin = self.winId(); print mywinid: 0x%x % trayWin screen = XDefaultScreenOfDisplay(dpy) iscreen = XScreenNumberOfScreen(screen) selectionAtom = XInternAtom(dpy, _NET_SYSTEM_TRAY_S%i % iscreen, 0) XGrabServer(dpy) managerWin = XGetSelectionOwner(dpy, selectionAtom) print managerWin: 0x%x % managerWin if managerWin != 0: XSelectInput(dpy, managerWin, 1L 17) XUngrabServer(dpy); XFlush(dpy); print managerWin if managerWin != 0: k = data() k.l = (0, 0, trayWin, 0, 0) ev = XClientMessageEvent(33, #type 0, # serial 0, # send_event dpy, # display managerWin, # window XInternAtom(dpy, _NET_SYSTEM_TRAY_OPCODE, 0), # message type 32, # format k) XSendEvent(dpy, managerWin, 0, 0, addressof(ev)) XSync(dpy, 0) img = qt.QImage(/usr/share/rattlesnake/pixmaps/rattlesnake64.png) pm = qt.QPixmap() pm.convertFromImage(img.smoothScale(22, 22), 0) self.setPixmap(pm)
[PyKDE] dcop
Hello, I've been playing with pyKDE and DCOP these last few days, and I must say it is not really easy. The main problem being I haven't been able to find any documentation (as soon as I have something working, I'll put it on the wiki). Up to now, I've managed to implement void functions. But either there's something I didn't understand, or the python prototype of DCOPObject.process() should be reviewed. Currently, the replyType and replyData are passed as arguments (as it is in C++). Their types are respectively QCString and QByteArray. The replyType is not a real problem, as I can set it with the setStr() method. However, pyKDE offers very few ways to interract with a QByteArray. And since it is passed as reference, I cannot build one from a python string. I'd like to be able to return at least a bool, an int, a QCString or a QCStringList. I've already tried to play with some QDataStream, etc, but pyKDE doesn't support the stream operators and , and I couldn't obtain any result. Perhaps the process() method should return a tuple of (bool, [something]) ? I don't know if it would be perfect, though. Does anyone know how to solve this ? Thanks. -- Amand Tihon pgpNh3dwetj9p.pgp Description: signature
Re: [PyKDE] dcop
On Tuesday 25 May 2004 20:22, Amand Tihon wrote:
Hello,
I've been playing with pyKDE and DCOP these last few days, and I must say
it is not really easy. The main problem being I haven't been able to find
any documentation (as soon as I have something working, I'll put it on the
wiki).
Up to now, I've managed to implement void functions.
But either there's something I didn't understand, or the python prototype
of DCOPObject.process() should be reviewed.
Currently, the replyType and replyData are passed as arguments (as it is in
C++). Their types are respectively QCString and QByteArray.
The replyType is not a real problem, as I can set it with the setStr()
method. However, pyKDE offers very few ways to interract with a QByteArray.
And since it is passed as reference, I cannot build one from a python
string.
I'd like to be able to return at least a bool, an int, a QCString or a
QCStringList. I've already tried to play with some QDataStream, etc, but
pyKDE doesn't support the stream operators and , and I couldn't obtain
any result.
Perhaps the process() method should return a tuple of (bool, [something]) ?
I don't know if it would be perfect, though.
Does anyone know how to solve this ?
It always cheers me up when someone asks about something I'm in the middle of.
I basically got a PyKDE-adapted version of pydcop (from kde-bindings - written
by Torben Weis and Julian Rockey) working this afternoon. Here's the basic
code to call a DCOP method and get the result back:
[methods from kicker/Panel are int panelSize () and
void addURLButton (QString)]
app = KApplication (...)
d = DCOPApplication (kicker, app.dcopClient ())
ok, pSize = d.Panel.panelSize () # pSize gets the int from the call
-or-
ok = d.Panel.addURLButton (QString (http://kde.org;))
(the QString (...) may not be required - haven't tested it yet).
That's all that's required. The dcop extension (one .py file and two global
functions added to the PyKDE kdecore lib) will take care of marshalling the
arguments (you have to provide the correct argument value types and count),
calling the function and demarshalling the replyData. The underlying methods
are available if you want to/need to do it the hard way. The kdecore
functions allow you to easily pack and unpack a QByteArray (using a
QDataStream).
No or operators yet though (function calls instead) - maybe in the
future, although the interface above makes them un-needed. You need to borrow
the dcopClient instance from a KApplication (the second param in the
DCOPApplication call).
The methods above always return at least a bool ('ok' - the status value from
the DCOP call -True== success, False == Failure), and a value if the method
isn't void.
I'm in the process of figuring what types to support, but most of the common
Qt and KDE classes that DCOP uses will be supported - for the most part
supporting a type is trivial. Not sure about the template types yet (for
example, QMap). Also, docs are needed and I need to decide if some exceptions
are required or if what's already there is sufficient.
I already had the basic QByteArray/QDataStream code done, and with what PyKDE
has available plus the elegant interface the KDE guys named above wrote (and
I stole) it's a pretty slick little package. Not much code at all.
It may not be finished for the next PyKDE release, but I'll probably include
it anyway, as it's pretty usable already. I still have to look at handling
the various string types (transparently I hope) and passing in things like
lists or dicts from Python. There should be something available in a couple
of weeks.
The other things I haven't looked at yet at all are DCOP enabling apps you
write using PyKDE or handling DCOP signals, but there's code I can steal for
that too.
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] PyKDE Factoids
In looking for DCOP-enabled KDE apps tonight, I ran across cxxmetric in kde3/bin, which will compute the number of code lines/comments/blank lines in a set of h/cpp files. Running it on PyKDE shows a little over 1.25 million lines of C++ code. That's excluding comments or blank lines. There's some duplication of h files in the various module subdirectories and extra/, but I'd guess that still puts PyKDE over 1 million LOC (and there are more modules coming) Those are mostly generated automatically by sip of course - I doubt the amount of actual written lines of C++ code is more that a few thousand lines. PyKDE binds about 700 classes and over 10,000 methods.. Now you know why it takes so long to compile. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
