Menu
▾
▴
shapefusion-devel
|
From: tiennou <tie...@gm...> - 2007-03-09 11:12:22
|
I'm trying to find a solution to the ankward wx installation on OSX... I think that I'll add my frameworks to the Product page, and add a note that they are needed for compilation, because it is much easier to tell users to install wx.framework in /Library/Frameworks than make them twiddle with ShapeFusion precompiled headers settings, include directories, and others... If you are fine with this, then I'll add my two frameworks somewhere on the project page... But I'm having compatibility problems ;-) You are still using 2.6.*, and I'm using 2.8.2 for development... When using __WXDEBUG__ framework, I just have some warnings about the fact that wxRect.Inside() is deprecated (can be changed to Contains ()), but when linking with the release framework, I get errors about this, and the fact that wxOPEN is not defined (replaced by wxFD_OPEN in 2.8). So I would like to know if it is possible for you to upgrade... In other news, I've bought the "Cross-platform GUI programming with wxWidgets", so I will have more information on the Document/View framework... tiennou |
|
From: Tito D. C. <ti...@da...> - 2007-03-10 00:08:59
|
On Fri, 2007-03-09 at 12:12 +0100, tiennou wrote: > I'm trying to find a solution to the ankward wx installation on OSX... > I think that I'll add my frameworks to the Product page, and add a > note that they are needed for compilation, because it is much easier > to tell users to install wx.framework in /Library/Frameworks than make > them twiddle with ShapeFusion precompiled headers settings, include > directories, and others... I don't think that's a great problem. Because we will release a statically linked binary, and if one wants to compile from Xcode, he will probably know how to tell the project where to find everything needed. And also, wx installations will be pretty the same everywhere I guess, so no changhe should be needed at all. Am I wrong? > If you are fine with this, then I'll add my two frameworks somewhere > on the project page... I'm reluctant about this... Let's see if we can avoid it. > But I'm having compatibility problems ;-) > You are still using 2.6.*, and I'm using 2.8.2 for development... When > using __WXDEBUG__ framework, I just have some warnings about the fact > that wxRect.Inside() is deprecated (can be changed to Contains()), but > when linking with the release framework, I get errors about this, and > the fact that wxOPEN is not defined (replaced by wxFD_OPEN in 2.8). So > I would like to know if it is possible for you to upgrade... Damn it, I feared that. I'd need to either compile wx from source or reinstall a more recent ubuntu. I'd really like to avoid either, since I have a very robust, stable and strongly personalized system. Actually I begin to have quite a number of reason to upgrade, but I'm waiting until something happens (e.g. something VERY important to upgrade, or hard disk crash---let's hope the former). I'm quite conservative on upgrades, you see. I see that wxOPEN is used just 3 times in ShapesView (excluding ShapesEditor), so let's find a way to do the trick. #ifdef? As for Inside(), I don't seem to have Contains(). But WHY THE HELL do they need to change such an API name! > In other news, I've bought the "Cross-platform GUI programming with > wxWidgets", so I will have more information on the Document/View > framework... That's cool. T -- Physics is reverse engineering |
|
From: tiennou <tie...@gm...> - 2007-03-12 18:19:39
|
Le 10 mars 07 =C3=A0 01:08, Tito Dal Canton a =C3=A9crit : > On Fri, 2007-03-09 at 12:12 +0100, tiennou wrote: >> I'm trying to find a solution to the ankward wx installation on =20 >> OSX... >> I think that I'll add my frameworks to the Product page, and add a >> note that they are needed for compilation, because it is much easier >> to tell users to install wx.framework in /Library/Frameworks than =20 >> make >> them twiddle with ShapeFusion precompiled headers settings, include >> directories, and others... > I don't think that's a great problem. Because we will release a > statically linked binary, and if one wants to compile from Xcode, he > will probably know how to tell the project where to find everything > needed. And also, wx installations will be pretty the same =20 > everywhere I > guess, so no changhe should be needed at all. Am I wrong? This will mainly depend where people install their wx source... For example, I put mine in /Volumes/myHD/Sources/Others/wxWidgets =20 which means that : - Xcode project in /Volumes/myHD/Sources/Others/wxWidgets/src/=20 wxWindows.xcodeproj - precompiled header is in /Volumes/myHD/Sources/Others/wxWidgets/=20 include/wx/wxprec.h - bundled wx icon in /Volumes/myHD/Sources/Others/wxWidgets/src/mac/=20 carbon/wxmac.icns Oh I guess we really need something more OSXyy from wx... I'll add some info for MacOS X in the INSTALL file... > >> If you are fine with this, then I'll add my two frameworks somewhere >> on the project page... > I'm reluctant about this... Let's see if we can avoid it. > >> But I'm having compatibility problems ;-) >> You are still using 2.6.*, and I'm using 2.8.2 for development... =20 >> When >> using __WXDEBUG__ framework, I just have some warnings about the fact >> that wxRect.Inside() is deprecated (can be changed to Contains()), =20= >> but >> when linking with the release framework, I get errors about this, and >> the fact that wxOPEN is not defined (replaced by wxFD_OPEN in =20 >> 2.8). So >> I would like to know if it is possible for you to upgrade... > Damn it, I feared that. I'd need to either compile wx from source or > reinstall a more recent ubuntu. I'd really like to avoid either, =20 > since I > have a very robust, stable and strongly personalized system. =20 > Actually I > begin to have quite a number of reason to upgrade, but I'm waiting =20 > until > something happens (e.g. something VERY important to upgrade, or hard > disk crash---let's hope the former). I'm quite conservative on =20 > upgrades, > you see. Hmm, guess I can downgrade instead, until you upgrade your distro... (I'm wondering what was the wxMac support in wx2.6...) Or I can release stuff using the wx debug version... > I see that wxOPEN is used just 3 times in ShapesView (excluding > ShapesEditor), so let's find a way to do the trick. #ifdef? As for > Inside(), I don't seem to have Contains(). But WHY THE HELL do they =20= > need > to change such an API name! That's right that I found this very *funny*. Guess they had a pretty =20 good reason... >> In other news, I've bought the "Cross-platform GUI programming with >> wxWidgets", so I will have more information on the Document/View >> framework... > That's cool. (I think you're gonna laugh at me, but if you're looking for it, you =20 can go take a look to http://en.wikipedia.org/wiki/WxWidgets (Grr, I =20 should have looked better...) But this wasn't really worth the effort... The chapter about Document/=20= View is only the making-of of the docview sample, so there is not =20 really more information about it than that...) tiennou= |
|
From: Tito D. C. <ti...@da...> - 2007-03-11 18:59:32
|
I think I fixed the ShapesBitmapToImage bug. It was triggered by the BitmapView and the SequenceView. Basically, in some cases, when the color table was changed they still kept the old bitmap which sometimes required a palette with more colors. Let's see if it comes up again. T -- Physics is reverse engineering |
|
From: Tito D. C. <ti...@da...> - 2007-03-13 18:25:29
|
I noticed that the new ShapeFusion doesn't handle non-shapes files very well. I added a check for too small files (I also backported it to 0.3) but the problem is another. It's the fact that if ShapesDocument fails to load a shapes file, nobody will care and ShapeFusion will crash. I guess we have to return false somewhere to tell about loading failures. But where? I could not find it within my wxDoc documentation. Bye T -- Physics is reverse engineering |
|
From: tiennou <tie...@gm...> - 2007-03-13 20:15:15
|
Le 13 mars 07 =C3=A0 11:56, Tito Dal Canton a =C3=A9crit : > I noticed that the new ShapeFusion doesn't handle non-shapes files =20 > very > well. I added a check for too small files (I also backported it to =20 > 0.3) > but the problem is another. It's the fact that if ShapesDocument fails > to load a shapes file, nobody will care and ShapeFusion will crash. I > guess we have to return false somewhere to tell about loading =20 > failures. > But where? I could not find it within my wxDoc documentation. I was having this thought while moving this stuff to Doc/View =20 framework... I guess it's possible to check for IsGood() at the end =20 of the loading, but that's right that's there is no obvious way of =20 telling that there is an error... I guess this need is enforced by the templates system, but I was =20 reluctant to put it completely in work, because it prevented me from =20 reading files that didn't ended in .shp2 (assuming that's the correct =20= extension...), nor using the Mac OS Type/Creator pair, because most =20 scenarios often have their own creator code... I'll ask in the wx-users Mailing list though... tiennou= |
|
From: tiennou <tie...@gm...> - 2007-03-16 13:10:50
|
Le 13 mars 07 =C3=A0 11:56, Tito Dal Canton a =C3=A9crit : > I noticed that the new ShapeFusion doesn't handle non-shapes files =20 > very > well. I added a check for too small files (I also backported it to =20 > 0.3) > but the problem is another. It's the fact that if ShapesDocument fails > to load a shapes file, nobody will care and ShapeFusion will crash. I > guess we have to return false somewhere to tell about loading =20 > failures. > But where? I could not find it within my wxDoc documentation. I got it working ;-). I' ve just overriden DoOpenDocument from =20 wxDocument to look at our mGoodData before telling that everything =20 went right... Others changes are that as soon as an error is reported, loading =20 stops, as currently we were still trying to load after an error... tiennou |
|
From: Tito D. C. <ti...@da...> - 2007-03-16 16:56:43
|
> I got it working ;-). I' ve just overriden DoOpenDocument from > wxDocument to look at our mGoodData before telling that everything > went right... > Others changes are that as soon as an error is reported, loading > stops, as currently we were still trying to load after an error... Nice... But you somehow deleted a piece of code of mine! Compare ShapesDocument.cpp revision 33 with 34, in ShapesDocument::LoadObject. The code that checks whether file size is too small has been removed. Was it intentional? I think it's an important check, since there aren't clear ways of identifying the shapes format. I'm pleased to see we are slowly converging to a stable 0.3-like app. Let me take care of bringing back commented code in ShapesView (bitmap and color table I/O to file). Bye T -- Physics is reverse engineering |
|
From: tiennou <tie...@gm...> - 2007-03-16 17:33:09
Attachments:
PGP.sig
|
Le 16 mars 07 à 17:56, Tito Dal Canton a écrit : >> I got it working ;-). I' ve just overriden DoOpenDocument from >> wxDocument to look at our mGoodData before telling that everything >> went right... >> Others changes are that as soon as an error is reported, loading >> stops, as currently we were still trying to load after an error... > Nice... But you somehow deleted a piece of code of mine! Compare > ShapesDocument.cpp revision 33 with 34, in ShapesDocument::LoadObject. > The code that checks whether file size is too small has been removed. > Was it intentional? I think it's an important check, since there > aren't > clear ways of identifying the shapes format. Yes, that was intentional, because I tough it would be more efficient to check for loading errors than checking size... But it's right a Shapes file with an invalid number of headers is definitely not a Shape files, so that can be added back... I'll do it now... > I'm pleased to see we are slowly converging to a stable 0.3-like app. > Let me take care of bringing back commented code in ShapesView (bitmap > and color table I/O to file). I've handled the bitmap part by adding to ShapeBitmap the ability to load itself from a wxImage. I'm feeling a little stuck with ColorTables though, due to the std::ofstream there... You can revert anything you don't like in my bitmap handling though, if you don't like it. tiennou |
|
From: Tito D. C. <ti...@da...> - 2007-03-16 17:46:41
|
On Fri, 2007-03-16 at 18:32 +0100, tiennou wrote: > Yes, that was intentional, because I tough it would be more efficient > to check for loading errors than checking size... But it's right a > Shapes file with an invalid number of headers is definitely not a > Shape files, so that can be added back... I'll do it now... Yep, if something can be said FOR SURE about a Shapes file it's that it can't be less than COLLECTIONS_IN_FILE * SIZEOF_collection_header! Bye T -- Physics is reverse engineering |
|
From: Tito D. C. <ti...@da...> - 2007-03-18 14:03:10
Attachments:
fixed_bug.png
|
I was comparing files written by trunk and 0.3, just for curiosity, when I noticed something interesting about sequence names and something bad about the "minimum light intensity" fixed field. As you may know, the 32-char strings contain usually more text than suggested by the first length byte. These are probably residual pieces of longer names given by Bungie folks. Well, 0.3 won't touch them (apart from setting a 0 at the right location) because it keeps the full 32 byte block in memory. Trunk, instead, will completely clear unused chars with zeroes, tearing off those "ancient" chars, because it converts to wxString internally. Not something we should worry about, just know it. IMO trunk behaviour is more correct, since it follows the "convert that ugly stuff to reasonable internal representation" phylosophy. As for minimum light intensity... Apparently numerical roundoff in ShapeFusion will progressively destroy minimum light intensity fields. I've written a small test program which takes an initial double value and simulates the effect of a succession of Shapes loading-saving. You can see the effect on the attached plot, where I've plotted the field value (starting from 0.5) versus the iteration. Each load-save cycle seems to decrease the value by 0.01! So working intensively on a Shapes file will eventually kill all minimum light intensities to 0. This severe bug seems a combined effect of our fixed-double conversion code (ShapesElements) and the fact that the wx field gets an event every time we write something to it (ShapesView). I don't have yet found how to solve it. Maybe we could just keep it as an integer value (between 0 and 0x10000) instead of converting to double. Damn wx, BTW ;-) Bye T -- Physics is reverse engineering |
|
From: Etienne S. <tie...@gm...> - 2007-03-18 19:45:06
|
2007/3/18, Tito Dal Canton <ti...@da...>: > I was comparing files written by trunk and 0.3, just for curiosity, when > I noticed something interesting about sequence names and something bad > about the "minimum light intensity" fixed field. > > As you may know, the 32-char strings contain usually more text than > suggested by the first length byte. These are probably residual pieces > of longer names given by Bungie folks. Well, 0.3 won't touch them (apart > from setting a 0 at the right location) because it keeps the full 32 > byte block in memory. Trunk, instead, will completely clear unused chars > with zeroes, tearing off those "ancient" chars, because it converts to > wxString internally. Not something we should worry about, just know it. > IMO trunk behaviour is more correct, since it follows the "convert that > ugly stuff to reasonable internal representation" phylosophy. I see what you mean, this was because I wanted to get rid of the wxConv stuff in ShapesEditor... Maybe we can add some debug message when we detect something longer that what is specified... BTW, I think this is currently broken, because you were using a value of "macintosh", which (from what I've read in the docs) is not a valid thing... Guess we can try fitting a nice unicode character in a sequence name, and see what happens... > As for minimum light intensity... Apparently numerical roundoff in > ShapeFusion will progressively destroy minimum light intensity fields. > I've written a small test program which takes an initial double value > and simulates the effect of a succession of Shapes loading-saving. You > can see the effect on the attached plot, where I've plotted the field > value (starting from 0.5) versus the iteration. Each load-save cycle > seems to decrease the value by 0.01! So working intensively on a Shapes > file will eventually kill all minimum light intensities to 0. This > severe bug seems a combined effect of our fixed-double conversion code > (ShapesElements) and the fact that the wx field gets an event every time > we write something to it (ShapesView). I don't have yet found how to > solve it. Maybe we could just keep it as an integer value (between 0 and > 0x10000) instead of converting to double. Damn wx, BTW ;-) We could also try to use the original fixed type, because other files uses fixed as well (I'm thinking of Sounds files, which I'm working on...). There are still a few things that do not seem to work correctly : - I think we lack updating the modified state of a Shapes file (by calling wxDocument::Modify()), because adding a bitmap doesn't enable the Save menu item automatically. - The wxTreeCtrl displays a strange UI behavior when browsed using arrows. A node can be expanded by pressing 'right', but pressing 'left' is equivalent to 'up', and it doesn't shrink a node back... I don't know if behavior is correct for you, if it's a problem with the way arrow events are handled , or if this is, again, wx fault... (and we need to file a bug report). (There is a thing that I like though, that pressing left on a node with no child takes me to its parent). - I've had a hard time with enabling file history, and it seems it won't work until we handle correctly file extensions. I've started work on handling Sounds files, but I'm waiting to have enough material to put on svn (and I'm currently away from my computer). 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