*view & *doc relationship
Ralf.Nolden at post.rwth-aachen.de
Thu Apr 6 11:31:33 UTC 2000
Hauke Hildebrandt wrote:
> The doc-view model certainly has its merits, but it definitely
> complicates matters, so please help us novices!
Ok, I´ll try to give some hints here, although I´m sure that reading the
tutorial handbook and the sources for the scribble example would do the
job as well because we already experienced there is some difficulty here
since I introduced that doc/view class model. The thing is that for MFC
programmers switching to Unix this is already known to them, but not for
Unix starters. I myself had some trouble to understand it first but you
will get a good idea once you know how to work with it.
As Hauke already said, the idea is to separate the data of the document
and the viewing/manipulation of the document with the app/view/doc class
When you think of a document normally, you imagine yourself the
displaying already, e.g. how it looks like. But from the programmer´s
point of view (which should be yours ;-) a document is a set of data of
whatever kind that is stored in a file. The program that wants to
operate with a certain document has to provide a method to read and
write the file, at least to read it; writing if manipulation is allowed.
Now, the doc class is more a container that takes the file contents and
stores it in memory. For this it has to provide a data section and
methods to read and write the file. Further, manipulation on the data
structure in the memory (the private data member of the doc class)
should be only allowed through defined methods by this doc class.
A view is a widget that is specialized on displaying a document that it
is supposed to understand (i.e. it can display the doc-class data
structures). For that, the view class gets a pointer to the document
that it is connected to on creation. This means that an application
first creates a doc-instance (which can be empty when you make a new
file or can be filled by reading in a file) and then it creates a
view-class instance that gets a pointer to the document. Further, the
doc class has a list of pointers to views that display it´s data
structures and methods to add and remove a view; so you have to add the
new created view to the document by inserting a pointer to the view list
of the document.
The view now is shown either as an MDI child widget for MDI apps or as a
main widget, which means that per top-level window only one view is
allowed (which is SDI). The view class now implements things like mouse
movements, keyboard events, paint events etc. by overwriting the QWidget
virtual event handlers. As the view has a pointer to it´s document it
paints the document contents in it´s paint-event and changes the
document structure according to actions like mouse events or keyboard
events trought the document pointer. Then it calls the paint-event resp.
the updateAllViews() method that calls all views in the list to repaint
themselves. This makes it possible to have
a) multiple views connected to the same document
b) manipulation onto the document data over a class-structure by defined
methods (information hiding)
c) repainting all views synchronously over the document pointer from the
view where the manipulation took place. This view knows nothing about
other views of the same document, it just tells the document, hey,
you´ve been changed, tell every other view you may have to update the
contents it´s displaying.
Again, the tutorial, although an MDI application for KDE 2, makes it
much easier to understand the doc-view model and why this is necessary.
Hope this helps you to get along with it.
The KDevelop Project
Email: rnolden at kdevelop.de
More information about the KDevelop