[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Re: MDI style
- From: "Ben Fowler" <ben.the.mole@xxxxxxxxx>
- Date: Sat, 2 Sep 2006 17:54:49 +0100
- Subject: Re: [XaraXtreme-dev] Re: MDI style
On 01/09/06, Gerry Iles <GerryI@xxxxxxxx> wrote:
I have made some changes to the CCamView class so that it calls SetFrame
rather than keeping its own member variable (and got rid of
GetParentFrame()). This still seems to run perfectly happily on linux
so could one of you with a Mac apply this patch to your local copy and
see if it improves things...?
Works for me.
wxWidgets "window.cpp" most certainly cannot create a wxWindowMac
without a parent. Do we know why it is trying to?
I am creating a CCamDocMDIChildFrame at line 1790 of camelot.cpp .
I have added this trace statement to the (otherwise empty) constructor:
TRACE( _T("CCamDocMDIChildFrame::CCamDocMDIChildFrame(
wxDocument:%p, wxView:%p, wxMDIParentFrame:%p, id:%d, title:\"%s\",
pos:%p, size:%p, type%ld, name:\"%s\" ) Called"),
doc, view, frame, id, title.c_str( ), &pos, &size, type,
name.c_str( ) );
and it produces output as:
CCamDocMDIChildFrame::CCamDocMDIChildFrame( wxDocument:0x3931a400,
wxView:0x3931e600, wxMDIParentFrame:0x39170e00, id:-1, title:"Child
Frame", pos:0xbfffe008, size:0xbfffe000, type541072960, name:"frame" )
Called
If you find that you are calling this or some other constructor with a
wxMDIParentFrame of 0, then we probably need to guard the call to it
with an ERROR2 and find out why.
Ben
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Ben Fowler
Sent: 01 September 2006 12:16
On 01/09/06, Gerry Iles <GerryI@xxxxxxxx> wrote:
> It looks to me like we are not actually handling the wxView/frame
> connection as wx intends.
> CCamView::OnCreate is creating a frame with
> wxGetApp().CreateChildFrame(
> pDoc, this ) but storing the pointer in its own member variable rather
> than in the wxView baseclass member (presumably via wxView::SetFrame).
> Why it works better in wxGTK than in wxMac is presumably down to the
> underlying implementation but "fixing" this may get it working well
> enough for now...
I agree on all counts.
I am not quite sure what is the simplest fix at this stage - I would
be tempted to eliminate the "own member variable" (or carefully
document what is going on), and use the SetFrame/GetFrame mechanism.
Indeed depending on what the "frame" constructor does, we might not
even need to call SetFrame(); however, it would be unwise to take all
this action for the sake of one platform.
> From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx]
> On 01/09/06, Phil Martin <phil@xxxxxxxx> wrote:
> > Phil Martin wrote:
> > Did I say "MFC-style"? I meant "MDI-style".
> >
> > In the long run we probably don't really want XaraLX to have
> > MDI-style windows on the Mac because that's not the Mac way of doing things.
> > So the question is, should we persist with trying to get the MDI-style
> > working for now, so that we can make other parts of the program more
> > stable or should we change to a different window layout now, which
> > will undoubtedly introduce a new layer of Mac-only bugs.
>
> I fear that MFC does have a certain amount to do with it. Speaking
> concisely, I think that we should only try to get MDI working if you
> want one parent window/many independent document windows; in other
> words a "Tools" palette or panel. Chlor
> http://sourceforge.net/projects/chlor/ does this, and it is an
> effective way of using Cocoa.
>
> We don't have many users at the moment, but I suspect that when we do,
> they will request a tabbed interface, one that will probably be not
> dissimilar to the wxGTK document handing. It might be an idea to leap
> frog over the other possibilities and either move to, or bolt-on, that
> interface.
>
> If this is impractical (or not what you want) then we will probably
> have to eliminate the Parent-Child coupling and have the document
> windows all Parents (or all Children, I am not sure which is the
> better way) in which each has a full set of toolbars and tools, and
> does drawing in a client area. There aren't many precedents for such a
> Mac application, and Xara Xtreme (to give it its new name) might even
> have a claim to be the first commercial quality one, when it is
> finished; but you might want to have a look at wxMud - though I have
> not been able to get it to link on the Mac.
>
> I can't really propose a roadmap here, and I will re-iterate that now
> we have a build system we should be thinking about getting the Xara
> Xtreme (Mac) in front of artists, and would tentatively propose
> therefore, doing the least (smallest) thing that could plausibly work
> http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html , which
> may well be to press on with the Mac style (Parent/Child) MDI in the
> short term with a view to replacing it, after some thought, with an
> interface style determined by Gaddesden Place. I suspect that this
> will need an architectural decision at some point and it might be good
> at this point to concentrate on collecting information to help that.