[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 10:10:57
Message-ID: 200606101210.57456.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 10 June 2006 11:35, Boudewijn Rempt wrote:
> > 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.
...
> 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.

What does the tool manager have to do with loading _all_ plugins 
dynamically?  I honestly don't see what the need is to fork a tool 
manager.
You are very well capable of loading all plugins Krita has dynamically by 
still reusing  the kofficeui toolmanager. And if not; tell me what I'm 
missing.

To reiterate; the kofficeui toolmanager can not load things dynamically; 
as I stated before.
Why you keep reading that as "Nothing can be loaded dynamically" seems to 
be based completely on the idea that two things that use plugins should 
behave the same.  Sorry, thats just not a good argument. You can reuse 
technology just fine and pass a boolean 'preload' to the registry or 
something as simple as that. I'm sure you can come up with a solution.

Why oh why are you so rigid and unmoving about me having to throw away 2 
days work on a toolmanager just because you don't want to have one 
boolean in a registry class.
Bah. :(

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

Outspoken? Stating that I want to measure before I leap to conclusions? I 
was under the impression that 'many eyeballs' meant that everyones input 
was appreciated and questions are NOT seen as critique or even disrespect 
but as respect for work done.

> 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.
Time is short; thats why measuring performance hits first and then 
refactoring to fix speed problems is the only correct approach.

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