Kdevelop base design (was Re: file views)

[John Birch]

On Wed, 05 Jul 2000, you wrote:
> On Wed, 5 Jul 2000, Falk Brettschneider wrote:
(snip)
> > BTW: It seems you've got concrete ideas about the whole architecture of
> > kdevelop... Could you explain a little bit and give us a survey?
> > Mainly the core, the implementation of the doc-view model is quite
> > unclear to me concerning to the aim to avoid such a huge master class
> > like CKDevelop.
> > I tend to believe there must be several 'helper' classes which split
> > CKDevelop... but how can we do that?
>
> In general, I think that most subsystems should be independent of the main
> binary, i.e. they have a clear interface through which one communicates
> with them. Currently, there is the quite generic KDevComponent. This could
> be subclassed to more specific ones, e.g. a version control interface
> or a source parser interface. The corresponding components are only
> created on demand. For example, a project should define a main language
> and a version control system. When the project is loaded, one asks
> the trader for a source parser that fits and loads it. One asks for
> a version control component and loads it. Similar for the debugger.
>
> The tricky part of the job is to find the right abstractions. For
> example, from Sandy's commits I conclude that he wants to support
> Java :-) So a source info interface would have to be general enough to
> support multiple languages (e.g. Java has interfaces, whereas C++ has
> multiple inheritance). Another example is the version control interface
> which is really braindead in KDevelop 1.2 (I've written it, so I can say
> this ;-) Have you ever wondered why the file views need so long to
> display when cvs support is switched on? It's because VersionControl
> is stateless and therefore has to read the file CVS/Entries for each
> file in the directory!
>
> > I tend to believe there must be several 'helper' classes which split
> > CKDevelop... but how can we do that?
>
> Weeell, it's all more difficult than I expected. In my experience,
> you have the following constraints:
>
> 1) All static actions have to be created before the createGUI() call
>    in the KDevelop class.
>
> 2) All components have to be added to KDevelop's factory after the
>    createGUI() call.
>
> 3) Creating static actions requires access to KDevelop::actionCollection()
>    (except for KXMLGUIClients which must be registered
>    with KDevelop's factory)
>
> 4) Many methods in KDevelop's core need access to the list of
>    components (in order to notify them about added files and so on)
>
> If you find a concept that works and fulfills these constraints,
> it would be nice :-)
>
> Bernd.

I'm working on the subclassed approach locally. I think it'll work out but 
it's more complicated in some ways.

Basically Kdevelop is a fixed set of parts that have a well defined interface 
(ie debugger interface, grepview 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. 
(But then I wondered about supporting mixed language projects and thought 
ugggh !!)
Presenting how the parts could be selected is also unclear.

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.

There is also an unspecified set of plugins that have a small interface. 
Haven't got any yet but I'm sure some could be dreamed up. :-) The user can 
download new plugins and add them to the plugin set to be loaded. (Some sort 
of pick list would be needed (ie two panes of icons, selected and other - 
drag icon to selected and it'll get loaded) Having got further than that in 
the thinking.

I've also wondered at the use of MDI (Hi Falk :-). You're going to hate me, 
but I've been thinking that dockviews really makes MDI redundent. I think the 
MDI view adds another level of user confusion, but I can change my mind :-)) 
I'm pretty sure the user just wants to see one or more views into one or more 
files at the same time.

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.

If it pans out better than I currently have it, then I'll ask for a new 
branch to go further with these ideas.

Any arguments? :-)

jbb

PS I'm not yet totally convinced about this direction.