Menu
▾
▴
shapefusion-devel
|
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: <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 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: 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: 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-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 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: 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-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: 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= |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X