audacity-devel

I don't get it. Getting rid of built-in images would make the exe smaller
but then having the images externally would make the total bigger again
wouldn't it? And you need the external images to make it work, yes?
OK, maybe I'm being awkward and somebody could save a bit of disk space by
removing the default images and replacing them with something luminous and
garish but how much would they save? A few kB?
You may have guessed that I think that a keeping the stand-alone exe is a
good idea, but I use English!
TTFN
Martyn
In a message dated 23/05/2006 20:06:32 GMT Standard Time, meyer@...
writes:
James,
James Crook schrieb:
> I can see good arguments for getting rid of XPMs and using PNGs. I
> don't see any compelling argument for dropping built-in images. To me
> it looks to be a bad thing. It would make Audacity unusable without
> the theme file.
The compelling argument for dropping built-in images is to be able to
plug-in additional themes. The compelling arguments against built-in
images is that they need extra spaces when they are not needed. Also,
Audacity already depends de-facto on the language files (for everyone
outside English-speaking countries) and on plugins (for everyone who
does a little bit advanced stuff with it). I don't see what's the
disadvantage with having a directory Images/ with PNG images in it that
would be located in the same directory as Audacity (on Windows) and in
/usr/share on Linux. I don't see any failure scenarios where this could
be a problem.
Markus

On May 23, 2006, at 1:35 PM, MartynShaw@... wrote:
> I don't get it. Getting rid of built-in images would make the exe
> smaller
> but then having the images externally would make the total bigger
> again
> wouldn't it? And you need the external images to make it work, yes?
Actually the embedded images are uncompressed XPMs, the files on disk
would be compressed PNGs. The total size of an Audacity install
would definitely go down a bit. The size of the .zip or installer
would be slightly smaller, because
This isn't the main reason to get rid of built-in images, but it's a
small argument in favor of it, or at least a neutral argument.
> OK, maybe I'm being awkward and somebody could save a bit of disk
> space by
> removing the default images and replacing them with something
> luminous and
> garish but how much would they save? A few kB?
>
> You may have guessed that I think that a keeping the stand-alone
> exe is a
> good idea, but I use English!
A bigger reason I want to switch to PNG is that XPM is a horrible,
hacked up format that is a pain to work with. Every program that
saves XPM does it in a slightly different way and wxWidgets doesn't
read all of them. There are bugs in many versions of wxGTK that
cause colors to be messed up; you can't put an exact color in an XPM
and expect it to be read in that way.
Finally, though, we want users to be able to edit the images that
make up Audacity. I think they should be able to do that by
_replacing_ the current images, not be loading an _extra_ set of
images. There are a lot of arguments for this - one is that it's
more easily discoverable; if you edit the PNG in Audacity's Images
directory and reload Audacity, it changes. Instant feedback! If
Audacity has built-in XPMs then it's not obvious where to put your
PNG files and where to click to get them to load. Also, having built-
in images and also the ability to load images from an external file
means unnecessary code duplication and less testing of either code
path. If all of the developers use the built-in theme, we'll never
notice bugs in the code to load an external theme...
- Dominic
> TTFN
> Martyn
>
> In a message dated 23/05/2006 20:06:32 GMT Standard Time,
> meyer@...
> writes:
> James,
>
> James Crook schrieb:
>> I can see good arguments for getting rid of XPMs and using PNGs. I
>> don't see any compelling argument for dropping built-in images.
>> To me
>> it looks to be a bad thing. It would make Audacity unusable without
>> the theme file.
> The compelling argument for dropping built-in images is to be able to
> plug-in additional themes. The compelling arguments against built-in
> images is that they need extra spaces when they are not needed. Also,
> Audacity already depends de-facto on the language files (for everyone
> outside English-speaking countries) and on plugins (for everyone who
> does a little bit advanced stuff with it). I don't see what's the
> disadvantage with having a directory Images/ with PNG images in it
> that
> would be located in the same directory as Audacity (on Windows)
> and in
> /usr/share on Linux. I don't see any failure scenarios where this
> could
> be a problem.
>
>
> Markus
>
>
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and
> Risk!
> Fully trained technicians. The highest number of Red Hat
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Audacity-devel mailing list
> Audacity-devel@...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

