Kdevelop base design (was Re: file views)

[Bernd Gehrmann]

On Thu, 6 Jul 2000, John Birch wrote:
> 
> I'm working on the subclassed approach locally. I think it'll work out but 
> it's more complicated in some ways.

What do mean with 'subclassed approach'?
> 
> Basically Kdevelop is a fixed set of parts that have a well defined interface 
> (ie debugger interface, grepview interface) 

grep doesn't need a special interface :-)

> There is a preferrred service 
> selection when loading the service so that any service can have more that one 
> implemetation installed at any given time. (ie more that one debugger part 
> could be written) Also this could be used when the project language changes. 

Quite analogous to finding a viewer for a given mime-type.

> (But then I wondered about supporting mixed language projects and thought 
> ugggh !!)

Naaah :-)

> Having separate interface means that more of the "logic" of kdevelop can be 
> put into the connection between the parts. But that's also a two edged sword. 
> Too many connections = a mess.

Separate interfaces for different parts make sense where special
interfaces are needed. Many parts (like the existing ones except
for the debugger) can share a common (and comparatively rich)
interface which is needed anyway for plugins that you don't know anything
about yet.

> One more thing, the layout should be held in config files so that the part 
> has no knowledge of the layout (not even a hint :-) It just produces widgets 
> for our "layout" manager to handle.

The layout manager needs to know _something_. Otherwise it can only
arrange the parts from left to right or top to bottom or with
random coordinates :-) Not very nice.

Bernd.