[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Registries
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2006-06-09 17:25:05
Message-ID: Pine.LNX.4.63.0606091913560.2824 () calcifer ! valdyas ! org
[Download RAW message or body]

On Fri, 9 Jun 2006, Thomas Zander wrote:

> On Friday 9 June 2006 16:49, Boudewijn Rempt wrote:
> > But I guess the way I should have done this is:
> >
> > * query for the desktop file with ktrader
> > * store the KService::ptr service for when we need something from that
> > plugin * ask the desktop file for all the properties I mentioned above,
> > store them too, and use them in the GUI
> 
> This implies we are going to store all the strings for tooltip / 
> description / name / id / imagename in the desktop file.
> Including their translations.

Yes -- but that shouldn't be a problem for translators. It means we need
some class per plugin type that holds that information after loading,
similar to the factory interface classes we've got now.

> This means we now have the ID in the factory (still need that), in the 
> desktop file and in code of other tools/shapes that use.
> Ugh; I don't like that prospect.

I don't think we need the factory, _if_ we have only one tool, colorspace,
etc per plugin. Which is may be a problem, since it will mean that, for instance,
about sixteen of Krita's tools which are now in one plugin will go in sixteen
separate plugins. Unless David has something clever hidden up his sleeve.

The proliferation of places where we store the ID is an issue, yes.

> > * load the library and create the tool, colorspace or whatever only
> > when the user uses it. for instance, on the first click on the icon for
> > the tool in the toolbar.
> 
> I changed the ToolRegistry to not load a kpart plugin anymore, which is 
> unneeded.

kpart or not doesn't make much difference with ktrader-discovered plugins,
does it? I think Krita's plugins are only kparts because that's how they
started out, when we replaced Krita's circa 1998 plugin system with something
that works. But the discovery and plugin factory system is the same.

If you mean the tool registry doesn't load plugins at all anymore, then,
well, we're going to need a thorough discussion about that. But I guess
and hope that that isn't the case.

> And with the gcc symbol hiding I personally want to see the resulting 
> speed before we optimize where it might not be needed.

Well, it's the difference between just reading .desktop files and reading
.desktop files _and_ .so files, and loading them in memory and instantiating
an object. I would assume there to be quite a bit of difference. But a little
test should be easy enough to write... Create hundred small plugins, a small kapplication,
just discover them or create them and time the difference.

> Since I am coding the toolManager and I am not at all sure I like the 
> amount of increased complexity loading on demand gives.

I have the feeling it would be just as simple or even simpler, and reusable.
The same technique should work for all plugins that don't come with kxmlgui
files. Tools, shapes, colorspaces, krita filters, karbon filters, krita
paintops -- and I'm sure the list is open-ended.

>  I was finishing up tools and toolbox APIs and rough implementations and 
> about to start shapes this weekend to follow the ideas I gathered while 
> working on tools.  What was your planning? Should I keep away from them 
> for now?

I think shapes & shape registry should work just fine now, with the possible 
exception of a missing service type and desktop files for the krita shapes I'm 
currently putting a plugin. No need to work on that just now, I think.
I've checked in the Krita shape plugin code so you can look at it, if you want
to start on KWord-type shape plugins, and I hope to get krita's shape
plugins  working this weekend.


Boudewijn

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]