Subject: Re: some more info on multi-view list crash
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Sat Nov 25 2000 - 18:47:50 CST
On Sat, 25 Nov 2000, Mike Nordell wrote:
> Martin Sevior wrote:
> > I think what is happenning is that that fl_AutoNum is trying to start two
> > lists based on the same shd and id number. I think this can be fixed by
> > checking to see if there is already a list defined in the vector of lists
> > in pd_Document.
>
> That would be a fix, but I think it's only a fix for the symptom, not the
> problem. If feasible I'd really like to work on a fix for the problem
> instead of the symptom.
It isn't even a fix. You are exactly right about circular dependencies.
This is the cause of our trouble combined with the fact that the view is
also the controller.
Much of the code that's in fl_BlockLayout should really be
moved to pd_Document.cpp. fl_AutoNum.cpp
should be moved down to the the piecetable and become pd_AutoNum.
I'll commit some patches that do some refactoring to remove the
circularities. This code is basically a work around the issues you've
mentioned. However as far as I can see they work to first order. I can't
get abi crashes anymore in the List code with just the toolbar buttons.
This is too much work to do right now and can wait till after 0.7.12 which
will be really cool for our users (and our bragging rights) see next post.
Cheers
Martin
>
> So, here's my quick analysis and opinions on this:
>
> When telling the AW to create a new list by clicking a toolbar button, this
> order goes to the View, and then the View is responsible for carrying out
> that order. That's one error. A View should only be what it's name implies.
> It should never be able to modify it's document in a "clean" world. But
> since the view in this case doubles as controller, we regrettably have to
> deal with it. But, we can enforce that a view may never request a document
> change by any other means than a *direct* user interaction (as opposed to an
> indirect interaction, e.g. a notification event).
>
> Another error is that there are circular dependencies between e.g.
> PD_Document and fl_Blocklayout (with a few other classes also entangled in
> this).
>
> Yet another error is that (apparently) some classes are allowed to modify
> the document when it gets notification events regarding that same document.
> Yet again, circular dependencies. There should be only one entity at the
> time allowed to modify the document. Currently any number of notified
> enities can change the document in the middle of a notified update. That's
> begging for trouble. The current situation allows the view to tell
> fl_BlockLayout to start a new list. That one in turn tells the document to
> changeStruxFmt which calls the piece table which calls the document telling
> it to notify the documents listeners. One of those listeners is (indirectly)
> again calling fl_BlockLayout that indirectly again tells the document to
> notify it's listeners of an update...
> I hope I'm getting though here.
>
>
> So, what are my ideas about this?
>
> 1. Disallow the pt_PieceTable to generate notifications (to the document).
> Since it's the document itself that initiates these changes it's itself
> perfectly capable of notifying listeners when an update has occured. This
> would remove one source of circularity.
>
> 2. Since View doubles as controller in this case, require that it only
> requests document modification from the document itself. The controller part
> of the view if perfectly capable of telling the document what insertion
> point or selected range(s) it currently has (if any). If we currently don't
> have a data type for selections (Range) we'll have to create a (composable)
> such.
>
> 3. Make the document class' interface complete. For the problem at hand it's
> the PD_Document that should have the method StartList, and that one should
> only notify it's listeners (conceptually views) when that update operation
> is complete.
>
> Did it make any sense? Comments?
>
> /Mike - please don't cc
>
>
This archive was generated by hypermail 2b25 : Sat Nov 25 2000 - 18:47:56 CST