lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Child documents [Was: Adding open files to MDI "Window" menu]


From: Vadim Zeitlin
Subject: Re: [lmi] Child documents [Was: Adding open files to MDI "Window" menu]
Date: Fri, 30 Jan 2009 23:57:16 +0100

 Hello again,

 I'm continuing my trip in the past of this mailing list archives and by
now I reached the discussion about the child documents. To give you more
context, the full contents of the message I'm replying to can be seen at

        http://lists.nongnu.org/archive/html/lmi/2008-03/msg00038.html

I don't think the thread it makes part of has anything else related to this
subject though.


On Thu, 20 Mar 2008 22:30:40 +0000 Greg Chicares <address@hidden> wrote:

GC> All I want is "if your parent closes, then you close" semantics,
GC> with the loosest possible physical coupling. Here's an untested
GC> sketch of how this might be implemented. (It changes the ABI,
GC> which rules it out for the current wx version.)

 I don't think this can be implemented in any reasonable way without
breaking ABI and it also seems a kind of a new feature which belongs to the
trunk [first] so for now I've implemented it mostly following your sketch.

GC> Class wxDocument already has this member:
GC> 
GC>     wxDocument* m_documentParent;
GC> 
GC> which AFAICT is used nowhere yet.

 In fact I initially wanted to implement the entire child document concept
at LMI level as it seems to be rather specific to it and there be no
particular problems with doing it outside of wx. But the presence of this
m_documentParent made me change my mind as, as long as we have it anyhow,
we'd better use it in at least some way. And it also seems to mean that
someone else at least planned to do something similar so it's not something
which only LMI risks to ever use.

GC> I would propose adding
GC> 
GC>     wxList<wxDocument> m_documentChildren;
GC> 
GC> and changing three member functions as follows:
GC> 
GC> wxDocument::wxDocument()
GC>   // This is needed only for closing and deleting later.
GC>   if(m_documentParent)
GC>     m_documentParent->m_documentChildren->Insert(this);
GC> 
GC> wxDocument::~wxDocument()
GC>   if(m_documentParent) {
GC>     m_documentParent->m_documentChildren->DeleteContents(true);
GC>     // Maybe DeleteAllViews should be called on each child?
GC>     m_documentParent->m_documentChildren->Clear();
GC>     }
GC> 
GC> wxDocument::Close()
GC>   for each element 'e' of m_documentChildren
GC>     do e->Close() /* or e->DeleteAllViews() ? */

 I've done this but modified Close() to call OnSaveModified() for all the
children and then effectively close them all in OnCloseDocument() as it
seems to be better: if any child refuses to close, nothing is done at all
whereas with the approach above some children would have been already
closed.

 You may wonder why didn't I change OnSaveModified() itself to call the
same method for all child documents. In fact I'm still not sure if this
wouldn't be the right thing to do but I hesitate to do it because
OnSaveModified() is also called from OnNewDocument() and it doesn't seem
clear what, if anything, should be done with the child documents when a
new parent document is (re)created.

GC> and adding just one new function:
GC> 
GC>   wxDocument* wxDocument::GetParent() const {
GC>     return m_documentParent;
GC>     }

 I called it GetDocumentParent() for consistency with the other methods.

GC> That's all there is to it, AFAICS.

 It is not totally clear yet how should opening/saving the child documents
work. Right now I didn't constrain them at all but I'm not sure if this is
really correct. To try to see if it is, I'd like to better understand the
only use-case which we currently have, namely the use of child documents in
LMI so let me rephrase your explanation of the consolidated view of the
census files to check if I understood it correctly:

---------------------------------------------------------------------------
 The consolidated view is not a view of CensusDocument because it doesn't
change when the document changes. In fact there can be several such views
corresponding to several versions of CensusDocument open at the same time.
So they must correspond to their own EphemeralCensusDocument and not the
main CensusDocument. EphemeralCensusDocument can't be saved because it's
always subordinate to an existing CensusDocument (why does it have to be so
though?) and hence it can't be opened neither because there are no files
containing it.
---------------------------------------------------------------------------

 Is this right?


 Supposing it is, I think the child document concept does make sense for
them. But I also wonder if we shouldn't explicitly support documents which
can't be opened/saved and even if we shouldn't consider that all child
documents like this. The latter seems to make sense because if you can open
a child document from a file then you shouldn't close it when the parent
document closes, i.e. it's a contradiction and the only solution is to not
make any documents corresponding to disk files child documents at all.

 Also, while I think that it may be possible to modify the child documents
(although it isn't in LMI case it might in the example of an image embedded
in a word processor), it still doesn't make sense to save them to disk
files. Instead all changes to them (if allowed at all) should be reflected
in their parent document.

 Do you agree with this?
 
 Thanks!
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]