[PyKDE] PyKDE 3.16.0 released

[Torsten Marek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim Bublitz schrieb:
> 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.
> 
Hi Jim,

sounds like a plan for a quick bug fix. If I have some time, I'll try to find a
better fix later.

best,

Torsten

- --
Torsten Marek <shlomme at gmx.net>
ID: A244C858 -- FP: 1902 0002 5DFC 856B F146  894C 7CC5 451E A244 C858
Keyserver: subkeys.pgp.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFGCDffMVFHqJEyFgRAsgFAKCwvdXnp/AkmMgrHo+uc4UobfLCHwCfa0zj
gN3jWiLXF9IpCzkuxh0xps0=
=QEpR
-----END PGP SIGNATURE-----