MartynShaw@... wrote:
> I don't get it. Getting rid of built-in images would make the exe smaller
> but then having the images externally would make the total bigger again
> wouldn't it? And you need the external images to make it work, yes?
> OK, maybe I'm being awkward and somebody could save a bit of disk space by
> removing the default images and replacing them with something luminous and
> garish but how much would they save? A few kB?
25 KB. That's what the PNG file currently takes. Embedded in the exe
(if done right) it should take almost exactly the same space.
My guesstimate is that the XPMs currently take up about 200 KB in the
exe, and slightly less in an Audacity installation file, because of some
compression of the exe.
> TTFN
> Martyn
Dominic Mazzoni wrote:
> Actually the embedded images are uncompressed XPMs, the files on disk
> would be compressed PNGs. The total size of an Audacity install
> would definitely go down a bit.
Not if we use PNG within the exe as I suggested in an earlier e-mail.
Then there is no size difference for the Audacity installation file
between images in the exe and images external to the exe.
> A bigger reason I want to switch to PNG is that XPM is a horrible,
> hacked up format that is a pain to work with.
Agreed. PNG is a much nicer format. I too would like to get rid of the
XPM images.
> Every program that saves XPM does it in a slightly different way
> and wxWidgets doesn't read all of them.
I was not aware of that problem. It is another argument in favour of
PNG. I have used ImageMagick for XPMs (it is cross platform) and not
had a problem with wxWidgets reading the images. My biggest problem
with XPMs funnily enough is that they tempt me in to hand editing. It
always looks to be much quicker to do this than to do the round trip via
an editor - and it ends up taking longer.
> Finally, though, we want users to be able to edit the images that
> make up Audacity.
Agree.
> I think they should be able to do that by _replacing_ the current
> images,
Agree.
Additionally I think it important to be able to try out changes without
restarting Audacity. This is why there is a load button in the Theme
preferences dialog, and why I have code to rebuild ControlToolBar with
the new images.
> not be loading an _extra_ set of images.
Uhh? That means that if they open the default image set in the GIMP,
edit them (badly) and find they don't like the results when viewed in
Audacity, they then have no easy way to recover the original set? If
you're championing discoverability, you have to consider that people
might do this in exploring, rather than doing the sensible thing of
making their own backup copy of the images first.
With the plan I have, if they delete the messed up image file they are
back to being OK on restarting Audacity. Or they can go into theme
preferences dialog and save a default version again to revert to defaults.
> There are a lot of arguments for this - one is that it's more
> easily discoverable;
I think discoverability from within the GUI is what really counts, not
from exploring external files. Surely we don't expect people to
discover the features of Audacity through exploring the .aup files or
the registry/initialisation files? They may try, and we may help to
some extent, but our focus should be on making the GUI discoverable.
> Also, having built- in images and also the ability to load
> images from an external file means unnecessary code duplication and
> less testing of either code path.
There would be no actual *code* duplication that I can see. If there
is, it should be put in to a subroutine! These are *different*
functions with related but not identical purposes. Your 'less testing'
argument applies equally to supporting both wav and ogg. But we do
support both.
> If all of the developers use the built-in theme, we'll never
> notice bugs in the code to load an external theme...
This is an argument for more testing, not for the absence of a feature.
I think there must be other issues here that go deeper that need to be
teased out. I'm not getting it as to why having a default copy (as PNG)
within the exe is a bad thing.
--James.

