Re: mktoolnix v7.9.0 mmg bug

Hey

Here gzipped patch file. Tested way you described.
When key is present it uses Registy (key
HKEY_CURRENT_USER\Software\mkvmergeGUI) to read and store
configuration.
When key is absent it created mkvtoolnix.ini file near executable.

PS: I am afraid I am one who likes old GUI(mmg) and dislikes new one.
Old GUI provide all functionality I needed.
PPS: AFAIK diff/patch files are made that way they can be freely
inserted into ordinal text (including emails and printed articles) and
will not lose their functionality.

Regards, Yaroslav

2015-05-30 10:14 GMT+03:00 Moritz Bunkus <[email protected]>:
> Hey,
>
> thanks for the effort.
>
>> Tested on WindowsXP systems(and still works on my 8.1 x64 system).
>
> How did you test it? That particular function is used for determining
> whether or not the application is installed, and with that knowledge the
> application (mkvmerge GUI and MKVToolNix GUI) decides where to store the
> settings: either in the registry (if the key is present) or in an .ini
> file in the same directory as the .exe (if the key isn't
> present). Please make sure that both cases actually work.
>
>> I can say bootstrapping build environment(and still it is not stable)
>> took 99% of time. You definitely should consider to make possible to
>> build project on Windows using native compiler(mingw or VC).
>
> I'm sorry, but I have no interest whatsoever in spending time on build
> systems that I neither use (native mingw) nor know anything about in the
> first place (VC). Additionally generating build files is something that
> requires constant maintenance (e.g. adding new files, dealing with new
> file types like Qt's UI files etc), therefore adding such a system once
> and then forgetting about it would lead to a non-working build system in
> almost no time.
>
> This isn't just a theoretical concern; it has already happened in the
> past when someone dumped a VC 7 based build system on my, I applied it,
> but that person didn't keep maintaining it. Therefore two years later
> another user tried that build system, noted that it didn't work at all
> anymore, and I have remove it since.
>
>> >>>>>> BEGIN PATCH
>
> After verifying that it actually works as intended can you please send
> me the patch as an attachment? It makes using it much easier for
> me and doesn't run the risk of the mailer (either yours or mine)
> modifies it in any way. Thanks.
>
>> 2. I do not understand what this code located in common section. Why
>> check for "mmg.exe" "installation" linked into all other tools?
>
> The installer writes that particular key. Even if it's named after one
> GUI it really is more a marker that the application has been installed
> and is not used as the portable version. Both mmg.exe (the old GUI) and
> MKVToolNix GUI (the new GUI) use that function; therefore it currently
> resides in the common library.
>
> Once support for wxWidgets (and with it for the old GUI) will have been
> removed I will probably remove that function altogether in favor of
> using Qt's Windows access functions.
>
>> ( And I do not understand reasons to do that checks, however that is
>> not my business).
>
> I've described what it's supposed to do at the top. Like I said please
> test that it actually does what it is supposed to do; I don't want to
> apply untested code.
>
> Kind regards,
> mosu
>
> _______________________________________________
> Matroska-users mailing list
> [email protected]
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-users
> Read Matroska-Users on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.user
>
_______________________________________________
Matroska-users mailing list
[email protected]
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-users
Read Matroska-Users on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.user