Kdevelop base design (was Re: file views)
bernd at physik.hu-berlin.de
Thu Jul 6 11:33:21 UTC 2000
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 !!)
> 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
> 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.
More information about the KDevelop-devel