[Chetwood]

Originally Posted by Mosu

And I did acknowledge other people's different uses and preferences, so what's your point?

That's what I was wondering. Why raise points (that could easily be countered) when you acknowledge other people's preferences which renders those points moot anyway? Moving on.

Originally Posted by Mosu

This is just how it comes across to me.

Well, then I have to say I'm sorry cause that wasn't my intention. I must admit though that your brisk way of dealing with requests and criticism (again, header compression) seems to provoke a different tone sometimes

Originally Posted by Mosu

Now when would I execute this file?

After the job queue is done is what I had in mind. This would keep it simple and therefore live up to my naive idea of being a "1-liner" job with no ramifications for your workload or other/requested features (I'm no coder though). Initially I thought about suggesting jobdone.bat and queuedone.bat (to be executed only after a return code of 0) but I realized that would probably strike you as a programmer less than elegant.

Originally Posted by Mosu

So we'd need some kind of parameter passing. That would have to be flexible enough to be extensible in the future (because I may want to expand on the capabilities without braking compatibility).

I get that. Implementing these feature requests requires careful planning (you don't have time for ATM) but I think you'll get this covered eventually with the scripting approach you mentioned. And of course, any negative side effects of people's inability to properly use that function would be their sole responsibility: "use at your own risk!". Still, while you're working on the new GUI, you might wanna add some extra space for future checkboxes ("shutdown after queue") next to "abort current job" in the mkvmerge is running queue window.

Originally Posted by Mosu

So implementing your feature request delays work for everyone else.

Obviously, and of course it's your decision what to implement next, whether it's the latest "tweak" to the MKV standard like no_cue_duration or the handling of new codecs. I, however, always found MKVToolnix to be lacking in the notification department (play sound or do whatever when done) we've come to expect from software over the years and I just thought that fixing this might benefit users more than an MKV feature that we've done fine without so far and that most likely will take standalone manufacturers forever to implement. But that's just me.

Still, I appreciate you taking time to explain this rather than shrugging it off. Thanks.