From: Sebastian T. <tr...@kd...> - 2009-02-06 09:21:06
|
On Friday 06 February 2009 00:18:37 Greg Beauchesne wrote: > Sebastian Trüg wrote: > > On Thursday 05 February 2009 16:38:03 Greg Beauchesne wrote: > >> Sebastian Trüg wrote: > >>> what do you think about the attached patch? > >>> I also managed to remove all dynamic_cast uses in PluginManager (forget > >>> the beginning of the file, that is related to the virtuoso backend). > >> > >> I think it might be missing your pluginstub.* changes, but otherwise it > >> looks good so far. Does the qobject_cast<> stuff work as expected with > >> old plug-ins? > > > > yes, it does. Attached is the full patch. I just sent the other one for > > the API. This patch also contains some other unrelated changes. You can > > ignore them (it probably will not apply correctly, thus I attach the > > sopranodirs.* files, too) > > OK, on running the patch with my mishmash of broken (for the moment) > plug-in locations, one of the things I noticed is that > PluginManager::loadPlugin() will add any plug-in to its list for which > there is a .desktop file, regardless of whether the actual library > loaded successfully or was the correct library type. Patch-to-your-patch > is attached for this. You are right. But doing so will load all plugins with dependencies again loosing the advantage of the desktop files. I don't think it is such a big issue that we load all the desktop files since this list is never exposed as is. It is just a list of possible plugins used internally. > There's also not a way to set the library search path yet. So, while I > can place the .desktop files wherever (which worked, by the way), the > actual library directory is still fixed to the preset locations > (libDirs()). Right. So I propose the addition of method setLibrarySearchPath(). But also just to recap: when using an installer on Windows stuff is installed in some location such as C:/Program Files/Soprano or whatever. And typically applications will store this path in the registry? How about a simpler approach and supporting env variables like SOPRANO_LIBRARY_PATH and SOPRANO_PLUGIN_PATH which are set by the installer. Is that possible on windows? Or we use QSettings to read this information. Then on Windows it could come from the registry (entries created by installer, independent of the actual lib which does not pollute the source code with windows-dependant stuff). And on Linux one had the possibility to install a global config file (or a local one) which defines additional search paths. > >> I don't know if you've done this already, but it seems like the > >> PluginStub class needs to be able to call QPluginLoader::unload() if > >> loading fails. That way, if the plug-in does not load, then it at least > >> won't stay in memory. > > > > right you are, Sir. Will do that (if you don't come up with a patch first > > ;) > > Done. Attached as part of the same patch as mentioned above. thanks. :) > > BTW: my wife just told me what your name means. Nice. :) > > Ah, yes. I'm told my heritage is French-Canadian. I don't actually speak > any French, though. Ah, c'est trop bête. Fraincais is such a nice language. :) Cheers, Sebastian |