[Audacity-devel] Easier checkin of theme changes

[Paul Licameli]

NOT a thing for 2.2.0, but could there be a better way to manage the
revision history of images in the theme?

1) Figure out how to compile a minimal command-line executable that does
what "Load Files" and "Output Sourcery" buttons do in Theme preferences.

2) Make the building and running of that program a custom step in the
makefiles that precedes the build of Audacity.

3) Add the image files to the git repository. They are now source files,
but (unlike, say .ny files) not part of the bundle that is shipped.

4) Remove the *ThemeAsCeeCode.h files from the revision history, because
they are generated.

5) Maybe for extra credit, make a small separate git repository describing
retroactively the history of image changes now encoded as changes of
ThemeAsCeeCode.h, so it is there for easier future reference.

Then, one could simply commit changed versions of image files and all would
work without difficulty.

Why was ThemeAsCeeCode.h made a part of the program? I never learned what
motivated that or when it was done. I see it was developed some time
before 2010.

PRL

[James Crook]

+1. It is a big mistake checking derived data into a VCS.

The minimal 'command-line' executable could actually be the whole
Audacity. The difference is that we make Audacity compilable with only
an empty stub for ThemeAsCeeCode.h, and able to run direct from the
unprocessed image files, if they are available, or GUI less, if they are
not available either. Baking ThemeAsCeeCode.h in then becomes an
optional step, e.g. when doing a release.

We should also explore alternative mechanisms for baking the images in.
For example the resource compiler of MSVC can add a binary resource file
in, and similar is available for Linux, without the intermediate step of
encoding as an array of numbers. Also we could use a zip file format to
store an actual tree of arbitrary files, rather than combining the
images into a single image. It is also worth looking at the wxWidgets
XRC mechanism.

Post by Paul Licameli
NOT a thing for 2.2.0, but could there be a better way to manage the
revision history of images in the theme?
1) Figure out how to compile a minimal command-line executable that does
what "Load Files" and "Output Sourcery" buttons do in Theme preferences.
2) Make the building and running of that program a custom step in the
makefiles that precedes the build of Audacity.
3) Add the image files to the git repository. They are now source files,
but (unlike, say .ny files) not part of the bundle that is shipped.
4) Remove the *ThemeAsCeeCode.h files from the revision history, because
they are generated.
5) Maybe for extra credit, make a small separate git repository describing
retroactively the history of image changes now encoded as changes of
ThemeAsCeeCode.h, so it is there for easier future reference.
Then, one could simply commit changed versions of image files and all would
work without difficulty.

yes.

Post by Paul Licameli
Why was ThemeAsCeeCode.h made a part of the program? I never learned what
motivated that or when it was done.

I claim the credit and brickbats for that.

It is/was important that the images stay with Audacity, as users may
just copy audacity.exe to some new location.

Post by Paul Licameli
I see it was developed some time before 2010.

by me.

Post by Paul Licameli
PRL

[Henric Jungheim]

Using resources to store that stuff is simple enough on
Windows. It is also probably the most the natural way of
including arbitrary binary streams in a PE file. That does
mean platform specific code for loading themes.

In the near term, one might consider making those arrays
const. That will put all those bytes in the read-only
.rdata/.rodata section instead of the .data section.

For example:
https://github.com/henricj/audacity/commit/3f4e782f9199cc0b59020812581e6685d0112e0d

Any data that shouldn't change ought to be "const". Both
the compiler and the MMU help in keeping "const" data
constant.

Post by James Crook
+1. It is a big mistake checking derived data into a VCS.
The minimal 'command-line' executable could actually be the whole
Audacity. The difference is that we make Audacity compilable with only
an empty stub for ThemeAsCeeCode.h, and able to run direct from the
unprocessed image files, if they are available, or GUI less, if they are
not available either. Baking ThemeAsCeeCode.h in then becomes an
optional step, e.g. when doing a release.
We should also explore alternative mechanisms for baking the images in.
For example the resource compiler of MSVC can add a binary resource file
in, and similar is available for Linux, without the intermediate step of
encoding as an array of numbers. Also we could use a zip file format to
store an actual tree of arbitrary files, rather than combining the
images into a single image. It is also worth looking at the wxWidgets
XRC mechanism.

Post by Paul Licameli
NOT a thing for 2.2.0, but could there be a better way to manage the
revision history of images in the theme?
1) Figure out how to compile a minimal command-line executable that does
what "Load Files" and "Output Sourcery" buttons do in Theme preferences.
2) Make the building and running of that program a custom step in the
makefiles that precedes the build of Audacity.
3) Add the image files to the git repository. They are now source files,
but (unlike, say .ny files) not part of the bundle that is shipped.
4) Remove the *ThemeAsCeeCode.h files from the revision history, because
they are generated.
5) Maybe for extra credit, make a small separate git repository describing
retroactively the history of image changes now encoded as changes of
ThemeAsCeeCode.h, so it is there for easier future reference.
Then, one could simply commit changed versions of image files and all would
work without difficulty.

yes.

Post by Paul Licameli
Why was ThemeAsCeeCode.h made a part of the program? I never learned what
motivated that or when it was done.

I claim the credit and brickbats for that.
It is/was important that the images stay with Audacity, as users may
just copy audacity.exe to some new location.

Post by Paul Licameli
I see it was developed some time before 2010.

by me.

Post by Paul Licameli
PRL

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[James Crook]

Thanks Henric. Very good suggestion. I've cherry picked that into HEAD,
along with a few other very safe commits in the same branch that I liked
and thought ready for use right now.

--James.

Post by Henric Jungheim
Using resources to store that stuff is simple enough on
Windows. It is also probably the most the natural way of
including arbitrary binary streams in a PE file. That does
mean platform specific code for loading themes.
In the near term, one might consider making those arrays
const. That will put all those bytes in the read-only
.rdata/.rodata section instead of the .data section.
https://github.com/henricj/audacity/commit/3f4e782f9199cc0b59020812581e6685d0112e0d
Any data that shouldn't change ought to be "const". Both
the compiler and the MMU help in keeping "const" data
constant.