[Kst] branches/work/kst/pluginify/kst/src

Adam Treat treat at kde.org
Thu Sep 21 20:11:21 CEST 2006


On Thursday 21 September 2006 2:07 pm, Adam Treat wrote:
> On Thursday 21 September 2006 1:55 pm, George Staikos wrote:
> > On Wednesday 20 September 2006 18:06, Adam Treat wrote:
> > > SVN commit 586905 by treat:
> > >
> > > * Connect the modified signal in the base class.
> > > * A bit of cleanup of kstdataobject includes
> > > * Only scan for datasource plugins once
> > > --- branches/work/kst/pluginify/kst/src/libkst/kstdatasource.cpp
> > > #586904:586905 @@ -157,7 +157,9 @@
> > >
> > >  static QValueList<PluginSortContainer> bestPluginsForSource(const
> > > QString& filename, const QString& type) {
> > > QValueList<PluginSortContainer> bestPlugins;
> > > -  scanPlugins();
> > > +  if (pluginInfo.isEmpty()) {
> > > +    scanPlugins();
> > > +  }
> > >
> > >    KST::PluginInfoList info =
> > > QDeepCopy<KST::PluginInfoList>(pluginInfo);
> >
> >   Good catch!  This should speed up the data wizard url requester a bit.
> >
> :)
>
> On a similar subject, any objection to changing the datasource loading
> mechanism to use the regular KDE loading infrastructure instead of
> specifying the symbol loading ourselves?  Right now there is confusion
> regarding the X-KDE-Library property...
>
> Normally, this should be set to 'kstdata_ascii' where the library
> is 'kstdata_ascii.so', but currently it is set to 'ascii' and the custom
> loading stuff prepends the 'kstdata_' to it.  I understand this is done to
> keep the symbols short, but if we just use KParts::ComponentFactory like
> the data object plugins, we can probably get rid of having all these
> symbols I think...
>
> Any thing I'm missing?

BTW, I know this isn't a priority nor does it especially need to be fixed, I'm 
just thinking long term...

> Adam
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst


More information about the Kst mailing list