James,
Okay, we all agree we want to get rid of XPM entirely and replace it
with PNG!
I am okay with the idea of embedding the PNGs into the program.
You've heard my arguments why I don't think it's necessary, but it
doesn't bother me.
I think your idea of putting all of the graphics into a single large
image is very clever. It's a great way to make it easy for someone
to edit all of the images at once. What it's terrible for, though,
is developers adding new graphics or changing existing graphics -
even resizing an existing graphic. For example, each new version of
Audacity would have a different set of graphics - would it need to
support all previous versions? How would you convert from a previous
ImageCache to a new ImageCache???
I propose the following, which I hope will satisfy everyone's goals:
1. Theme will load its graphics from PNG files found on disk.
2. Theme has the ability to export the graphics to a single
ImageCache.png which users can edit, and import the ImageCache back
into Audacity, which will save it out as a Theme directory again.
This feature only needs to be supported for the _current_ version of
Audacity.
3. Audacity ships with a default ImageCache.png bundled into the
executable. If you run Audacity and it can't find its theme
directory, it uses the Theme code to split out the graphics into
individual files and saves them, thus creating a theme directory. If
the usual location is not writable, it could even use the audacity
temp directory, which has already been created.
- Dominic
On May 25, 2006, at 3:54 AM, James Crook wrote:
> MartynShaw@... wrote:
>> I don't get it. Getting rid of built-in images would make the
>> exe smaller but then having the images externally would make the
>> total bigger again wouldn't it? And you need the external images
>> to make it work, yes?
>
>> OK, maybe I'm being awkward and somebody could save a bit of disk
>> space by removing the default images and replacing them with
>> something luminous and garish but how much would they save? A
>> few kB?
>
> 25 KB. That's what the PNG file currently takes. Embedded in the
> exe (if done right) it should take almost exactly the same space.
>
> My guesstimate is that the XPMs currently take up about 200 KB in
> the exe, and slightly less in an Audacity installation file,
> because of some compression of the exe.
>
>> TTFN
>> Martyn
>
> Dominic Mazzoni wrote:
> > Actually the embedded images are uncompressed XPMs, the files on
> disk
> > would be compressed PNGs. The total size of an Audacity install
> > would definitely go down a bit.
>
> Not if we use PNG within the exe as I suggested in an earlier e-
> mail. Then there is no size difference for the Audacity
> installation file between images in the exe and images external to
> the exe.
>
> > A bigger reason I want to switch to PNG is that XPM is a horrible,
> > hacked up format that is a pain to work with.
>
> Agreed. PNG is a much nicer format. I too would like to get rid
> of the XPM images.
>
> > Every program that saves XPM does it in a slightly different way
> > and wxWidgets doesn't read all of them.
>
> I was not aware of that problem. It is another argument in favour
> of PNG. I have used ImageMagick for XPMs (it is cross platform)
> and not had a problem with wxWidgets reading the images. My
> biggest problem with XPMs funnily enough is that they tempt me in
> to hand editing. It always looks to be much quicker to do this
> than to do the round trip via an editor - and it ends up taking
> longer.
>
> > Finally, though, we want users to be able to edit the images that
> > make up Audacity.
> Agree.
>
> > I think they should be able to do that by _replacing_ the current
> > images,
> Agree.
>
> Additionally I think it important to be able to try out changes
> without restarting Audacity. This is why there is a load button in
> the Theme preferences dialog, and why I have code to rebuild
> ControlToolBar with the new images.
>
> > not be loading an _extra_ set of images.
> Uhh? That means that if they open the default image set in the
> GIMP, edit them (badly) and find they don't like the results when
> viewed in Audacity, they then have no easy way to recover the
> original set? If you're championing discoverability, you have to
> consider that people might do this in exploring, rather than doing
> the sensible thing of making their own backup copy of the images
> first.
>
> With the plan I have, if they delete the messed up image file they
> are back to being OK on restarting Audacity. Or they can go into
> theme preferences dialog and save a default version again to revert
> to defaults.
>
> > There are a lot of arguments for this - one is that it's more
> > easily discoverable;
>
> I think discoverability from within the GUI is what really counts,
> not from exploring external files. Surely we don't expect people
> to discover the features of Audacity through exploring the .aup
> files or the registry/initialisation files? They may try, and we
> may help to some extent, but our focus should be on making the GUI
> discoverable.
>
> > Also, having built- in images and also the ability to load
> > images from an external file means unnecessary code duplication and
> > less testing of either code path.
>
> There would be no actual *code* duplication that I can see. If
> there is, it should be put in to a subroutine! These are
> *different* functions with related but not identical purposes.
> Your 'less testing' argument applies equally to supporting both wav
> and ogg. But we do support both.
>
> > If all of the developers use the built-in theme, we'll never
> > notice bugs in the code to load an external theme...
>
> This is an argument for more testing, not for the absence of a
> feature.
>
>
> I think there must be other issues here that go deeper that need to
> be teased out. I'm not getting it as to why having a default copy
> (as PNG) within the exe is a bad thing.
>
>
> --James.
>
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and
> Risk!
> Fully trained technicians. The highest number of Red Hat
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Audacity-devel mailing list
> Audacity-devel@...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Sounds like:
a) Embedded images
b) PNG format
could be the way forward.
I'll work on that assumption for now.
This means I can get on with converting the rest of Audacity to use
Theme.cpp.
--James
Dominic Mazzoni wrote:
> James,
>
> Okay, we all agree we want to get rid of XPM entirely and replace it
> with PNG!
>
> I am okay with the idea of embedding the PNGs into the program. You've
> heard my arguments why I don't think it's necessary, but it doesn't
> bother me.

