Menu
▾
▴
shapefusion-devel
|
From: Gregory S. <wo...@tr...> - 2008-02-14 19:19:11
|
Do we have a list of features or a planned release date for 0.5? Tito and I agreed to wait till 0.5 to release a Windows version, for which I've seen many requests in that time. I did give RyokoTK from IRC a build to try, and he reported some problem with bitmap export, which I haven't tracked down yet. Also, I considered writing support for reading/generating Anvil shapes patches (now that they're useful to Aleph One) if that would be welcome. Well, I guess my question is basically, what's up? Gregory |
|
From: Tito D. C. <ti...@da...> - 2008-02-20 16:25:13
|
On Thu, 2008-02-14 at 14:19 -0500, Gregory Smith wrote: > Do we have a list of features or a planned release date for 0.5? Tito and > I agreed to wait till 0.5 to release a Windows version, for which I've > seen many requests in that time. Feature list: yes Planned release date: no My 0.5 feature list is actually almost complete (items marked with 'x' are done): [tito] Arrow keys in the gradient editor. [tito] x Switch to wxWidgets 2.8.x, so get rid of Inside()s and wxTextCtrl::SetValue()s. [tito] x Fix origin/keypoint live drag feedback in frame editor panel. [tito] x "center on origin" display mode in frame editor panel (e.g. View menu option). [tito] x Subclass BigEndianBuffer and LittleEndianBuffer from a parent class. [tito] x Read collection and sound names from a simple external text file (use wxTextFile). [tito] x Sanitize class member names to m*. [tito] x Correct Photoshop color table I/O code to reflect the ACT format specs I found. [tito/treellama] x Fixed crash when opening shapes files under Windows. No big features, basically just fixes and cosmetic stuff, as you can see. > I did give RyokoTK from IRC a build to try, and he reported some problem > with bitmap export, which I haven't tracked down yet. Also, I considered > writing support for reading/generating Anvil shapes patches (now that > they're useful to Aleph One) if that would be welcome. Well, you could checkout 0.4 and build a win executable out of it. Then we could add it to the download page so that pleople can find bugs, and we can schedule their fixes for 0.5. However, 0.4 is affected by that shapes bug under windows, so nobody will find it much useful. Alternatively we may freeze 0.5 as is, and release it together with its win executable. Also, support for patches is welcome if you want to implement it, but I'd like to talk a bit about how that's going to be implemented. > Well, I guess my question is basically, what's up? Unfortunately, at the moment I'm totally busy on the physics side (thesis, one last exam, articles...) and it's higly unlikely that I will do anything heavy for shapefusion until summer. But I can handle a 0.5 release now. A bit of work on it is needed to generalize the item name file to non-linux platforms, though. Bye, Tito -- Physics is reverse engineering |
|
From: Gregory S. <wo...@tr...> - 2008-02-20 19:25:40
|
On Wed, 20 Feb 2008, Tito Dal Canton wrote: > Well, you could checkout 0.4 and build a win executable out of it. Then > we could add it to the download page so that pleople can find bugs, and > we can schedule their fixes for 0.5. However, 0.4 is affected by that > shapes bug under windows, so nobody will find it much useful. Agreed. > Alternatively we may freeze 0.5 as is, and release it together with its > win executable. This sounds useful. > Also, support for patches is welcome if you want to implement it, but > I'd like to talk a bit about how that's going to be implemented. I wouldn't do this for 0.5, so I'll post about it separately. > Unfortunately, at the moment I'm totally busy on the physics side > (thesis, one last exam, articles...) and it's higly unlikely that I will > do anything heavy for shapefusion until summer. But I can handle a 0.5 > release now. OK. Let me have a look at BMP writing in Windows. Also, can we update the Makefile to build a .exe? There are two ways to do it: 1) add a new target to the main Makefile, so that typing cross-make.sh ShapeFusion.exe will result in that being built 2) add a new Makefile.win32, and then the command is cross-make.sh -f Makefile.win32 Do you have a preference? The first requires less maintenance, but the second might be cleaner. > A bit of work on it is needed to generalize the item name file to > non-linux platforms, though. Are you still going with the idea of installing a defaults file somewhere global to all users, and allowing user overrides from their own homes? I can take a look at this if it helps. In Mac OS X that would be, I guess: /Library/Application Support/ShapeFusion/ and ~/Library/Application Support/ShapeFusion and, in Windows: C:\Windows\Application Data\ShapeFusion and C:\Documents and Settings\<username>\Local Settings\Application Data\ShapeFusion But without an installer I don't know how the files will get there. It's also going to be a little tedious if a user wants to switch between editing shapes for two different scenarios. Gregory |
|
From: Tito D. C. <ti...@da...> - 2008-02-22 21:45:35
|
On Wed, 2008-02-20 at 14:25 -0500, Gregory Smith wrote: > OK. Let me have a look at BMP writing in Windows. Also, can we update the > Makefile to build a .exe? There are two ways to do it: > > 1) add a new target to the main Makefile, so that typing cross-make.sh > ShapeFusion.exe will result in that being built > > 2) add a new Makefile.win32, and then the command is cross-make.sh -f > Makefile.win32 > > Do you have a preference? The first requires less maintenance, but the > second might be cleaner. I'd go for the second. > Are you still going with the idea of installing a defaults file somewhere > global to all users, and allowing user overrides from their own homes? I > can take a look at this if it helps. > > In Mac OS X that would be, I guess: > /Library/Application Support/ShapeFusion/ and ~/Library/Application > Support/ShapeFusion > > and, in Windows: > C:\Windows\Application Data\ShapeFusion and C:\Documents and > Settings\<username>\Local Settings\Application Data\ShapeFusion > > But without an installer I don't know how the files will get there. It's > also going to be a little tedious if a user wants to switch between > editing shapes for two different scenarios. I guess shapefusion could also look for the file in the same directory of the executable. I'd tell users that they better put it in the right place, though. Switching it for different scenarios is a future feature, of course :) Bye Tito -- Physics is reverse engineering |
|
From: Tito D. C. <ti...@da...> - 2008-02-26 09:06:09
|
On Fri, 2008-02-22 at 22:44 +0100, Tito Dal Canton wrote: > I guess shapefusion could also look for the file in the same directory > of the executable. I'd tell users that they better put it in the right > place, though. Switching it for different scenarios is a future feature, > of course :) My last work for 0.5 has been trying to define a new class, ElementNameProvider, aimed at providing access to the names file in a clean and abstract way. I.e., that class would look for the file (or hold a user-chosen path for it in the future) and make item names readable like GetCollectionName() or GetSoundClassName(). What do you think about this approach? Tito -- Physics is reverse engineering |
|
From: Gregory S. <wo...@tr...> - 2008-02-26 20:09:26
|
On Tue, 26 Feb 2008, Tito Dal Canton wrote: > My last work for 0.5 has been trying to define a new class, > ElementNameProvider, aimed at providing access to the names file in a > clean and abstract way. I.e., that class would look for the file (or > hold a user-chosen path for it in the future) and make item names > readable like GetCollectionName() or GetSoundClassName(). What do you > think about this approach? Sounds good to me. It's possible people will want separate files for Shapes and Sounds, but the same class could handle that. Gregory |
|
From: Gregory S. <wo...@tr...> - 2008-03-07 20:41:59
|
On Tue, 26 Feb 2008, Tito Dal Canton wrote: > My last work for 0.5 has been trying to define a new class, > ElementNameProvider, aimed at providing access to the names file in a > clean and abstract way. If you don't know about it already (I didn't), wxPathList should make short, easy work of this. Gregory |
|
From: Tito D. C. <ti...@da...> - 2008-08-06 18:01:00
|
Hi all, I just committed a little change that should be an initial improvement in finding DefaultNames.txt in platform-wise places. Could someone build on windows and test that everything is working? You should keep DefaultNames.txt right next to the executable (that's its place on windows). Could you also share the windows binary with me, so I can test it too? In the meantime I hope to do the MacOS build and test it. I decided to close this feature and then release 0.5 ufficially. The ElementNameProvider class will be a 0.6 neatness. Bye Tito -- Physics is reverse engineering |
×
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