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

List:       koffice-devel
Subject:    Re: Registries
From:       Thomas Zander <zander () kde ! org>
Date:       2006-06-10 7:48:34
Message-ID: 200606100948.35349.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 10 June 2006 09:09, Boudewijn Rempt wrote:
> > 100? If its more then 20, I'd be surprised.  Only Krita is heavy on
> > plugins.
>
> Um... That means that if you immediately load a Krita flake object,
> you'll load all of Krita plugins. 

Why would that be?
If I have a layered bitmap shape in my kword, we talked about providing 
features of krita in kword. But just because krita has all features as 
plugins does not mean kword will have to be able to use all of them. The 
different applications will have most core functionality in those apps 
themselves; I would not like to see a histogram or the filters in kword. 
Perhaps not even the gradient tool.

> And even without Krita, I think the 
> number will be larger:
> * Six or more colorspaces
> * Shapes are essentially an open-ended category, but I'd be surprised
> if we have as few as twenty shape plugins
> * Lots of tools, too.
> * plugins for resources like gradients, patterns and clipart

You are seriously mixing up things.
We were talking about tools and about shapes and loading times. Stating 
that if krita supplies a tool that that will automatically mean we have 
to dlopen all kritas plugins is ludicrous. I hope that was not your 
intention at least.
I need to instantiate a tool object in the toolmanager and thats the only 
thing that stops us from loading tools on demand. If krita supply a tool 
thats unfriendly enough to load all plugins krita has then I think you 
forgot what the advantage of plugins is.

> And at the same time, we want to keep our trademark short startup time.
> Anyway, if I find some time, I'll look into this issue. I think it's
> pretty easy to solve in a generic way for all KOffice resources using a
> little indirection and a bit of conceptual help from David :-).

Nobody is saying we will loose our startup time. If things are slow; then 
optimize. But not based on what you think might be slow.  Standard rule 
of premature optimization.
You are just thinking that we for some reason will have hundreds of 
plugins to load on startup and you apparently thing that if tools / 
shapes should not be loaded on demand then I imply that krita can't load 
things on demand either. Both are wrong.

So;
- supply bigger libraries with more shapes/tools and don't force the krita 
idea of dozens of libraries upon all apps in koffice.
- load krita plugins on demand
- load tools on startup
- load shapes on startup; which is for free since they are in the same lib 
as tools.
- make sure that instantiating a tool does not end up in loading all 
plugins for that application.

-- 
Thomas Zander

[Attachment #5 (application/pgp-signature)]

_______________________________________________
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]