*view & *doc relationship

[Tim Rohrer]

Hauke,

>From what I've read, I think you want the doc class to manipulate the data. 
The user will cause the manipulation via interations with the view, but, the
doc methods will make the actual changes and update files, etc. Perhaps someone
else can confirm this for us?

I'm not quite as far along as you are.  My lack of understanding right now has
to do with getting the data from the doc to the view.  Take the "simple" example
of the html viewer.  I changed the base class for the view to KHTMLWidget. 
Now, I set a QString to point to an html file and create a new instance of
KHTMLWidget in the App constructor.  Of course, to get it to view, I have to do
a show() which creates a new window seperate from the main view.  I am not
connecting the app, doc, and views.  Perhaps I shouldn't be creating the
instance of KHTMLWidget in the App constructor but if I don't, how do I get the
data in? Perhaps I'm mixing things up to much? I've been working my way through
the tutorials and the kscribble example but maybe I need to go back to that and
put more time into it.

I just noticed a couple more articles came in on this thread.  I'll give them a 
read.

Tks
-tgr  


On Thu, 06 Apr 2000, you wrote:
> Hi, Tim!
> 
> I have started working with C++ and kdevelop and - rest assured - the
> document/view model was and still is confusing to me as well. The basic
> idea
> certainly is to separate the actual content of the document - text or
> gif-files in your case - from their representation on the screen. So
> your document class may contain a member variable of type QString
> containing text or a list of pointers to gifs as well as methods for
> saving and restoring this structure. The View class provides different
> methods to show these contents on the screen - let' say a
> "drawTextInCircularShape(const char* text)" function. You can open
> different views of the same data with the document structure untouched -
> e.g. a bar chart and a pie chart in the case of numerical data.
> 
> The point where I need help (and which could do with some examples in
> the documentation) is: Let's say the App class has a menu entry to
> change some data which opens a dialog. Who changes the document's data?
> Do I hand over a pointer or reference of the doc's data to the dialog
> which changes it? Does the dialog create some data and call a
> "doc->changeData(float xyz)"? Who looks after the update of the view
> after the data has been changed?
> 
> The doc-view model certainly has its merits, but it definitely
> complicates matters, so please help us novices!
> 
> Thanks, Hauke

-- 
Tim Rohrer
tgrohrer at metbymail.com
http://www.metbymail.com/~rohrer