Easier checkin of theme changes

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Easier checkin of theme changes

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.


On 7/12/2017 3:12 AM, Paul Licameli wrote:

> 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.

> 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.


> I see it was developed some time before 2010.
by me.

>
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Easier checkin of theme changes

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.

On Wed, Jul 12, 2017 at 01:26:41PM +0100, James Crook wrote:

> +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.
>
>
> On 7/12/2017 3:12 AM, Paul Licameli wrote:
> > 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.
>
> > 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.
>
>
> > I see it was developed some time before 2010.
> by me.
>
> >
> > 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Easier checkin of theme changes

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.

On 7/12/2017 8:28 PM, Henric Jungheim wrote:

> 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.
>
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...