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-21 20:13:21
|
Le 21 mars 07 =C3=A0 20:18, Tito Dal Canton a =C3=A9crit : > On Wed, 2007-03-21 at 18:45 +0100, tiennou wrote: > >> Yes, I will take care of building the OS X binary, I'm trying to link >> wx statically, so that I can tag shapefusion and release this... >> I'll do some testing too, after I have done with that. >> I'll take a look at your "fixed" fix ;-), because I need it for >> sounds... > Now is certainly better than before, but keep in mind that the bug was > triggered because the wxTextCtrl sends a "spurious" event when you set > its value from code. We probably wouldn't have noticed if that was not > the case. Maybe this won't be the case with the sound editor. BTW I > don't really understand the wxTextCtrl behaviour, why does it need to > trigger an event when set by program? It brings more problems than > solutions IMO, and you can't disable it. I'll take a look at how you did things, but I want to train my wx =20 reflexes before, and creating the Sound editor GUI is a good start. I think there's a bunch of things to update in the ShapesView code, =20 now that we moved to wxDoc, and some things could be simplified... >> Currently, I'm trying to learn wx-interface-making ;-). I've finished >> Sounds loading code, and I'm setting up the View from the sketches I >> made... > Nice. Gregory Smith suggested to look at Wail for a good GUI. I don't > remember Wail but maybe you can see it. I got Wail sourcecode next to ShapeFusion, as reference stuff... Alas =20= I can't run it because it's Metrowerks Powerplant stuff, I don't have =20= Codewarrior, and can't run it because I got no Classic on a MacBook =20 Pro :-(. I'll try with my old iBook (and give a spin to Anvil too, it's been =20 too long ;-)) tiennou= |
|
From: Tito D. C. <ti...@da...> - 2007-03-21 19:19:03
|
On Wed, 2007-03-21 at 18:45 +0100, tiennou wrote: > Yes, I will take care of building the OS X binary, I'm trying to link > wx statically, so that I can tag shapefusion and release this... > I'll do some testing too, after I have done with that. > I'll take a look at your "fixed" fix ;-), because I need it for > sounds... Now is certainly better than before, but keep in mind that the bug was triggered because the wxTextCtrl sends a "spurious" event when you set its value from code. We probably wouldn't have noticed if that was not the case. Maybe this won't be the case with the sound editor. BTW I don't really understand the wxTextCtrl behaviour, why does it need to trigger an event when set by program? It brings more problems than solutions IMO, and you can't disable it. > Actually, I got some ideas about some changes in the interface. I > thought of putting a tab panel for > ColorTables/Bitmaps/Frames/Sequences, instead of putting this into the > wxTreeCtrl. This could allow for shortcuts in a menu to easily switch > between the data of a given chunk... Not a bad idea... I'll think about it. > I would also like the interface not to "move" so much. Currently when > there's nothing selected, there's nothing displayed, and the editors > show up only when there has been a selection... I agree, you select a frame and suddenly your selection jumps away because thumbnails are rescaled and reflushed. I don't like that. Maybe we could just keep the space for editors always visible. I did so because 1024x768 on my iBook is not much for ShapeFusion, and I wanted to avoid wasting space. > I've made some sketches of my "ideal" GUI, I can put them somewhere if > ou want to take a look at them. Please do. > Currently, I'm trying to learn wx-interface-making ;-). I've finished > Sounds loading code, and I'm setting up the View from the sketches I > made... Nice. Gregory Smith suggested to look at Wail for a good GUI. I don't remember Wail but maybe you can see it. > Yes, it's right that if there's features missing, there will be > questions ;-). I think the missing thing at the moment is colortable > exporting. Yep, and I'll fix it. T -- Physics is reverse engineering |
|
From: tiennou <tie...@gm...> - 2007-03-21 17:46:15
|
Le 21 mars 07 =C3=A0 18:16, Tito Dal Canton a =C3=A9crit : > Hi, I completed my 0.3 roadmap and would like to release. As you can > see I've included the fix for fixed fields (I've fixed fixed =20 > fields! :-) > Sorry). Can you test it a bit before? Also, would you like to take =20 > care > of building the OS X binary? Yes, I will take care of building the OS X binary, I'm trying to link =20= wx statically, so that I can tag shapefusion and release this... I'll do some testing too, after I have done with that. I'll take a look at your "fixed" fix ;-), because I need it for =20 sounds... > I'll take care of porting the SequenceView changes to trunk. I'm not > completely satisfied with the SequenceView though, particularly about > the small arrows to edit frame indexes. It's slow and annoying. I want > to add a button to set all frame indexes at once: you specify a frame > index to start and ShapeFusion will take a block of N frames and fill > the sequence with them. Do you have alternative ideas about that =20 > panel? Actually, I got some ideas about some changes in the interface. I =20 thought of putting a tab panel for ColorTables/Bitmaps/Frames/=20 Sequences, instead of putting this into the wxTreeCtrl. This could =20 allow for shortcuts in a menu to easily switch between the data of a =20 given chunk... I would also like the interface not to "move" so much. Currently when =20= there's nothing selected, there's nothing displayed, and the editors =20 show up only when there has been a selection... I've made some sketches of my "ideal" GUI, I can put them somewhere =20 if ou want to take a look at them. Currently, I'm trying to learn wx-interface-making ;-). I've finished =20= Sounds loading code, and I'm setting up the View from the sketches I =20 made... > My personal "contribute plan" before 0.4 includes a color table editor > and a state-of-art color reduction algorithm to use when importing > bitmaps. Of course we have to make sure the new wxdoc code brings all > features of 0.3. Yes, it's right that if there's features missing, there will be =20 questions ;-). I think the missing thing at the moment is colortable =20 exporting. tiennou |
|
From: Tito D. C. <ti...@da...> - 2007-03-21 17:16:15
|
Hi, I completed my 0.3 roadmap and would like to release. As you can see I've included the fix for fixed fields (I've fixed fixed fields! :-) Sorry). Can you test it a bit before? Also, would you like to take care of building the OS X binary? I'll take care of porting the SequenceView changes to trunk. I'm not completely satisfied with the SequenceView though, particularly about the small arrows to edit frame indexes. It's slow and annoying. I want to add a button to set all frame indexes at once: you specify a frame index to start and ShapeFusion will take a block of N frames and fill the sequence with them. Do you have alternative ideas about that panel? My personal "contribute plan" before 0.4 includes a color table editor and a state-of-art color reduction algorithm to use when importing bitmaps. Of course we have to make sure the new wxdoc code brings all features of 0.3. Bye T -- Physics is reverse engineering |
|
From: tiennou <tie...@gm...> - 2007-03-19 10:47:46
|
Le 19 mars 07 =E0 11:17, ti...@da... a =E9crit : >> 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... > Well, "macintosh" was just a guess of mine :-) However > it always worked at least with Italian accents. It does > not work with the degree symbol, which appears correct > on Linux but gives an infinity symbol on MacOS > (SequenceView). After reading some wx Docs, (and a quick look at wikipedia), it =20 appears that you were right : http://en.wikipedia.org/wiki/Mac_OS_Roman I'll try fixing this as soon as I get back to my computer, hopefully =20 in 2 days. > >> 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...). > Yep, I mean that. A fixed value in range 0-1 is represented > as an integer ranging from 0 to 0x10000 (provided I > understand > correctly how fixed works...). > > I don't know if the wxTree behaviour I see is correct... > Seems quite ok to me. If you can't close a node from the wxTree, then you see what I meant... tiennou= |
|
From: <ti...@da...> - 2007-03-19 10:19:00
|
> 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... Well, "macintosh" was just a guess of mine :-) However it always worked at least with Italian accents. It does not work with the degree symbol, which appears correct on Linux but gives an infinity symbol on MacOS (SequenceView). > 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...). Yep, I mean that. A fixed value in range 0-1 is represented as an integer ranging from 0 to 0x10000 (provided I understand correctly how fixed works...). I don't know if the wxTree behaviour I see is correct... Seems quite ok to me. > 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). Nice. Bye, T |
|
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 |
|
From: Tito D. C. <ti...@da...> - 2007-03-18 14:03:10
|
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: 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: tiennou <tie...@gm...> - 2007-03-16 17:33:09
|
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 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 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: tiennou <tie...@gm...> - 2007-03-16 12:30:01
|
Here is the response I got from wx-users... Guess we'll have to cope
with this by making our own wxDoc subclass... I'll look into this.
Début du message réexpédié :
> De : Klaas Holwerda <db...@nl...>
> Date : 16 mars 2007 10:27:49 HNEC
> À : wx-...@li...
> Objet : Rép : Doc/View framework, and stopping LoadObject
> Répondre à : wx-...@li...
>
> tiennou wrote:
>
>> I guess I should return something wrong somewhere in LoadObject,
>> but I can't return NULL (compiler give me an error), so what is
>> the correct way of telling the Document that I should use ?
>
> In wxArt2D derived doec/view framework i handled this problem by
> having m_parsedWell flag in a2dDocument.
> And i have several ways to find a handler for the document to load.
> A handler is coupled to a document template.
> Like in void a2dDocument::OnOpenDocument( a2dDocumentEvent& event )
> find a handler based on the document template.
>
> a2dIOHandlerStrIn* handler = m_documentTemplate-
> >GetDocumentIOHandlerForLoad( store, this );
>
> LoadObject( store, handler );
> if ( !m_parsedWell || (!store && !store.eof()) )
> {
> a2dDocviewGlobals->ReportErrorF( a2dError_FileCouldNotOpen,
> _("Sorry, could not Load file %s"), file.GetFullPath().c_str() );
> event.Veto();
> }
>
> Here GetDocumentIOHandlerForLoad normaly only returns the handler
> of the document template.
> But it also does test with the handler its CanLoad() method if at
> least the file header is oke.
> This makes it possible to load files without extensions too.
> And the one down here searches a handler in all available templates.
>
> a2dIOHandlerStrIn*
> a2dDocumentTemplateAuto::GetDocumentIOHandlerForLoad
> ( a2dDocumentInputStream& stream, a2dDocument* document )
> {
> // Find the template for this type of document.
> const a2dDocumentTemplateList& allDocTemplates =
> a2dDocviewGlobals->GetDocviewCommandProcessor()->GetDocTemplates();
> for( a2dDocumentTemplateList::const_iterator iter =
> allDocTemplates.begin(); iter != allDocTemplates.end(); ++iter )
> {
> a2dDocumentTemplateList::value_type temp = *iter;
> if ( temp != this && temp->GetDocumentTypeName() ==
> GetDocumentTypeName() && temp->GetDocumentIOHandlerStrIn() && temp-
> >GetDocumentIOHandlerStrIn()->CanLoad( stream, document ) )
> return temp->GetDocumentIOHandlerStrIn();
> }
> return NULL;
> }
>
> To bad for you, you can not do these things with the standard Doc/
> view framework. I found several other short comings, which made
> certain things impossible.
> So i think you best can take mine, our you modify the existing one
> to suit your needs.
>
> Klaas
>
>
>
>
>
> --
> Unclassified
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wx-...@li...
> For additional commands, e-mail: wx-...@li...
>
tiennou
|
|
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: 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-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-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-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: tiennou <tie...@gm...> - 2007-03-09 09:39:39
|
Le 8 mars 07 =C3=A0 23:50, Tito Dal Canton a =C3=A9crit : > Yo, I've corrected color table misbehaviour (related to color table > loading and to the view->color table menu). > > I've also found a problem I wasn't able to track down. In > ShapesBitmapToImage, bitmap pixel values sometimes exceed the =20 > number of > colors per table! I've added a check for this and I wasn't able to =20 > cause > segfaults since then; however, there's certainly an obscure bug > somewhere we need to track down. I'm quite certain it's not a bug in > shapes files, since the old editor never had such problems. That is something I've seen frequently, switching collections trigger =20= this bug... I wasn't able to track it down further... > I've also removed ShapesEditor from Makefiles. Is this file still > needed? If not, let's kill it now. Yes it can be removed safely, I will do it when I'm finished updating =20= Xcode project file... > Now, under linux, the new app looks much like the old one. Nice work. Cool, huh ? Have you tested menu shortcuts ? That's one of the few =20 things I've silently added... I hope you like my idea of centralizing =20= menu managment in one file... > Could you fix the 0.3 Xcode project so that one doesn't need your > wx.framework to build? I'm reluctant at releasing 0.3 with a broken > project. I'm currently doing it, but cvs takes its time to revert my =20 modifications... I'm planning to send a patch to wxWidgets for the framework, but it =20 won't be available until the next release... (Oh yes, misunderstood, I'm fixing both trunk and shapefusion-0.3 =20 branch) tiennou |
|
From: Tito D. C. <ti...@da...> - 2007-03-08 22:59:16
|
Yo, I've corrected color table misbehaviour (related to color table loading and to the view->color table menu). I've also found a problem I wasn't able to track down. In ShapesBitmapToImage, bitmap pixel values sometimes exceed the number of colors per table! I've added a check for this and I wasn't able to cause segfaults since then; however, there's certainly an obscure bug somewhere we need to track down. I'm quite certain it's not a bug in shapes files, since the old editor never had such problems. I've also removed ShapesEditor from Makefiles. Is this file still needed? If not, let's kill it now. Now, under linux, the new app looks much like the old one. Nice work. Could you fix the 0.3 Xcode project so that one doesn't need your wx.framework to build? I'm reluctant at releasing 0.3 with a broken project. Bye, T -- Physics is reverse engineering |
|
From: Tito D. C. <ti...@da...> - 2007-03-05 21:29:11
|
On Mon, 2007-03-05 at 15:44 +0100, tiennou wrote: > No problem, but I thought I could create a shapefusion-0.3 branch for > fixes to the 0.3 code base, and move back the work in wxDoc-branch to > trunk and prepare this for a 0.4 release... So do it. I have nothing to commit now, I'll throw my local copies away and check out the new ones. I have one more feature to add to 0.3, then I'll look for bugs and release. I'm going to include you in the README and other places, what should I put? Tiennou? > About the segfaults you get : I'm getting strange crashes too on MacOS > X, and it seems to be caused by the fact that I changed things like > vector<ShapesCollection> to vector<ShapesCollection*>. It might some > pointer voodoo that cause the correlations, and I'm thinking that > maybe they should be changed back to ShapesCollection. I pointed out a bug about that, but I don't think you fixed it... I don't remember now, something about treating a ShapesChunk* as a ShapesChunk. It compiled without warnings though. I'll do the exam and then... examine it all. Bye Tito -- Physics is reverse engineering |
|
From: tiennou <tie...@gm...> - 2007-03-05 14:44:59
|
Le 5 mars 07 =C3=A0 14:11, ti...@da... a =C3=A9crit : > I got the GUI working, but I'm experiencing problems under > linux. I get segfaults and strange "correlations" between > independent opened documents. I'll investigate and try to > fix. Can you wait some more days before doing the > conversion? No problem, but I thought I could create a shapefusion-0.3 branch for =20= fixes to the 0.3 code base, and move back the work in wxDoc-branch to =20= trunk and prepare this for a 0.4 release... About the segfaults you get : I'm getting strange crashes too on =20 MacOS X, and it seems to be caused by the fact that I changed things =20 like vector<ShapesCollection> to vector<ShapesCollection*>. It might =20 some pointer voodoo that cause the correlations, and I'm thinking =20 that maybe they should be changed back to ShapesCollection. tiennou |
|
From: <ti...@da...> - 2007-03-05 13:11:42
|
I got the GUI working, but I'm experiencing problems under linux. I get segfaults and strange "correlations" between independent opened documents. I'll investigate and try to fix. Can you wait some more days before doing the conversion? Bye Tito |
|
From: tiennou <tie...@gm...> - 2007-03-05 13:05:08
|
I've setup Sourceforge this way : Trackers : Bugs : Category : - General - Shapes Group : - Stable - Unstable/trunk Feature Requests : Category : - Feature Request Group : - Next Release Patches : Category : - General - Shapes Group : - Bug Fix - New Feature Support Requests : Disabled I've set the preferred support mechanism to this mailing list, and deactivated Tasks and Documentation. I will make the svn switch later, please tell me if you need some more time... tiennou |
