Re: [Shapefusion-devel] status

[tiennou <tie...@gm...>]

Le 19 f=C3=A9vr. 07 =C3=A0 20:05, Tito Dal Canton a =C3=A9crit :

> On Mon, 2007-02-19 at 19:26 +0100, tiennou wrote:
>> I guess you were right, changing to a wxDocument oriented approaches
>> is a real pain, because Shapes and ShapesEditor must be separated, =20=

>> and
>> much things have to be redone...
> Doh! It's real!
>
>> One of the things that bother me is that I could use what has been
>> done, but I need to convert your BigEndianBuffer stuff to a
>> wxDataStream to put reading and loading into the LoadObject/=20
>> SaveObject
>> methods of wxDocument... I haven't been able to find a tutorial on
>> this (except in the wxWidgets book, which I don't have).
> Yeah, wx documentation sucks. Tried to get the book with p2p? ;-)

I will ;-)

> I'll look at wxDocument too and try to produce some ideas, and will =20=

> let
> you know if I have some. In the meantime, maybe you could write =20
> your own
> Sounds editor by starting a new wxDocument app, then we could "learn"
> from it the best way to convert ShapeFusion. And eventually we could
> merge your editor with ShapeFusion (that should be easy since we only
> need to put the classes together). Once we understand how the whole
> thing works I can recode BigEndianBuffer and all if you don't feel.

Actually, I've created a branch for that purpose... I'm happilly =20
copying things from the docview sample to this branch. You can check =20
it out by issuing
svn co https://shapefusion.svn.sourceforge.net/svnroot/shapefusion/=20
branches/wxDoc-branch

I'm setting all this up, and I'm creating empty ShapeDocument/=20
ShapeEditor files as they should look for wxDocument-ing.

> We could also go with your previous multi-document approach, but =20
> I'm not
> sure it's a good way to do it... I prefer the wxDocument way (no =20
> matter
> how difficult it could be to convert existing code) because I think =20=

> the
> code would be a lot nicer and more organized. Yeah, I should have
> started with that already in mind.

I didn't knew about wxDocument until you told me, too ;-)

Hmm, my approach had the advantage of not separating the Shapes/=20
ShapesEditor, but doesn't actually track open/created documents, so =20
that prevent ShapeFusion from prompting "There are unsaved changes... =20=

Would you like to Cancel/Don't Save/Save ?".
 =46rom my point of view, I'm not really fond of the wxDocument way, =20
but it can be enhanced by subclassing stuff, so that's not really a =20
problem...