For locales for which mkvtoolnix does not contain a translation
(e.g. fr_FR, en_AU etc) mkvtoolnix should not abort with an
error message. mmg must not chose such a locale as the parameter
for --ui-language. Fix for bug 338.
When a packetizer is appended to another one then the ::set_headers() member
function of the appended one will not be called. The AVC ES packetizer enables
the timecode generation of the parser in ::set_headers(). So the timecode
generation is always off in the appended packetizers.
This is a problem when the user appends raw AVC ES files because for them
the timecode generation must turned on because otherwise there will be no
timecodes for the frames. So now the AVC ES packetizer hoooks into the
::connect() function and enables timecode generation if neccessary.
Possible fix for bug 344.
The action "remove all files" must also clear the list of attached files.
The action "File" -> "New" must clear the internal list of attached files
as well as the GUI component.
wxWidgets 2.9 distributes space according to a widget's
natural width. That resulted in the language drop down to become
so wide that the charset drop down did not fit into the window
anymore. By setting the minimum width of both combo boxes equal
both get equal shares of the available space resulting in proper
display.
Do not require a separate "make depend" step. Especially as
new dependencies are not picked up until the next "make depend".
Use gcc's capability to calculate dependencies during
compilation.
wxWidgets 2.8 defines file dialog enums as wxFD_... while 2.6 used wx_...
This patch detects whether or not the wxFD_... enums are available and
uses them; otherwise the old enums are used.
On Linux wxWidgets 2.8.0 and newer uses the GTK combo boxes which suck. A lot.
Therefore mmg uses wxBitmapComboBoxes for wxWidgets >= 2.8.0 on Linux and normal
wxComboBoxes in all other cases. wxBitmapComboBoxes are still drawn by wxWidgets
itself (just like wxComboBoxes before 2.8.0) and offer much better functionality.
Fix for bug 339.
As I am not sure how magic_file() access files on Windows I am
switching to using my own file access class. That way paths with
non-ASCII chars should work fine even in non-UTF-8 encoded
environments. Hopefully a fix for bug 340.
windres is not needed for non-Windows builds and should
therefore only be checked if we are cross-compiling.
Otherwise warnings or errors could confuse the user.
The windres tool used for cross-compiled mingw builds
should be detected by configure. Until now it was assumed
that it was simply called "windres" and not prefixed
like the other compiler components (e.g. i386-mingw32msvc-gcc).
The call to setlocale() should contain the current codeset (e.g. en_US.UTF-8) instead
of just the language and territory (en_US). Otherwise the user would have to have
loacles generated for "en_US" as well which is often not the case with newer Linux
distributions (e.g. Ubuntu 8.10). Fix for bug 338.
1. Setting the LANG environment variable is not enough because
the user might have set LC_MESSAGES himself. While this does
not affect Windows itself it does affect apps ported from Linux,
e.g. GTK. So the LC_MESSAGES variable has to be set, too.
2. Use two-letter language codes for setting LC_MESSAGES and
LANG on Windows, too, because other apps like GTK want it that
way.
