--nextPart2780122.Qh6zbmM97x
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Dirk Mueller wrote:
>Oh, ok. Misunderstanding. I've not claimed that the code is supposed to
> stay that way forever. :) The problem is that we currently have about
> 23 places in KDE (according to lxr), that call KLibrary::findLibrary
> (which maps a lib to an absolute path) without actually loading it. I
> could certainly use the qlibrary code in your test.cpp to implement the
> searching, however I fear that it is a little bit slow to dlopen it
> just for fun. I was planning to get rid of those 23 places to be able
> to remove the findLibrary API ,then we can simplify the stuff a lot and
> benefit from the behaviour in QLibrary you pointed out.

Well, why do they find a library but don't load them? Are you also sure=20
they don't load later?

I tried the search in lxr.kde.org and found only 3 circumstances (not=20
places) where findLibrary is used without loading the library:

* IOSlave launching (the library is found in klauncher, but kdeinit=20
actually opens it)
* kst: I have no idea why it puts the result of findLibrary in a widget
* Kross: it checks for the presence of its Python and Ruby interpreters by=
=20
finding the library instead of finding .desktop files.
=2D-=20
=A0 Thiago Macieira =A0- =A0thiago (AT) macieira.info - thiago (AT) kde.org
=A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:
=A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358

--nextPart2780122.Qh6zbmM97x
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBFJ/naM/XwBW70U1gRAk9nAJ9OwNdLqGnc897kIPkpgoOknLb5DACgrBmt
Pt+Vf5hbwEQf3VQ9PDSqhpM=
=ecB+
-----END PGP SIGNATURE-----

--nextPart2780122.Qh6zbmM97x--