Menu
▾
▴
shapefusion-devel — Development-related list
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
(16) |
Mar
(65) |
Apr
(36) |
May
(9) |
Jun
|
Jul
(1) |
Aug
|
Sep
(3) |
Oct
(25) |
Nov
(14) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(10) |
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: tiennou <tie...@gm...> - 2007-03-02 14:45:33
|
Le 2 mars 07 =C3=A0 15:08, ti...@da... a =C3=A9crit : >> I think we can setup things like this : >> for groups: >> - trunk >> - 0.3 >> - (add more as version number increase) > So you want a branch for each version number? Is it worth? Not really after all... Shapefusion is still a small project with =20 only 2 different versions... I'll go with just stable and unstable/trunk ? >> for category : >> - GUI >> - Thing like Shapes Handling >> - (I don't know what else...) > General, Shapes, Sounds [, Physic Models] I'll go for General, Shapes for now, and add other as we have more =20 editors running... >> Maybe add you as a possible Assignee. > Ok. > >> Maybe disable Forums (this would force people to use the >> mailing lists). > Ok. > >> What do you think about that ? > That you've probably noticed I prefer coding rather than > administring projects :-) That's fine, since I'm a learning system administrator, so I like =20 things doing this... (And coding is fun too ;-)) > We also need to update the web page, but I'll do that as I'm > quite experienced with html/css/w3c and the like. That's fun, this is the part I'm less keen on ;-). I'll let you =20 handle this... tiennou |
|
From: tiennou <tie...@gm...> - 2007-03-02 14:40:14
|
Le 2 mars 07 =C3=A0 15:03, ti...@da... a =C3=A9crit : > Well done with the GUI. > >> I'll try again getting this on Windows this afternoon. > I say don't "waste" energy on that now. Let's get bug-free > code first! > >> I'm thinking to do the merging of trunk and >> wxDoc-branch... I'll do a branch of the current trunk >> named shapefusion-0.3, so we can continue correcting >> bugs for this version, and I'll merge back wxDoc-branch >> into trunk Do you agree with that ? Please commit anything >> you have not commited yet... > I'm reluctant to do this all now, as I've almost completed > my roadmap to 0.3... However it should not change things > that much, right? Just please wait until I've committed my > changes to wxDoc branch (I hope I can do it tonight). Ok on both, I'll wait until we have a stable version to get on =20 Windows, and I'll wait until you commit your changes to the branch. It should not completely break things, but commiting to a branch that =20= moved ought to create some funkyness in our working copies... tiennou |
|
From: <ti...@da...> - 2007-03-02 14:08:31
|
> I think we can setup things like this : > for groups: > - trunk > - 0.3 > - (add more as version number increase) So you want a branch for each version number? Is it worth? > for category : > - GUI > - Thing like Shapes Handling > - (I don't know what else...) General, Shapes, Sounds [, Physic Models] > Maybe add you as a possible Assignee. Ok. > Maybe disable Forums (this would force people to use the > mailing lists). Ok. > What do you think about that ? That you've probably noticed I prefer coding rather than administring projects :-) We also need to update the web page, but I'll do that as I'm quite experienced with html/css/w3c and the like. Tito |
|
From: <ti...@da...> - 2007-03-02 14:04:07
|
Well done with the GUI. > I'll try again getting this on Windows this afternoon. I say don't "waste" energy on that now. Let's get bug-free code first! > I'm thinking to do the merging of trunk and > wxDoc-branch... I'll do a branch of the current trunk > named shapefusion-0.3, so we can continue correcting > bugs for this version, and I'll merge back wxDoc-branch > into trunk Do you agree with that ? Please commit anything > you have not commited yet... I'm reluctant to do this all now, as I've almost completed my roadmap to 0.3... However it should not change things that much, right? Just please wait until I've committed my changes to wxDoc branch (I hope I can do it tonight). My system is a quite old Ubuntu Linux 6.06, cannibalized and configured to be as lightweight as possibile. No file manager, WindowMaker as window manager, conky as system monitor on the right, kernel 2.6.20 (I'm constantly upgrading because of the broadcom wireless driver evolving), Bluetooth with the Apple white mouse, a truly elegant touch :D And of course, just a plain xterm as terminal. Bye Tito |
|
From: tiennou <tie...@gm...> - 2007-03-02 12:47:47
|
I wish to set up Sourceforge project trackers, to help with bug reporting (I found a good load of them now that the GUI works) and tracking. I think we can setup things like this : for groups: - trunk - 0.3 - (add more as version number increase) for category : - GUI - Thing like Shapes Handling - (I don't know what else...) Maybe add you as a possible Assignee. Maybe disable Forums (this would force people to use the mailing lists). What do you think about that ? tiennou |
|
From: tiennou <tie...@gm...> - 2007-03-02 11:41:38
|
I got GUI working ! I just moved the code from MenuFileOpen to OnUpdate and this worked ;-). I've also fixed some issues about menu items, and updated the code to reflect your changes to trunk : Added FrameDelete and corrected ShapesElements classes destructors. The preferred way to access menu is now via the menubar pointer (or frame->GetMenuBar()). Sadly, I know see that saving is flawed; I got incorrect values back from the saved file... I'm testing saving again to see where things go wrong, but I suspect size calculation. I'll try again getting this on Windows this afternoon. I'm thinking to do the merging of trunk and wxDoc-branch... I'll do a branch of the current trunk named shapefusion-0.3, so we can continue correcting bugs for this version, and I'll merge back wxDoc-branch into trunk Do you agree with that ? Please commit anything you have not commited yet... tiennou |
|
From: tiennou <tie...@gm...> - 2007-03-02 10:12:27
|
Le 2 mars 07 =C3=A0 00:21, Tito Dal Canton a =C3=A9crit : > On Thu, 2007-03-01 at 21:34 +0100, tiennou wrote: >> I would prefer keeping modularity, because maybe one day this 32- >> collections-per-shapes-file could be lifted... >> That's just a thing, but creating an editor for Aleph One mean >> enhancements can be made to the files Aleph One uses (provided Aleph >> One team agrees), but that might be for a future time... > You're right. > > I think you were correct in moving ShapesEditor things to ShapesView. > That's what's intended: the *View contains the GUI. I'm trying to =20 > build > on Linux to reproduce the GUI bug, but I'm stuck in fixing bugs and > making my system like the new code. I guess you have =20 > wxUSE_STD_IOSTREAM > set to false... Of course I have it set to true ;-) Also =20 > utilities.h and > MyTreeItemData* are to be moved to Shapes/, they don't have a point in > being in the top level directory. May I commit these fixes when done? Yes, feel free to commit at anytime you feel is right. This is =20 cooperative development after all ;-) >> - Refactoring things about thumbnails, because there is a couple of >> code duplication out there, caused by the separation between Frames >> and Bitmaps... >> This limitation could be lifted by merging Frames and Bitmap at >> loading time, and splitting them again when saving. > Hmm, no. Let's keep bitmaps and frames well separated. Even if > ShapeFusion displays them in a very similar way, in Shapes logic they > are well defined entities... Bitmaps are chunks of pixels, frames are > bitmap "wrappers" that just *reference* a bitmap, but they are =20 > *not* to > be treated as bitmaps. I think that's an important distinction. So I > say, let's keep a little code duplication and respect the Shapes =20 > logic. > Also I think code duplication can be reduced to a great extent in the > future, we just need the right idea. That's what I think too... >> - Maybe they could be passed pointers to the std::vector so they >> could manipulate the structure directly, or something... > What I didn't like about the old trunk were those AddBitmap/AddFrame > methods in *Browser. Maybe we could make *Browsers more intelligent: > just give them the appropriate collection std::vector pointer; they =20= > will > do their best to display it as best as possibile when asked, and > automatically rebuild their caches when they detect some change. I =20 > need > to think about this... We could send events related to changes containing the new =20 std::vector pointer, which then trigger an event handler in the =20 Browsers code... > I managed to build! See the following screenshot... Looks like your =20= > GUI > bug is multiplatform ;-) > > http://altivec.fisica.indivia.net/shapefusion_wxdoc_first_test.png > > I had to do many fixes in the code, basically wxT's missing in every > wxLog and wxUSE_STD_IOSTREAM cases. Is it worth committing them? I've > also moved some files so I'm not sure what I have to do. I love the look & feel of your *nix ;-) What's that ? I thought that wxUSE_STD_IOSTREAM would be a problem for you, the =20 thing I found strange is why wxWidgets on OS X doesn't use this too... Yes, as I said, feel free to commit when you fix bugs (the wxT is me =20 not having good wxWidgets practices). In order to move things in svn, you need to issue a svn move (not =20 just mv), as svn will update your local copy information, and make =20 the actual mv. On some occasions (when the file you move has local =20 modifications, you will need to --force, because svn prevents that =20 due to the delete involved (a move is a svn copy/svn delete). I don't know if you did, but I'd recommend reading the subversion =20 book, as there is lot of interesting stuff in there... > Fortunately, the GUI bug seems trivial after all. > > The new code is not filling the main wxTreeCtrl at all, so what should > it display? ;-) You are just creating the root item, but it won't be > displayed because the tree control is created with the wxTR_HIDE_ROOT > flag. This is compatible with what's in the screenshot I made: you can > see the empty tree control on the left (white) and the dummy sizer on > the right (gray). Like the "empty" editor of the original trunk. I see what you mean... There is a discrepancy on OS X, the wxTreeCtrl =20= takes all the space on the window (not just the left part, it extends =20= up to the right side). I'll take a look at this when I have a better =20 grasp on GUI code... > In the original trunk, the tree is filled in > ShapesEditor::MenuFileOpen(), which is now completely commented out. I > think the filling can be done in ShapesView::OnCreate(), just after =20= > the > creation of the root item (make sure you can access the sequence =20 > names, > you need them). This will produce something more reasonable I hope :-) I'll take a look at this... I see that you made some changes to the =20 trunk, I'll try to backport them to the branch (that way I'll =20 exercise my svn skills ;-)). I've taken a look at compilation on Windows, but got stuck on =20 compiling wxWidgets... I'll try again when the branch-trunk merging =20 is done. tiennou= |
|
From: Tito D. C. <ti...@da...> - 2007-03-02 00:43:28
|
Fortunately, the GUI bug seems trivial after all. The new code is not filling the main wxTreeCtrl at all, so what should it display? ;-) You are just creating the root item, but it won't be displayed because the tree control is created with the wxTR_HIDE_ROOT flag. This is compatible with what's in the screenshot I made: you can see the empty tree control on the left (white) and the dummy sizer on the right (gray). Like the "empty" editor of the original trunk. In the original trunk, the tree is filled in ShapesEditor::MenuFileOpen(), which is now completely commented out. I think the filling can be done in ShapesView::OnCreate(), just after the creation of the root item (make sure you can access the sequence names, you need them). This will produce something more reasonable I hope :-) Tito -- Physics is reverse engineering |
|
From: Tito D. C. <ti...@da...> - 2007-03-02 00:26:12
|
I managed to build! See the following screenshot... Looks like your GUI bug is multiplatform ;-) http://altivec.fisica.indivia.net/shapefusion_wxdoc_first_test.png I had to do many fixes in the code, basically wxT's missing in every wxLog and wxUSE_STD_IOSTREAM cases. Is it worth committing them? I've also moved some files so I'm not sure what I have to do. Tito -- Physics is reverse engineering |
|
From: Tito D. C. <ti...@da...> - 2007-03-01 23:21:39
|
On Thu, 2007-03-01 at 21:34 +0100, tiennou wrote: > I would prefer keeping modularity, because maybe one day this 32- > collections-per-shapes-file could be lifted... > That's just a thing, but creating an editor for Aleph One mean > enhancements can be made to the files Aleph One uses (provided Aleph > One team agrees), but that might be for a future time... You're right. I think you were correct in moving ShapesEditor things to ShapesView. That's what's intended: the *View contains the GUI. I'm trying to build on Linux to reproduce the GUI bug, but I'm stuck in fixing bugs and making my system like the new code. I guess you have wxUSE_STD_IOSTREAM set to false... Of course I have it set to true ;-) Also utilities.h and MyTreeItemData* are to be moved to Shapes/, they don't have a point in being in the top level directory. May I commit these fixes when done? > I'm commiting right now... I really need help on this damn white- > background problem ;-). I think it would be better to keep the > separation between ShapesView and ShapesEditor, because GUI code is > awful, but if this is the only way... As before, it's the right way to do it I guess. > - Refactoring things about thumbnails, because there is a couple of > code duplication out there, caused by the separation between Frames > and Bitmaps... > This limitation could be lifted by merging Frames and Bitmap at > loading time, and splitting them again when saving. Hmm, no. Let's keep bitmaps and frames well separated. Even if ShapeFusion displays them in a very similar way, in Shapes logic they are well defined entities... Bitmaps are chunks of pixels, frames are bitmap "wrappers" that just *reference* a bitmap, but they are *not* to be treated as bitmaps. I think that's an important distinction. So I say, let's keep a little code duplication and respect the Shapes logic. Also I think code duplication can be reduced to a great extent in the future, we just need the right idea. > - Maybe they could be passed pointers to the std::vector so they > could manipulate the structure directly, or something... What I didn't like about the old trunk were those AddBitmap/AddFrame methods in *Browser. Maybe we could make *Browsers more intelligent: just give them the appropriate collection std::vector pointer; they will do their best to display it as best as possibile when asked, and automatically rebuild their caches when they detect some change. I need to think about this... Tito -- Physics is reverse engineering |
|
From: tiennou <tie...@gm...> - 2007-03-01 20:34:19
|
Le 1 mars 07 =C3=A0 12:54, Tito Dal Canton a =C3=A9crit : > Hi, I'm finally examining your branch and I'm happy to see what was > done. Good job! Code looks a lot more organized and clean (and I guess > it will be event better once we merge and all that). I'm glad you > decided to go back to std vectors. I read on the wxWidget site that wxList predated the time std:: was =20 cross-platform, so I though it would be better to use wx-things =20 instead of std:: ;-) > I have a comment on ShapesDocument. The member "mCollections" could > actually be a simple static array rather than a std::vector, since =20 > we'll > always deal with 32 collection slots. I would prefer keeping modularity, because maybe one day this 32-=20 collections-per-shapes-file could be lifted... That's just a thing, but creating an editor for Aleph One mean =20 enhancements can be made to the files Aleph One uses (provided Aleph =20 One team agrees), but that might be for a future time... > Also in ShapesDocument::SaveObject(), you say > ShapesCollection coll =3D mCollections[i]; > but it should be a pointer I guess. Hmm, I don't see this part, and the code in svn is out of date. Anyway, I tried getting the GUI working again by binding ShapesView =20 to ShapesEditor : I thought I could keep ShapesEditor and instanciate =20= it from ShapesView, passing it a pointer to the child frame. However =20 this crashed with an error I don't recall, so I moved everything from =20= ShapesEditor to ShapesView, and now I get a complete white background =20= (instead of the typical MacOS X background). I'm commiting so you can take a look at this, I'm afraid there is =20 still something I don't grasp in the wxWidgets way ;-) I'm not sure I correctly made the link between View and Document... I =20= replaced all instances of payload to ((ShapesDocument*)GetDocument)-=20 >, because that seemed the only way to retrieve the ShapesDocument =20 after loading, but as GUI doesn't work I can't test this. gdb told me =20= that it was a ShapesDocument so I casted it... I wish there was more =20 stuff about the Document/View framework on the net... > I think that ShapesLoaders classes could all go inside ShapesElements. > That would be the "master" file for the shapes editor. What about =20 > this? Yes, that can be done, but I thought that the ShapesElement class =20 could be renamed and kept separate, because it will prove to be =20 useful when I'll have a look at Sound files. But as it is just a =20 small debugging class, I will put ShapesLoaders and ShapesElement =20 inside ShapesElements... I'm commiting right now... I really need help on this damn white-=20 background problem ;-). I think it would be better to keep the =20 separation between ShapesView and ShapesEditor, because GUI code is =20 awful, but if this is the only way... I've been thinking about the different View/Browsers. I would like to =20= know what do you think about... - Refactoring things about thumbnails, because there is a couple of =20 code duplication out there, caused by the separation between Frames =20 and Bitmaps... This limitation could be lifted by merging Frames and Bitmap at =20 loading time, and splitting them again when saving. - Maybe they could be passed pointers to the std::vector so they =20 could manipulate the structure directly, or something... tiennou |
|
From: Tito D. C. <ti...@da...> - 2007-03-01 19:07:01
|
Hi, I'm finally examining your branch and I'm happy to see what was done. Good job! Code looks a lot more organized and clean (and I guess it will be event better once we merge and all that). I'm glad you decided to go back to std vectors. I have a comment on ShapesDocument. The member "mCollections" could actually be a simple static array rather than a std::vector, since we'll always deal with 32 collection slots. Also in ShapesDocument::SaveObject(), you say ShapesCollection coll = mCollections[i]; but it should be a pointer I guess. I think that ShapesLoaders classes could all go inside ShapesElements. That would be the "master" file for the shapes editor. What about this? That's all for now. Tito -- Physics is reverse engineering |
|
From: tiennou <tie...@gm...> - 2007-02-28 15:34:08
|
Le 28 f=C3=A9vr. 07 =C3=A0 15:11, ti...@da... a =C3=A9crit : > Sorry for the scarce partecipation, I'm next to an importan > exam and I'm doing brain time-sharing between multiple > disciplines... No problem about that... I wish I could let you > >> Are you satisfied with my naming conventions of the code I >> revamped ? Using mKeypointObscured as a member name and >> KeypointObscured() and SetKeypointObscured() as methods >> ? > I agree. Okay, so that's what I'll use... > >> I'm trying to get ShapesEditor to work again, and as they >> are numerous references to the old Shapes.h structs, I'm >> thinking about making all members public, because it >> would make it work with no change. On the other hand >> this would mean that my accessor stuff is useless, so >> I'm wondering ;-) > I say let's make all them public. It's not ideal, but we can > fix it later. I think I will change everything right now, because I've already =20 changed members name, so I'm stuck. >> I'm thinking about refactoring code from View/Browser, >> because there is numerous methods related to turning >> ShapesFrame/ShapesBitmap into images/thumbnails for >> viewing. I added these capabilities to ShapesBitmap (you >> can now call ShapeBitmapToImage and ImageThumbnail >> directly on them), but I need to add a pointer to a >> ShapesChunk in ShapesFrame in order to be able to access >> the associated ShapeBitmap- >>> ShapeBitmapToImage call... What do you think about it ? > I don't like this. IMO a ShapesFrame should not be able to > generate its own > wxImage, because it's linked to a ShapesBitmap in a "weak" > way (that is, you need to access the full chunk to realize > the link). I'm thinking about a new class that knows how to > convert ShapesBitmaps and ShapesFrames to wxImage. It could > be called for example ShapesRenderDevice or ShapesRenderer. > The nice thing about that would be just ONE SETTING for > "show transparent pixels", "view using color table", "smooth > thumbnails" and so on. We could just ask it "I need to > convert this bitmap/frame for viewing, could you do it?" and > it would create a wxImage with the correct display settings. > It could even cache thumbnails I guess. We could store a > pointer to this converter in ShapesView. Could it work? I think there is some need for a refactor in those parts of the code, =20= but yes, it can be delayed until we have a working wxDocument approach. I was just going overshot ;-) tiennou |
|
From: <ti...@da...> - 2007-02-28 14:12:01
|
Sorry for the scarce partecipation, I'm next to an importan exam and I'm doing brain time-sharing between multiple disciplines... > Are you satisfied with my naming conventions of the code I > revamped ? Using mKeypointObscured as a member name and > KeypointObscured() and SetKeypointObscured() as methods > ? I agree. > I'm trying to get ShapesEditor to work again, and as they > are numerous references to the old Shapes.h structs, I'm > thinking about making all members public, because it > would make it work with no change. On the other hand > this would mean that my accessor stuff is useless, so > I'm wondering ;-) I say let's make all them public. It's not ideal, but we can fix it later. > I'm thinking about refactoring code from View/Browser, > because there is numerous methods related to turning > ShapesFrame/ShapesBitmap into images/thumbnails for > viewing. I added these capabilities to ShapesBitmap (you > can now call ShapeBitmapToImage and ImageThumbnail > directly on them), but I need to add a pointer to a > ShapesChunk in ShapesFrame in order to be able to access > the associated ShapeBitmap- > >ShapeBitmapToImage call... What do you think about it ? I don't like this. IMO a ShapesFrame should not be able to generate its own wxImage, because it's linked to a ShapesBitmap in a "weak" way (that is, you need to access the full chunk to realize the link). I'm thinking about a new class that knows how to convert ShapesBitmaps and ShapesFrames to wxImage. It could be called for example ShapesRenderDevice or ShapesRenderer. The nice thing about that would be just ONE SETTING for "show transparent pixels", "view using color table", "smooth thumbnails" and so on. We could just ask it "I need to convert this bitmap/frame for viewing, could you do it?" and it would create a wxImage with the correct display settings. It could even cache thumbnails I guess. We could store a pointer to this converter in ShapesView. Could it work? Tito |
|
From: tiennou <tie...@gm...> - 2007-02-28 08:13:34
|
Hi ! I need to have a talk with you about those damn accessors, and the way I write code... Are you satisfied with my naming conventions of the code I revamped ? Using mKeypointObscured as a member name and KeypointObscured() and SetKeypointObscured() as methods ? I'm trying to get ShapesEditor to work again, and as they are numerous references to the old Shapes.h structs, I'm thinking about making all members public, because it would make it work with no change. On the other hand this would mean that my accessor stuff is useless, so I'm wondering ;-) I'm thinking about refactoring code from View/Browser, because there is numerous methods related to turning ShapesFrame/ShapesBitmap into images/thumbnails for viewing. I added these capabilities to ShapesBitmap (you can now call ShapeBitmapToImage and ImageThumbnail directly on them), but I need to add a pointer to a ShapesChunk in ShapesFrame in order to be able to access the associated ShapeBitmap- >ShapeBitmapToImage call... What do you think about it ? tiennou |
|
From: tiennou <tie...@gm...> - 2007-02-27 10:23:37
|
Le 26 f=C3=A9vr. 07 =C3=A0 22:28, Tito Dal Canton a =C3=A9crit : > On Mon, 2007-02-26 at 17:22 +0100, tiennou wrote: >> This is because I've built my own framework for use with ShapeFusion, >> which is not available right now... >> I can send it to you, but the debug version I use is quite big >> (500Mb). And as I needed room, I deleted my wxWidget source tree, >> which means I cannot rebuild it now... >> I will look into this as soon as I finish this. It shouldn't be a big >> problem of making it work with the current wx source tree. > Ah, thought that. No problem, we'll fix it before 0.3/0.4 release. > > >> just (almost) completed loading/saving, now ShapeFusion 0.3 is able >> to read the files I save with my branch version. One bad point =20 >> though, >> frames are not displayed, there is the red X instead, so there is >> obviously something wrong... I'm currently rewriting accessors for >> Insert/Delete, so I can move to upgrading your View/Browser =20 >> widgets... > Curiouser and curiouser! > > I'm thinking about committing my latest changes to the main trunk, > releasing 0.3 and then going on and completely merging the wxDoc =20 > stuff. > Then release 0.4. Is this good? Please do ! I'm reconverting back my wxList to std::vector, because it is less of =20= a pain to use... I'm having some thought on accessors for the new classes... Doesn't =20 it seems like overkill to have Getters/Setters for those ? I finished redoing View/Browser stuff, but I can't seem to get it to =20 show... The window is still grey, but I get the "can't expand hidden =20 root" assert... Strange. I'm commiting 2 times, because svn won't let me move/delete files =20 with modifications tiennou= |
|
From: Tito D. C. <ti...@da...> - 2007-02-26 23:26:46
|
On Mon, 2007-02-26 at 17:22 +0100, tiennou wrote: > This is because I've built my own framework for use with ShapeFusion, > which is not available right now... > I can send it to you, but the debug version I use is quite big > (500Mb). And as I needed room, I deleted my wxWidget source tree, > which means I cannot rebuild it now... > I will look into this as soon as I finish this. It shouldn't be a big > problem of making it work with the current wx source tree. Ah, thought that. No problem, we'll fix it before 0.3/0.4 release. > just (almost) completed loading/saving, now ShapeFusion 0.3 is able > to read the files I save with my branch version. One bad point though, > frames are not displayed, there is the red X instead, so there is > obviously something wrong... I'm currently rewriting accessors for > Insert/Delete, so I can move to upgrading your View/Browser widgets... Curiouser and curiouser! I'm thinking about committing my latest changes to the main trunk, releasing 0.3 and then going on and completely merging the wxDoc stuff. Then release 0.4. Is this good? Bye! Tito -- Physics is reverse engineering |
|
From: tiennou <tie...@gm...> - 2007-02-26 16:23:15
|
Le 26 f=C3=A9vr. 07 =C3=A0 16:00, ti...@da... a =C3=A9crit : > Hi, great job with the wxDoc branch. I have some comments... > > I think the Shapes stuff is becoming really complicated with > respect to the old implementation. I wonder if all those > separate classes like ShapesColor are really necessary... > Since we aren't going to extend their functionalities with > new features, I'd prefer keeping the code as compact as > possible rather than spreading it over too many files. If > there was a thing I liked about the previous implementation, > it was the very fact that all Shapes related code was kept > inside the class Shapes, which was independent from > wxWidgets :-) Also, I think that the Files subdirectory > could be dropped and everything could be kept in the Shapes > one. As you wish ;-) I will recompress everything when I think there won't =20= be anything big going in there... > Since your commit fixing the Xcode project, I can't build on > OS X anymore. I seem to lack wx.framework or something like > that... How can I fix this? I'm using a rather old version > of wxWidgets, will it work by just upgrading? This is because I've built my own framework for use with ShapeFusion, =20= which is not available right now... I can send it to you, but the debug version I use is quite big =20 (500Mb). And as I needed room, I deleted my wxWidget source tree, =20 which means I cannot rebuild it now... I will look into this as soon as I finish this. It shouldn't be a big =20= problem of making it work with the current wx source tree. > I've checked out the wxDoc branch and will examine it more > carefully, and willy try to correct the Linux makefile. I just (almost) completed loading/saving, now ShapeFusion 0.3 is able =20= to read the files I save with my branch version. One bad point =20 though, frames are not displayed, there is the red X instead, so =20 there is obviously something wrong... I'm currently rewriting =20 accessors for Insert/Delete, so I can move to upgrading your View/=20 Browser widgets... I'm glad there is not much left to do to make this (almost) final ;-). tiennou |
|
From: <ti...@da...> - 2007-02-26 15:01:17
|
Hi, great job with the wxDoc branch. I have some comments... I think the Shapes stuff is becoming really complicated with respect to the old implementation. I wonder if all those separate classes like ShapesColor are really necessary... Since we aren't going to extend their functionalities with new features, I'd prefer keeping the code as compact as possible rather than spreading it over too many files. If there was a thing I liked about the previous implementation, it was the very fact that all Shapes related code was kept inside the class Shapes, which was independent from wxWidgets :-) Also, I think that the Files subdirectory could be dropped and everything could be kept in the Shapes one. Since your commit fixing the Xcode project, I can't build on OS X anymore. I seem to lack wx.framework or something like that... How can I fix this? I'm using a rather old version of wxWidgets, will it work by just upgrading? I've checked out the wxDoc branch and will examine it more carefully, and willy try to correct the Linux makefile. Bye Tito |
|
From: tiennou <tie...@gm...> - 2007-02-23 15:26:12
|
Le 23 f=C3=A9vr. 07 =C3=A0 15:51, ti...@da... a =C3=A9crit : >> I'm in a big need of help there, because I'm thinking of >> Object- Orienting the Marathon structs so I could just >> write ShapesDocument::LoadObject(), and it will issue >> ShapesChunk::LoadObject(), which will work as a a chain... >> I need some help from you to (re)do that. > Mumble... Chunks are well-defined, self-consistent, > independent data blocks. ShapesChunk::LoadObject() would > need an offset and size to load its chunk, then it could > just grab the data block from the stream and decode it (like > happened with BigEndianBuffer). So I guess > ShapesDocument::LoadObject() could first load the 32 > collection headers and then issue as many > ShapesChunk::LoadObject() as needed, giving them the right > offsets and sizes. I hope wxDoc supports random stream > access! I've almost completely moved to the new ShapesDocument architecture. =20 Things left to do are : - calculation of scale factors - the part involving CalcActualNumberOfViews - debuggin' Actually, this goes this way : ShapesDocument::LoadObject is called with a wxInputStream as =20 argument, which call COLLECTIONS_PER_FILE times =20 ShapesCollection::LoadObject. ShapesCollection::LoadObject looks for offsets/lengths, create one or =20= two ShapesChunk, passing it offsets and lengths, then calls LoadObject. ShapesChunk::LoadObject load ShapesColorTables, ShapesBitmap, =20 ShapesSequences, and ShapesFrames, passing them offsets and calling =20 LoadObject on them. > However, couldn't you just reproduce what Shapes::Shapes() > did inside ShapesDocument::LoadObject()? That code is well > tested. This is a straight copy of code from Shapes::Shapes() and =20 Shapes::LoadShapesChunk(), converted to use wxInputStream for random =20 access (and wxDataInputStream for data reading). The few problems I have is errors, as I don't know what I should do =20 when something goes wrong... I thought of using exceptions, but =20 implemented mGoodData to stick with what was done. >> I'm also trying to remove everything std (vectors >> principally) and changing them into wxList subclasses to >> ensure portability... It won't be a problem for you ? > Well I think std is more portable than wx. But it should not > be a problem. Are you also using wxFile instead of std > streams? Yes, wxInputStream, because the wxDocument::LoadObject methods uses =20 this, from which I create a wxDataInputStream, for big-endian loading =20= of data. I've had some problems with long, so I switched these to wxInt32 > I guess we are actually rewriting ShapeFusion from scratch. > Will *Browser and *View classes work? I really hope so. I'll take a look at these as soon as I'm able to open Evil shapes =20 without a "This may not be a Marathon Shapes file" ;-). But since the layout is basically the same, it should not be a problem. I'm commiting my work right now so you can have a look... tiennou |
|
From: <ti...@da...> - 2007-02-23 14:52:05
|
> I'm in a big need of help there, because I'm thinking of > Object- Orienting the Marathon structs so I could just > write ShapesDocument::LoadObject(), and it will issue > ShapesChunk::LoadObject(), which will work as a a chain... > I need some help from you to (re)do that. Mumble... Chunks are well-defined, self-consistent, independent data blocks. ShapesChunk::LoadObject() would need an offset and size to load its chunk, then it could just grab the data block from the stream and decode it (like happened with BigEndianBuffer). So I guess ShapesDocument::LoadObject() could first load the 32 collection headers and then issue as many ShapesChunk::LoadObject() as needed, giving them the right offsets and sizes. I hope wxDoc supports random stream access! However, couldn't you just reproduce what Shapes::Shapes() did inside ShapesDocument::LoadObject()? That code is well tested. > I'm also trying to remove everything std (vectors > principally) and changing them into wxList subclasses to > ensure portability... It won't be a problem for you ? Well I think std is more portable than wx. But it should not be a problem. Are you also using wxFile instead of std streams? I guess we are actually rewriting ShapeFusion from scratch. Will *Browser and *View classes work? I really hope so. Bye, Tito |
|
From: tiennou <tie...@gm...> - 2007-02-21 14:16:54
|
Le 21 f=C3=A9vr. 07 =C3=A0 13:50, ti...@da... a =C3=A9crit : >> Hmm, my approach had the >> advantage of not separating the Shapes/ ShapesEditor > Actually, I see this separation as a good thing... > >> =46rom my point of view, I'm not really fond of the >> wxDocument way, but it can be enhanced by subclassing >> stuff, so that's not really a problem... > There are many things I don't like about wx, too. But from > experience I think that the final result is good if you try > to follow wx accurately. Let's see if this holds also with > this wxDoc stuff... I'm commiting right now. I've made some progress... I think reusing the ShapeEditor code won't =20= be a problem, but as I need loading Shapes file to continue, I moved =20 to trying to actually load data the wxDoc way... I'm in a big need of help there, because I'm thinking of Object-=20 Orienting the Marathon structs so I could just write =20 ShapesDocument::LoadObject(), and it will issue =20 ShapesChunk::LoadObject(), which will work as a a chain... I need =20 some help from you to (re)do that. I'm also trying to remove everything std (vectors principally) and =20 changing them into wxList subclasses to ensure portability... It =20 won't be a problem for you ? tiennou |
|
From: <ti...@da...> - 2007-02-21 12:50:50
|
> Hmm, my approach had the > advantage of not separating the Shapes/ ShapesEditor Actually, I see this separation as a good thing... > From my point of view, I'm not really fond of the > wxDocument way, but it can be enhanced by subclassing > stuff, so that's not really a problem... There are many things I don't like about wx, too. But from experience I think that the final result is good if you try to follow wx accurately. Let's see if this holds also with this wxDoc stuff... Bye Tito |
|
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: 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 |
