shapefusion-devel Mailing List for ShapeFusion (Page 2)

Brought to you by: etiennes, rtoschi

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

Flat | Threaded

<< < 1 2 3 4 .. 9 > >> (Page 2 of 9)

Re: [Shapefusion-devel] 0.5 plans

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

Re: [Shapefusion-devel] patch: BMP export bug

From: Gregory S. <wo...@tr...> - 2008-02-22 01:36:52

Tito Dal Canton wrote:
> Thanks. I did a quick test and (as expected) nothing seems different
> under linux. Keep in mind that GIMP palettes are ASCII files, but your
> change seems to make no difference anyway. Can you confirm that your
> patch fixes things under win? I'll commit when you do.

Things seem to work in Wine: I tried exporting bitmaps and color tables,
and importing color tables. Exporting bitmaps didn't work in Wine before
the patch, and do after the patch, so I assume it fixes it in Windows
proper as well.

std::ios::binary may be the right thing to do even for ASCII files like
GIMP palettes--they import into GIMP just fine.

> BTW, stupid windows one more time.

Of course.

Gregory

Re: [Shapefusion-devel] patch: BMP export bug

From: Tito D. C. <ti...@da...> - 2008-02-21 21:35:47

Thanks. I did a quick test and (as expected) nothing seems different
under linux. Keep in mind that GIMP palettes are ASCII files, but your
change seems to make no difference anyway. Can you confirm that your
patch fixes things under win? I'll commit when you do.

BTW, stupid windows one more time.

Bye
Tito
-- 
Physics is reverse engineering

[Shapefusion-devel] patch: BMP export bug

From: Gregory S. <wo...@tr...> - 2008-02-21 03:40:37

Attachments: shapefusion-binary.diff

Turns out Windows has this stupid concept of "text" and "binary" files,
and std i/o fstreams default to the wrong one. The patch attached fixes
all the ofstreams and ifstreams I could find, to use std::ios::binary
when opening the streams.

This solves BMP export problems (and color table import/export, I have
to assume) in Windows.

Gregory

Re: [Shapefusion-devel] 0.5 plans

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

Re: [Shapefusion-devel] 0.5 plans

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

[Shapefusion-devel] 0.5 plans

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

Re: [Shapefusion-devel] names

From: Gregory S. <wo...@tr...> - 2007-12-03 01:16:53

On Dec 2, 2007, at 6:36 PM, Tito Dal Canton wrote:

> Another planned feature is to look in different places for that file.
> For example, the MacOS X build should look inside the application  
> bundle
> rather than /usr/local/share/shapefusion, and the Windows build could
> look in the directory containing the executable. But more important,
> precedence will be given to a similar file in the user's home  
> directory
> (.shapefusion/DefaultNames.txt or similar), so one will be able to  
> give
> meaningful names for her own scenario in a simple and consistent way.

The Mac OS X convention would be  ~/Library/Application Support/ 
ShapeFusion, rather than .shapefusion. There's a similar convention  
in Windows (I'd have to look it up).

Chances are, though, it would make more sense to look in the  
directory containing the executable; since this is a Marathon shapes  
editor, and we're all used to keeping scenarios in their own folders,  
with Forge and Anvil in them. For instance, I could have 3 different  
ShapeFusions, one for M1A1, Infinity, and Tempus Irae. I don't want  
them all to use the strings in ~

> The only drawback I can think of is that a 'make install' step is now
> required in linux, to make sure the file is there. But we can also  
> tell
> the user "put that default file in ~/.shapefusion" in the README.

I suggest not requiring a default. Build the Infinity names into the  
executable, so no text file is needed unless custom names are used.  
This is how Aleph One works with its MML strings.

FWIW, most Linux users are probably accustomed to having a make  
install, and may get confused if it's not present!

Gregory

[Shapefusion-devel] names

From: Tito D. C. <ti...@da...> - 2007-12-02 23:36:48

Hardcoded things are ugly. Collection names were hardcoded, until now.
ShapeFusion now reads them from a simple external text
file, /usr/local/share/shapefusion/DefaultNames.txt. It looks for lines
in the form

collection N string

and collection N will get the name specified by string. Comments start
with the usual '#', and blanks are ignored (except those inside names).
If the file is not found, if it is not readable, or if a name for a
particular collection is missing, a collection will get a dummy
"Collection N" name.

A planned improvement is to extend this to sounds, with the same syntax
and in the same file. An awesome thing is that the shapes sequence
editor will be able to know sound names and display nice popup menus,
rather than those meaningless sound IDs.

Another planned feature is to look in different places for that file.
For example, the MacOS X build should look inside the application bundle
rather than /usr/local/share/shapefusion, and the Windows build could
look in the directory containing the executable. But more important,
precedence will be given to a similar file in the user's home directory
(.shapefusion/DefaultNames.txt or similar), so one will be able to give
meaningful names for her own scenario in a simple and consistent way.

The only drawback I can think of is that a 'make install' step is now
required in linux, to make sure the file is there. But we can also tell
the user "put that default file in ~/.shapefusion" in the README.

Comments?

Tito
-- 
Physics is reverse engineering