[PyKDE] PyKDE 3.16.0 released

[Jim Bublitz]

On Sunday 24 September 2006 00:17, Torsten Marek wrote:
> Jim Bublitz schrieb:
> > On Saturday 23 September 2006 13:04, Torsten Marek wrote:
> >> Hi Jim,
> >>
> >> one more thing. Is there a way to circumvent the libkonsolepart.so
> >> hackery? What you are doing in configure.py works for private persons
> >> who install PyKDE on their own, but I can't include something like that
> >> into the Debian package. I'd be happy to work on a fix if you could give
> >> me some pointers.
> >
> > The last reply was a little too quick - I didn't want dinner to overcook
> > and I was thinking just in terms of what has to be done to disable the
> > konsole_part stuff.  The way configure.py is set up it's easy to provide
> > a switch and you won't have to touch any files, so that's what I'll do.
>
> Hi Jim,
>
> hackery is a hard word, I know. Sorry for that,

No problem - it made me smile. I wasn't offended in the least (probably 
because it's fairly accurate).

> but still - linking against 
> non-versioned shared objects is not a very nice idea. Still, there should
> be a better way to solve this problem than removing functionality.

Nothing in kde3/lib/kde3 is versioned. The problem is that without the symlink 
and ldconfig, libkonsolepart.so can't be found, and PyKDE's kparts module 
won't load. The only alternative I can think of is to add kde3/lib/kde3 to 
the user's LIB_PATH (I think that's the environment variable - SuSE hasn't 
used it for quite a while), and I think that's a much less desireable 
modification to a user's system.

If there's some other way to do it, I'm open to suggestion, but it ends up 
being the same thing - linking to libkonsolepart.

> Is there a KDE API to load KParts by name? In that case, one could
> implement this API (if it's not already done), implement all the
> superclasses of the konsole KPart and "somehow" create the C++ wrapper for
> the konsole kpart object that is returned from the KPart loader. I have to
> admit that I really don't have any idea about how KDE loads its plugins.
> What I do know is that it's possible to use classes that were defined in
> dlopen'ed libraries as long as the superclasses are wrapped.

I'd think the KParts interface could be used to load a konsole part, and I'm 
not sure why the people requesting this seem to prefer access to the classes 
and methods directly. I'm just acting as the technician or mechanic here - I 
don't really understand the application of this code, but it's extremely easy 
for me to provide what was requested. I'm doing syntax, not semantics, and 
syntactically it works.

At any rate, I think any method would have the same problem, as something has 
to link and load libkonsolepart to get access to it's classes/methods. A more 
elegant wrapper just pushes the problem back one level.

There shouldn't be any version issues, because in order to get a new 
libkonsolepart version, you have to reinstall KDE, and if you do that, you 
probably need a new PyKDE (compiled or packaged) as well. 

So I think the only option is to include it/not include it. I would prefer 
PyKDE was the same platform anywhere so that people can distribute apps 
against it - this is one of the few cases where I'm willing to be flexible on 
that. Most useful extensions to PyKDE (like panel applets) are going to have 
the same problem (and probably the same solution).

I also think you're concern is valid, as libkonsolepart for KDE >= 3.5 isn't 
binary compatible with KDE < 3.5 (the  "one method changed" case, which 
breaks PyKDE that I mentioned above). But I'm not supporting the older 
versions, because they don't work at all on SuSE.

Jim