Dominic,
I think we are on the same wavelength here. The image cache file is
version specific. At least that is what I intended. Version 1.4.1
Audacity will probably not be able to use a cache file from 1.3.2, but
probably would be able to use the individual images just fine. As you
say, to move between versions of Audacity we use the individual files,
not the cache files.
----
There is a possible complication. Another reason other than designer
convenience that I chose to start by implementing with a single
cached image is that loading of a single image may be significantly
faster than from multiple files.
I don't know if that is so. I need to find out. I'll know when I've
got the part that loads/saves from individual image files implemented.
I had planned to use the image cache in normal use. If the images load
rapidly as individual images then we could do exactly as you proposed
and use the individual images in normal use with the cache being just a
convenience for distribution and for image designers. This would make
future/past version compatability better than I had planned for, which
would be good.
--James.

James,
If loading from a single image is significantly faster, that could be
a good thing.
One way or another, I have a bunch of other images I'd like to add.
Many of them are not at all the same size as any existing images,
which presents a bit of a complication for the ImageCache? In any
event, let's figure out a way to add new images without having to
generate XPMs or edit the entire ImageCache manually.
- Dominic
On May 26, 2006, at 1:47 AM, James Crook wrote:
> Dominic,
>
> I think we are on the same wavelength here. The image cache file is
> version specific. At least that is what I intended. Version 1.4.1
> Audacity will probably not be able to use a cache file from 1.3.2, but
> probably would be able to use the individual images just fine. As you
> say, to move between versions of Audacity we use the individual files,
> not the cache files.
>
>
> ----
>
> There is a possible complication. Another reason other than designer
> convenience that I chose to start by implementing with a single
> cached image is that loading of a single image may be significantly
> faster than from multiple files.
>
> I don't know if that is so. I need to find out. I'll know when I've
> got the part that loads/saves from individual image files implemented.
> I had planned to use the image cache in normal use. If the images
> load
> rapidly as individual images then we could do exactly as you proposed
> and use the individual images in normal use with the cache being
> just a
> convenience for distribution and for image designers. This would make
> future/past version compatability better than I had planned for, which
> would be good.
>
> --James.
>
>
>
>
> _______________________________________________
> Audacity-devel mailing list
> Audacity-devel@...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Dominic Mazzoni wrote:
> James,
> One way or another, I have a bunch of other images I'd like to add.
> Many of them are not at all the same size as any existing images,
> which presents a bit of a complication for the ImageCache?
I think it will probably be OK if I change it so that I only start a new
row in the ImageCache if either we are out of horizontal space or the
next image has height greater than the previous one. It wastes a small
ampunt of the available space it's true, but seems an OK compromise, and
the 'wasted space' will compress to nothing as it is all the same
colour. I am also going to add a 1 pixel border round each image so
that we can (later) use the magic colour method to get the boundaries
and hence sizes.
> In any event, let's figure out a way to add new images without
> having to generate XPMs or edit the entire ImageCache manually.
I think I have this figured now.
There are three formats for the images:
- Single ImageCache.png
- Single ImageCache.h include file (roughly 4 times larger)
- Multiple separate image.png files.
We need all three, but I think we're better off having only one of these
formats in CVS. My concern is of ending up with mismatches between the
different versions. My preference is for the first, as it is smaller
and easier to work with than the second. I'm happy to go with the third
if there's a preference to do so, though I think it could be a little
less convenient for tracking different themes. Whatever we choose, we'd
generate the other formats we need via Audacity itslf. Generation of
ImageCach.h would only be possible from Debug builds of Audacity, since
only developers will ever need it.
What's your reaction to that? Does it sound sensible?
--James.

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details