From: Tito D. C. <ti...@da...> - 2007-02-19 16:19:15
|
Tiennou, I'm trying to commit some code (basically fixups). Hope this will be ok with your multi-document trunk. Bye Tito -- Physics is reverse engineering |
From: tiennou <tie...@gm...> - 2007-02-19 18:26:44
|
Le 19 f=C3=A9vr. 07 =C3=A0 17:19, Tito Dal Canton a =C3=A9crit : > Tiennou, I'm trying to commit some code (basically fixups). Hope this > will be ok with your multi-document trunk. Please do ;-) I'm still picking on a way to convert all this stuff =20 into multi document... I guess you were right, changing to a wxDocument oriented approaches =20 is a real pain, because Shapes and ShapesEditor must be separated, =20 and much things have to be redone... One of the things that bother me is that I could use what has been =20 done, but I need to convert your BigEndianBuffer stuff to a =20 wxDataStream to put reading and loading into the LoadObject/=20 SaveObject methods of wxDocument... I haven't been able to find a =20 tutorial on this (except in the wxWidgets book, which I don't have). tiennou |
From: Tito D. C. <ti...@da...> - 2007-02-19 19:05:16
|
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, 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/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'll look at wxDocument too and try to produce some ideas, and will let you know if I have some. In the meantime, maybe you could write 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. We could also go with your previous multi-document approach, but I'm not sure it's a good way to do it... I prefer the wxDocument way (no matter how difficult it could be to convert existing code) because I think the code would be a lot nicer and more organized. Yeah, I should have started with that already in mind. Happy hacking Tito -- Physics is reverse engineering |
From: tiennou <tie...@gm...> - 2007-02-19 19:41:22
|
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... |
From: tiennou <tie...@gm...> - 2007-02-19 18:55:16
|
(Sorry I'm sending this again, I got bounced by SF's Mailman...) Le 19 f=C3=A9vr. 07 =C3=A0 17:19, Tito Dal Canton a =C3=A9crit : > Tiennou, I'm trying to commit some code (basically fixups). Hope this > will be ok with your multi-document trunk. Please do ;-) I'm still picking on a way to convert all this stuff =20 into multi document... I guess you were right, changing to a wxDocument oriented approaches =20 is a real pain, because Shapes and ShapesEditor must be separated, =20 and much things have to be redone... One of the things that bother me is that I could use what has been =20 done, but I need to convert your BigEndianBuffer stuff to a =20 wxDataStream to put reading and loading into the LoadObject/=20 SaveObject methods of wxDocument... I haven't been able to find a =20 tutorial on this (except in the wxWidgets book, which I don't have). tiennou |