Rosegarden

Add script used for experimental hg/git conversion (for reference)

Merged branch logical-instruments with trunk

Reverse the hack I did on this file to spare it from search and replace.

We forgot to update the copyright notices this year, and released 11.02 with a
2010 date. Oops.

• Update distro-versions script. Every distro has seen something change:
• Match Ubuntu LTS release names
• Handle extraordinary number of "current" Debian releases without breaking table layout
• Handle openSUSE's change to RG package names (rosegarden4 -> rosegarden)
• Get new Arch Linux logo, previous link broke
• Switch to a more apparently responsive Gentoo package server

Patch from Daniel O'Connor allowing us to build on FreeBSD

• Update distro version script for various distro updates (and fix my
  own bug which excluded version "10."-something by testing for a single
  digit only, in a couple of distri)

translation updates

Undo the whole /usr/bin/rosegarden-n concept, which did not go over well with
maintainers.

disambiguate all 'keyboard shortcut' texts

Quick, barely tested hack to fix my previous oversight when changing the
installed binary from /usr/bin/rosegarden to /usr/bin/rosegarden-10.02 (for
example.) This rewrites our rosegarden.desktop file into, eg.
rosegarden-10.02.desktop and edits the file to point to the correct binary.

I'm debating whether to take all of this all the way and append $(VERSION) to
everything we install. It seems like it would probably be best, but we haven't
changed our icon in years, and there's minimal room for conflict in the MIME
department, so I don't think it's worth the effort to try to promote 100%
complete separation. (Especially since this will only be used to keep the new
Rosegarden in parallel with Classic for a comparatively short time, and
afterwards it will just be for maintaining parallel installs of the new version
and its successors, which will all be totally compatible with respect to what's
installed to the system. If that should ever change, we can address it then.)

Try a new "UNSTABLE PRE-RELEASE" splash for development builds, including
routine SVN builds. The new make-release-tarball script will change this from
UNSTABLE=1 to STABLE=1 as part of the "RELEASE" target. All other targets will
have the development splash, and that will be the normal state of any SVN tree
as well.

I have an .xcf file of the splash itself, and don't necessarily suggest this is
actually a good concept in this form, but I think the idea in general has some
real merit. The only downside is that I'll be looking at the ugly splash
perpetually, as will many other core users who always run development builds day
to day. Oh well. Let's try it anyway.

Modify rebuild-qrc to include a .qm file for every .ts file present under
version control. I think this will satisfy all of my policy requirements while
allowing us to pull the .qm files out of version control.

I should have thought of this sooner, and I wouldn't have thought of it at all
if Jani and Heikki hadn't complained about my original approach. I don't take
criticism well sometimes, but I do listen. Be patient. :)

• append -$(VERSION) to binary name when installing, so eg.
  /usr/bin/rosegarden-10.02 can co-exist with other installed
  versions

• clean up some obsolete scripts

• new make-release-tarball from scratch (this won't become
  a make target, I don't think, and will just be used straight
  out of scripts/)

I'll go ahead and delete this one too (since it's easy to resurrect if
necessary). I can't quite fathom how this does anything particularly
interesting or useful, and don't imagine anyone uses this for anything.

remove obsolete script

sigh...

fix ts-stats script to report accurate data in a useful way

Nope, it won't be that easy after all. The exception messages are composited
out of this and that, so just translating the base part of it is useless. We
have to redo everything with Q_DECLARE_TRANSLATION_FUNCTIONS or whatever, and
rework all the exception messages the hard way.

It's worth doing though. Having "Bad sound file" appear immutably in English in
an otherwise translated error dialog is just crap.

translate exceptions: phase 1

add .rc tooltips to translation (code to use these still isn't working, and is withheld from this commit)

• add -w option (highlight warnings)

translation-related adjustments

oops... fix carriage returns in generated file

• update Spanish translation (in previous data commit)

• experiment with translatable shortcuts looking for problems (none found yet,
  but I don't actually have a non-US keyboard to test with)

• update generated code to provide point instructions to translators so they
  can avoid pitfalls I just fell into, rather than relying on them finding
  some wiki document