file views

[Bernd Gehrmann]

On Wed, 5 Jul 2000, Falk Brettschneider wrote:

> Hi,
> 
> Bernd Gehrmann wrote:
> 
> > Are the file views no more used for project management?
> 
> Yeah... good point, where should the file views be placed within the
> architecture?
> I suppose a good document-view-approach is always in mind, I mean to
> keep the views apart from the file data.
> 
> 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.