--===============1007029194== Content-Type: multipart/signed; boundary="nextPart13228598.m7TopTcMzS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart13228598.m7TopTcMzS Content-Type: multipart/alternative; boundary="Boundary-00=_IKncInjbuF64pBY" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-00=_IKncInjbuF64pBY Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Monday 07 July 2008 20:56:09 Thomas Zander wrote: > On Monday 7. July 2008 19:02:47 Stefan Nikolaus wrote: > > Functions=A0=A0=A0=A0=A0=A0=A0Switch from KoPluginLoader to KPluginLoad= er in order to > > use KPluginSelector. ;) > > Could you write up your experiences? I certainly want to use the > KPluginSelector one day, so I'm wondering what the difference between the > KPluginLoader and the KoPluginLoader is :) What prevent using the KPluginSelector with KoPluginLoader are just the con= fig=20 entries, that mark the plugins as enabled/disabled. While KoPluginLoader=20 stores a list for the enabled plugins and another one for the disabled ones= ,=20 KPluginSelector expects one entry per plugin. The only downside is that those entries are always stored in the config gro= up=20 "Plugins". It is possible, that one would get name clashes there. There are= =20 other KPluginSelector::addPlugin methods, which obviously are designed for= =20 KParts as they use the group "KParts Plugins". Maybe one could add another= =20 method, that takes a KConfigGroup. Besides, it would be possible to use KPluginLoader for loading shapes/tools. The FooPlugin simply becomes a plugin factory: K_PLUGIN_FACTORY(FooPluginFactory, registerPlugin(); registerPlugin(); ) K_EXPORT_PLUGIN(FooPluginFactory("FooPlugin")) The macro creates a KPluginFactory derived class. The name "FooPlugin" has = to=20 be the "X-KDE-PluginInfo-Name" in the desktop file. You also have to add=20 "KPluginInfo" to "X-KDE-ServiceTypes" there and may add the several "X-KDE- PluginInfo-*" entries. For examples of the desktop files look in=20 koffice/kspread/functions.=20 On the loading side: Query the KServiceTypeTrader as before, do some=20 conversions, iterate over each service/plugininfo (see=20 koffice/kspread/FunctionModuleRegistry.cpp), and you can get first the plug= in=20 factory by: KPluginFactory *factory =3D KPluginLoader(*pluginInfo.service()).factory(); And then from this factory the shape and tool can be created by: KoShape* shape =3D factory->create(parentQObject); KoTool* tool =3D factory->create(parentQObject); That's it. :) =2D-=20 Stefan Nikolaus --Boundary-00=_IKncInjbuF64pBY Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable p, li { white-space: pre-wrap; }On Monday 07 July 2008 20:56:09 Thomas Zander wrote:<= br> > On Monday 7. July 2008 19:02:47 Stefan Nikolaus wrote:
> > Functions=A0=A0=A0=A0=A0=A0=A0Switch from KoPluginLoader to KPlug= inLoader in order to
> > use KPluginSelector. ;)
>
> Could you write up your experiences? I certainly want to use the
> KPluginSelector one day, so I'm wondering what the difference between = the
> KPluginLoader and the KoPluginLoader is :)

What prevent using the KPluginSelector with KoPluginLoade= r are just the config entries, that mark the plugins as enabled/disabled. W= hile KoPluginLoader stores a list for the enabled plugins and another one f= or the disabled ones, KPluginSelector expects one entry per plugin.
The only downside is that those entries are always stored in the config gro= up "Plugins". It is possible, that one would get name clashes there. There = are other KPluginSelector::addPlugin methods, which obviously are designed = for KParts as they use the group "KParts Plugins". Maybe one could add anot= her method, that takes a KConfigGroup.
Besides, it would be possible to use KPluginLoader for loading shapes/tools= =2E
The FooPlugin simply becomes a plugin factory:

K_PLUGIN_FACTORY(FooPluginFactory,
registerPlugin<FooShape>();
registerPlugin<FooTool>();
)
K_EXPORT_PLUGIN(FooPluginFactory("FooPlugin"))

The macro creates a KPluginFactory derived class. The nam= e "FooPlugin" has to be the "X-KDE-PluginInfo-Name" in the desktop file. Yo= u also have to add "KPluginInfo" to "X-KDE-ServiceTypes" there and may add = the several "X-KDE-PluginInfo-*" entries. For examples of the desktop files= look in koffice/kspread/functions.
On the loading side: Query the KServiceTypeTrader as before, do some conver= sions, iterate over each service/plugininfo (see koffice/kspread/FunctionMo= duleRegistry.cpp), and you can get first the plugin factory by:

KPluginFactory *factory =3D KPluginLoader(*pluginInfo.ser= vice()).factory();

And then from this factory the shape and tool can be crea= ted by:

KoShape* shape =3D factory->create<KoShape>(pare= ntQObject);
KoTool* tool =3D factory->create<KoTool>(parentQObject);

That's it. :)

--
Stefan Nikolaus

--Boundary-00=_IKncInjbuF64pBY-- --nextPart13228598.m7TopTcMzS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkhycowACgkQpfDn2DABIpcH5ACeNtBBBYE5RrD85+j2Fvpu5b/y MxcAn2tWyfWexGqSOgfJTxfeOqoQs04u =z8El -----END PGP SIGNATURE----- --nextPart13228598.m7TopTcMzS-- --===============1007029194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ koffice-devel mailing list koffice-devel@kde.org https://mail.kde.org/mailman/listinfo/koffice-devel --===============1007029194==--