[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-10 9:35:02
Message-ID: 200606101135.04397.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 10 June 2006 09:48, Thomas Zander wrote:

> 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.

No? You wouldn't like to be able to have an embedded Krita shape with an 
adjustment layer? That implies a filter -- which, without lazy loading, 
implies loading all filters.

> Perhaps not even the gradient tool.

Then we must find a way to load things on demand, or disable loading things, 
or make it possible to define a matrix of plugins that needs to be loaded for 
particular apps. Because if the singletons responsible for loading 
tools/shapes/etc do a ktrader query, they'll load everything they find; all 
tools, all shapes, all everything of the type they're responsible for. 
KOffice-wide.

> You are seriously mixing up things.

Don't think so: plugins are plugins. It'd prefer to have one pattern or 
strategy for loading plugins, whatever the type.

> 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.

We're not talking classloaders and jarfiles here -- if you instantiate a Krita 
image, you'll instantiate the filter, paintop and colorspace singletons. If 
you want a paint tool for your embedded krita image, you'll load all tools. 
The only thing you won't get are the view plugins -- that is, kparts with 
a .rc file. Although you might want some of them, for instance to resize the 
krita image.e

> 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.

The advantages of plugins are:

* Modular development -- make it easy to develop one particlar piece of 
functionality separately, compile it separately and install it separately.
* Modular development -- make it easy for third parties to add bits of 
functionality without having to hack the application itself. This is in 
itself immensely valuable for attracting third-party hackers: it's the basis 
of the success of the Gimp, Photoshop and MS Office.
* Modular development -- make sure functionality is in clear, separated chunks 
that don't interfere with other bits of functionality
* Keep the core application small and understandable

Unless you implement the kind of dialog Digikam has where the user has to 
disable plugins (a horribly solution, I feel), you won't get lazy loading.

Now, if you just use a Krita flake, say the paintdevice flake, you will get 
filters, tools and paintops. Otherwise you cannot do anything with the 
content of the flake, except displaying it.

> 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.

Sorry, but if you're going to be outspoken, I will too. Nonsense! Poppycock!
This is not about optimization, this is about architecture and design. Getting 
the basics right up-front.

> 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.

No: we will have many plugins. Perhaps not hundreds, but more than a dozen for 
certain. Sure, Krita can load things on demand on its own. But that leads to 
code duplication -- Krita loads its tools using its own tool manager, the 
rest of KOffice using another. Not a Good Thing.

> So;
> - supply bigger libraries with more shapes/tools and don't force the krita
> idea of dozens of libraries upon all apps in koffice.

Nothings forces anyone to split their functionality into many plugins, even 
Krita doesn't do that. We've a big defaulttools plugins with many tools, and 
another with all the selection tools. But: as soon as you make it possible to 
add functionality through plugins, you no longer control the number, size or 
fine-grainedness of the plugins your application loads. 

I for one hope that we get so many third-party plugins, shapes, tools and 
whatever for all of KOffice that the best plugin loading system will be 
brought to its knees.

> - 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.

But, well, if you don't want me to code lazy loading for plugins and shapes, 
while still showing the relevant ui for adding all available and relevant 
shapes to the document, no problem. Time is short as it is.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi

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