Re: [PyKDE] Re: Kcontrol modules.
On Wednesday July 9 2003 15:20, David Boddie wrote:
> Following up to this again as things change...
>
> On Tue, 8 Jul 2003 20:21:21, Simon Edwards
<[EMAIL PROTECTED]> wrote:
> > I had a look at the IOSlave code and saw that it works quite
> > differently than kcms. Kcms are basically shared libraries
> > that have a factory method that returns a instances of a
> > subclass of KCModule.
>
> Well, I've managed to get kicker to load a shared library and
> call the C++ "init" factory function as normal. This starts a
> Python interpreter, looks for the relevant Python module,
> imports it then calls the "init" function in the module. The
> "init" function creates an instance of the KPanelApplet
> subclass and returns this to the C++ function.
>
> -> C++ "init"
>...
>-> Python "init"
> ...
> -> AppletClass.__init__
> ...
> applet <-
> ...
>pInstance <-
>
> The instance is then converted to a pointer using
>
> panel_applet = (KPanelApplet*)sipMapSelfToThis(pInstance);
>
> which is returned to the caller. Kicker (or its applet loading
> proxy) then crashes, rather unhelpfully failing to provide a
> traceback.
>
> Any ideas on what I'm doing wrong would be good at this point.
sipMapSelfToThis returns sipThisType*, which is a ptr to a
struct. You probably want sipThisType->cppPtr (at least it is in
3.5 - its in siplib/siplib.c). Alternatively, it's a little
simpler to use:
KPanelApplet *sipForceConvertTo_KPanelApplet (
PyObject *,int *)
eg:
#include
int isErr = 0;
panel_applet = sipForceConvertTo_KPanelApplet (pyObj, &isErr);
if (isErr) {
}
and link to libkdeui (in site-packages).
You might not be this far along, but will your method allow
someone to choose one of several panel applets written in Python
using the same .so file for each? In other words, does each
applet require a .so file, or is there a common .so file and
users just write applets strictly in Python?
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] More 3.7 compile issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 09 July 2003 18:46, Steve Simmons wrote: > On Wed, Jul 09, 2003 at 02:14:33PM -0700, Jonathan Gardner wrote: > > On Wednesday 09 July 2003 13:32, Steve Simmons wrote: > > > On Wed, Jul 09, 2003 at 03:49:46PM -0400, Rob Knapp wrote: > > > I would normally do 'python build.py' and 'make' as an ordinary > > > user, then 'make install' as root. Unfortunately sip and PyQt (and > > > PyKDE?) attempt to compile directly into a /usr/local (or equiv) > > > directory. . . > > > > Isn't this desired behavior? By default, most packages install into > > /usr/local. If you want it to go into /usr or somewhere else, you'll > > have to specify it in args to build.py (or the configure program in > > other packages). > > For install yes, but for build no. You should be able to compile > completely as a user, and potentially even run tests as a user, > without being root. Invoking large complex make processes as root > is, well, not something a cautious sysadmin would do. > Yes, you can do this as a user. You will need to pass the proper arguments to build.py and/or set the proper environment variables. And the install directives do affect the binaries and libraries that come out the other end. So you need to say up front in many cases where everything is going to go, or where it is right now. The last thing you want to do is have the configuration script try to automatically find the headers, libraries, etc, on its own because you didn't specify it. If you have another version of the same software on the system, the chances of it finding the wrong one is too great. So you must either explicitly state where everything is, or watch the output with an eagle eye. > > A better approach is to always, always, always remove sip and PyQt > > before installing something new. After all, you are really asking for > > trouble if you have libsip.so.9 and libsip.so.10 in the same directory. > > Before installing, yes. But consider the joy of removing them and then > discovering that the new version doesn't build, or has bugs in your > environment. Yet another reason why one should be able to build and > test before doing the actual install. Again, if you know exactly what you are doing, you can do what you like. If you are still new to how sip and PyQt depend on each other, then you are better off working with a clean system. Just search through the archives to see how many times Phil has said, "You have version X of sip and version Y of PyQt." He is not talking to newbies -- some of these people are experienced developers and administrators! How many times have I had to take a deep breath and remember that I had the exact same problem? I can't count that high. For myself, my rule is "blow away all of sip, PyQt, and PyKDE before trying to build any of it. Always build qscintilla, sip, PyQt then PyKDE, and always in that order." This has saved me a lot of grief. And save yourself a lot of work and start using RPM of debian packaged managers. That way, when you screw up your system, you can bomb out the new stuff and install the known working RPM and you are happy. - -- Jonathan Gardner [EMAIL PROTECTED] (was [EMAIL PROTECTED]) Live Free, Use Linux! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/DQS1WgwF3QvpWNwRAo4PAJ45lv1lFbcuHRSrmQtNsVku4x3hHgCg30CS kFZQePjYPsUjoUfz4sOdAnY= =Z960 -END PGP SIGNATURE- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] More 3.7 compile issues
On Wed, Jul 09, 2003 at 02:14:33PM -0700, Jonathan Gardner wrote: > On Wednesday 09 July 2003 13:32, Steve Simmons wrote: > > On Wed, Jul 09, 2003 at 03:49:46PM -0400, Rob Knapp wrote: > > I would normally do 'python build.py' and 'make' as an ordinary > > user, then 'make install' as root. Unfortunately sip and PyQt (and > > PyKDE?) attempt to compile directly into a /usr/local (or equiv) > > directory. . . > > Isn't this desired behavior? By default, most packages install into > /usr/local. If you want it to go into /usr or somewhere else, you'll have to > specify it in args to build.py (or the configure program in other packages). For install yes, but for build no. You should be able to compile completely as a user, and potentially even run tests as a user, without being root. Invoking large complex make processes as root is, well, not something a cautious sysadmin would do. > A better approach is to always, always, always remove sip and PyQt before > installing something new. After all, you are really asking for trouble if you > have libsip.so.9 and libsip.so.10 in the same directory. Before installing, yes. But consider the joy of removing them and then discovering that the new version doesn't build, or has bugs in your environment. Yet another reason why one should be able to build and test before doing the actual install. ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Re: Kcontrol modules.
Following up to this again as things change... On Tue, 8 Jul 2003 20:21:21, Simon Edwards <[EMAIL PROTECTED]> wrote: > I had a look at the IOSlave code and saw that it works quite differently > than kcms. Kcms are basically shared libraries that have a factory method > that returns a instances of a subclass of KCModule. Well, I've managed to get kicker to load a shared library and call the C++ "init" factory function as normal. This starts a Python interpreter, looks for the relevant Python module, imports it then calls the "init" function in the module. The "init" function creates an instance of the KPanelApplet subclass and returns this to the C++ function. -> C++ "init" ... -> Python "init" ... -> AppletClass.__init__ ... applet <- ... pInstance <- The instance is then converted to a pointer using panel_applet = (KPanelApplet*)sipMapSelfToThis(pInstance); which is returned to the caller. Kicker (or its applet loading proxy) then crashes, rather unhelpfully failing to provide a traceback. Any ideas on what I'm doing wrong would be good at this point. David ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] More 3.7 compile issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 09 July 2003 13:32, Steve Simmons wrote: > On Wed, Jul 09, 2003 at 03:49:46PM -0400, Rob Knapp wrote: > > These issues have been resolved. I'm just noting them here in case > > anyone else has the same problem. Not sure how they would since it was > > my own idiocy...but I can't be the only one this unobservant, can I? > > Nope, I did it too. > > I would normally do 'python build.py' and 'make' as an ordinary > user, then 'make install' as root. Unfortunately sip and PyQt (and > PyKDE?) attempt to compile directly into a /usr/local (or equiv) > directory. This has been an issue for quite some time, and one of > these days I'll fix the Makefiles and send the patches to the developers. > Isn't this desired behavior? By default, most packages install into /usr/local. If you want it to go into /usr or somewhere else, you'll have to specify it in args to build.py (or the configure program in other packages). A better approach is to always, always, always remove sip and PyQt before installing something new. After all, you are really asking for trouble if you have libsip.so.9 and libsip.so.10 in the same directory. - -- Jonathan Gardner <[EMAIL PROTECTED]> (was [EMAIL PROTECTED]) Live Free, Use Linux! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/DIW5WgwF3QvpWNwRAgX3AJ4yYSKevmUV+mhCblmddJi0yfLLBwCfZoUa Eab/bBMNUj4tVFlub2XJLwQ= =+gMj -END PGP SIGNATURE- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] More 3.7 compile issues
On Wed, Jul 09, 2003 at 03:49:46PM -0400, Rob Knapp wrote: > These issues have been resolved. I'm just noting them here in case anyone > else has the same problem. Not sure how they would since it was my > own idiocy...but I can't be the only one this unobservant, can I? Nope, I did it too. I would normally do 'python build.py' and 'make' as an ordinary user, then 'make install' as root. Unfortunately sip and PyQt (and PyKDE?) attempt to compile directly into a /usr/local (or equiv) directory. This has been an issue for quite some time, and one of these days I'll fix the Makefiles and send the patches to the developers. Next stop - building PyKDE 3.7 on FreeBSD 4.8... ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] More 3.7 compile issues
These issues have been resolved. I'm just noting them here in case anyone else has the same problem. Not sure how they would since it was my own idiocy...but I can't be the only one this unobservant, can I? The whole problem was that I wasn't watching the make processes for errors. Apparently the buid of sip was failing to copy libsip.dll and sip.exe over for some reason (in use by another app maybe?) And the second issue came from not realizing an error had occured during the make install. On Wed July 9 2003 12:30 pm, Phil Thompson wrote: > On Wednesday 09 July 2003 4:29 pm, Rob Knapp wrote: > > I'm currently compiling on a win32 platform and the build process > > reported that sipBadLengthForSlice was an unknown identifier. The line > > number provided was line 130 in spi/qstringlist.sip. > > Make sure you are using SIP v3.7. > Removing all versions of sip from my computer and re-making it did the trick. I'm not sure where how sip wasn't getting replaced. [snip] > > However, there is a larger problem. When I reach the end of my > > compilation and attempt to import qt I get this: > > [snip] > > That sounds like you have a 3.7 libqtc.pyd and a 3.6 qt.py. > > An explanation of both problems might be that you forgot to run "nmake > install" after building both SIP and PyQt. This also resolved the problem. The make of qtuic.pyd failed (because I don't have the XML module installed), which prevented nmake install from copying this over. Copying the .py files over manually resolved this issue. > Phil > > ___ > PyKDE mailing list[EMAIL PROTECTED] > http://mats.imk.fraunhofer.de/mailman/listinfo/pykde ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: Re[2]: [PyKDE] Problems compiling PyQt 3.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 09 July 2003 06:00, mazu wrote: > Witaj Hans-Peter, > > W Twoim licie datowanym 8 lipca 2003 (21:56:03) mo¿na przeczytaæ: > > HPJ> Your env. is missing the qt3-devel package. > > HPJ> Pete > > >> I get errors about QAssistantClient while compiling PyQt 3.7, on my > >> debian woody with Qt 3.1.2. Here is compiler message: > > Could you tell me the exact name of the package, which is missing? > I've got libqt3-mt and libqt3-mt-dev already installed. I found > similar problem in FAQ, but my Qt is version 3.1.2. You may have the packages installed properly. However, you environmental variables aren't pointing to the right places or don't exist at all. Read through the options of build.py and pass in appropriate arguments to detail where you have all of the header files and such, or set up your environment correctly. - -- Jonathan Gardner <[EMAIL PROTECTED]> (was [EMAIL PROTECTED]) Live Free, Use Linux! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/DFyDWgwF3QvpWNwRAiF9AKCLKlRwiecsXVmpx0yRMNURWnCbUQCeIzUl fFfMQ0N5yeUbAuzcjg4hp18= =3glv -END PGP SIGNATURE- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Re: Kcontrol modules
On Tue, 8 Jul 2003 20:21:21, Simon Edwards <[EMAIL PROTECTED]> wrote: > Anyone here tried doing kcontrol modules in Python+PyKDE? Not yet. > After seeing the success of IOSlaves in Python, I would like to be able to > kcontrol modules (kcm). I've been playing a bit with coding some admin > progs that really should be integrated with the control center. > > I had a look at the IOSlave code and saw that it works quite differently > than kcms. Kcms are basically shared libraries that have a factory method > that returns a instances of a subclass of KCModule. Yes, when I started looking at panel applets I realised what all the fuss was about! > What I would like is some opinions on the three ways of doing in kcms in > Python. (the 3 ways that I can think of ;-) ): > > 1) Implement in C/C++ a kcm that takes a python script from somewhere, > creates a KCModule instance using the script and returns it back to KDE > Control for running/embedding. This would be a case of C++ calling a > library which returns a PyKDE/Python object. I don't know if this is > possible. I'd try this method. Recent recommendations by Phil to use various sip functions might turn out to be very useful in this context. > 2) Implement in C/C++ a kcm and a subclass of KCModule (Pykcm). Pykcm > embeds the Python interpretter, and takes a python script from somewhere. > It then delegates its methods out to the corresponding methods in the > script. This sounds possible, and it probably a good solution (if it works. > ;-) ) This is a lot of work. > 3) Implement in C/C++ a kcm that runs an external python script that then > uses QXEmbed (see the KDE API docs) to embed itself in the KDE Control > center. This is quite do-able I think, but there may be some draw backs. I've no idea whether this would work! > Any thoughts? I'm going to pursue option 1 as I think that it'll provide the most flexible solution, if it works. Don't let me stop anyone else from trying any of the above methods. All the best, David ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Fwd: Re: [PyKDE] Losing Timers
I meant to say, "put the following in (for example) qglobal.sip".
Phil--- Begin Message ---
On Wednesday 09 July 2003 3:06 pm, Miller, Douglas wrote:
> A problem of losing Timer Events on the Qt interest email archive was
> solved this way.
>
> Set 'qt_win_use_simple_timers' in qapplication_win.cpp to true.
>
> The following snippet of code solved it:
>
> Q_EXPORT extern bool qt_win_use_simple_timers;
>
> void someInitFunction()
> {
> ...
> qt_win_use_simple_timers=true;
> }
>
>
> Does PyQt allow access to this variable so I can set it? Or how would this
> best be implemented? Please give me some guidance. Thanks.
You will have to create a function that will set the variable. Put something
like the following in (for example)...
void set_simple_timers(bool);
%MemberCode
int s;
if (sipParseArgs(&sipArgsParsed,sipArgs,"i",&s)
{
Q_EXPORT extern bool qt_win_use_simple_timers;
qt_win_use_simple_timers = s;
Py_INCREF(Py_None);
return Py_None;
}
%End
Phil
--- End Message ---
Re: [PyKDE] Losing Timers
On Wednesday 09 July 2003 3:06 pm, Miller, Douglas wrote:
> A problem of losing Timer Events on the Qt interest email archive was
> solved this way.
>
> Set 'qt_win_use_simple_timers' in qapplication_win.cpp to true.
>
> The following snippet of code solved it:
>
> Q_EXPORT extern bool qt_win_use_simple_timers;
>
> void someInitFunction()
> {
> ...
> qt_win_use_simple_timers=true;
> }
>
>
> Does PyQt allow access to this variable so I can set it? Or how would this
> best be implemented? Please give me some guidance. Thanks.
You will have to create a function that will set the variable. Put something
like the following in (for example)...
void set_simple_timers(bool);
%MemberCode
int s;
if (sipParseArgs(&sipArgsParsed,sipArgs,"i",&s)
{
Q_EXPORT extern bool qt_win_use_simple_timers;
qt_win_use_simple_timers = s;
Py_INCREF(Py_None);
return Py_None;
}
%End
Phil
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] More 3.7 compile issues
On Wednesday 09 July 2003 4:29 pm, Rob Knapp wrote: > I'm currently compiling on a win32 platform and the build process reported > that sipBadLengthForSlice was an unknown identifier. The line number > provided was line 130 in spi/qstringlist.sip. Make sure you are using SIP v3.7. > For the time being I've hacked the .sip file to simply return NULL in those > circumstances since my immediate needs don't require that class...however > it would be nice to have the option of using it in future. > > However, there is a larger problem. When I reach the end of my compilation > and attempt to import qt I get this: > > Traceback (most recent call last): > File "" line 1, in ? > File "d:\projects\lib\qt.py", line 924 in ? > libqtc.sipRegisterClasses() > SystemError: Unable to find class object for QSignalMapper That sounds like you have a 3.7 libqtc.pyd and a 3.6 qt.py. An explanation of both problems might be that you forgot to run "nmake install" after building both SIP and PyQt. Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] More 3.7 compile issues
I'm currently compiling on a win32 platform and the build process reported that sipBadLengthForSlice was an unknown identifier. The line number provided was line 130 in spi/qstringlist.sip. For the time being I've hacked the .sip file to simply return NULL in those circumstances since my immediate needs don't require that class...however it would be nice to have the option of using it in future. However, there is a larger problem. When I reach the end of my compilation and attempt to import qt I get this: Traceback (most recent call last): File "" line 1, in ? File "d:\projects\lib\qt.py", line 924 in ? libqtc.sipRegisterClasses() SystemError: Unable to find class object for QSignalMapper I've tried defining QT_NO_SIGNALMAPPER in qconfig.h to get around this, but that just generates compile errors. ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Losing Timers
A problem of losing Timer Events on the Qt interest email archive was solved
this way.
Set 'qt_win_use_simple_timers' in qapplication_win.cpp to true.
The following snippet of code solved it:
Q_EXPORT extern bool qt_win_use_simple_timers;
void someInitFunction()
{
...
qt_win_use_simple_timers=true;
}
Does PyQt allow access to this variable so I can set it? Or how would this
best be implemented? Please give me some guidance. Thanks.
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re[2]: [PyKDE] Problems compiling PyQt 3.7
Witaj Hans-Peter, W Twoim licie datowanym 8 lipca 2003 (21:56:03) mo¿na przeczytaæ: HPJ> Your env. is missing the qt3-devel package. HPJ> Pete >> >> I get errors about QAssistantClient while compiling PyQt 3.7, on my >> debian woody with Qt 3.1.2. Here is compiler message: Could you tell me the exact name of the package, which is missing? I've got libqt3-mt and libqt3-mt-dev already installed. I found similar problem in FAQ, but my Qt is version 3.1.2. -- Pozdrowienia, mazumailto:[EMAIL PROTECTED] ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] SIP: wrapper code calls virtual functions with base class prefix
On Tuesday 08 July 2003 12:49 pm, Tore Knabe wrote: > Hi, > > I want to wrap a base class, which serves as an > interface, and inherit from this base class in C++. > The C++ class, which is not wrapped, overrides the > virtual function foo() from the base class. My > problem: when I call a factory method in Python to > create an object obj of the derived class, then > calling obj.foo() in Python executes the code from the > base class, not the derived one. Looking at the > wrapper code generated by SIP shows that foo is called > with the base class scope: BaseClass::foo(). This code > is generated by the function generateFunctionCall in > the SIP source file gencode.C. The commentary to the > function says: > > "... call the real function and not any version in the > wrapper class in case it is virtual. This will > prevent virtual loops." > > This protection against virtual loops prevents me from > using an interface class the way I planned. What would > happen if it were removed? What is an example of a > virtual loop? class MyWidget(QWidget): def setPalette(self,p): # Do some fiddling with the palette. # Now call the base class implementation. QWidget.setPalette(self,p) Phil ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
