John Birch John.Birch at xtra.co.nz
Mon Dec 11 17:52:51 UTC 2000

On Mon, 11 Dec 2000 22:44, Bernd Gehrmann wrote:
> On Mon, 11 Dec 2000, John Birch wrote:
> > In the current implementation, you must write an editor manager otherwise
> > somewhere a component will blow up when it tries to access it and this
> > may not be in a component that we write...
> No, you don't have to write an editor manager, as there is already
> one (although it again has a design bug which I fixed about 53 weeks
> ago in the HEAD branch and fixed partially in the 1.x branch about
> 55 weeks ago). And of course it has to be loaded when the user works on
> a project - an IDE without a possibility to edit files is pointless.

You've missed the point of what I was trying to say, For people reading this 
thread only from this point on, be warned that this paragraph doesn't seem to 
make that much sense taken out of context like this. You will need to reread 
the original post to put it back into context. But I'll try to explain it 
another way.

Because the component pointers are held in the component base class, then 
every component "knows" about the other components. So these components must 
be instantiated in the system. (It is _possible_ it may work without one, but 
not likely).

This makes it a lot harder to change from using one type of component (eg an 
editorManager part) to a new type of (as yet unspecified and unwritten) 
component that managers the editors. In fact making this sort of change will 
require the base framework to change and I believe that is not correct.

So my cardinal rule is that any component knows nothing of another components 
existance. It just reacts to events given to it.

I would like us to be in a position to put sets of components up on the web 
and allow people to download their preferred options, without having to 
download a new base framework. Not to mention allow people to send us new 
sets of components. This is possible in the current implementation but I 
believe it is harder than it needs to be...


Of course if people rewrite a component and don't honour the events _other_ 
components send, then the system won't work well either, but that's another 
story... :-)

to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«

More information about the KDevelop-devel mailing list