[Matroska-users] MKVToolNix GUI (7.9.0) feedback

Moritz Bunkus moritz at bunkus.org
Sun May 10 21:14:59 CEST 2015


Hey,

first of all thanks for the detailed feedback. Much appreciated!

I am aware of a lot of the points you've mentioned and intend to
fix/change/implement some of them, but likely not all, or at least not
right away. The reason is simple: amount of work & available time ;)

However, I should really keep your mail around as a kind of TODO
list. So maybe filing issues on Github would indeed be best, at least
for those points that I don't dismiss outright.

> The binary of it on Windows 7 64bit is 21MB big, while mmg is 15MB big.
> Why is that GUI so much bigger, considering it doesn't have all features
> implemented, like the info. (mkvinfo is 19MB big, so that would have
> been plausible)

To be honest I don't care a lot about the executable's file size. The
GUI can already do a number of things that the old couldn't, so well…
Also Qt is simply more code that wxWidgets. Plain and simple.

> The properties window in the Input tab shows a scroll-bar, even if the
> window is maximized and there is no reason to scroll as all option are
> visible.
>
> The black vertical bar on the left is longer than the box right to it.

Both cosmetic issues and very low priority, but should be fixed sometime
in the future.

> The window was not maximized by default and this made me find the "Add
> files" very easily, but I wondered how appending files works.

I'm not so happy about those four buttons. They were the first thing I
added back when I started the new GUI – mostly because the old GUI did
it that way. However, some time after that I decided not to plaster
everything with buttons because the sheer number of features I was
planning on implementing would have made the GUI cluttered with buttons.

I'm not sure how to solve this dichotomy yet.

One thing I was thinking about was making a short (two minutes) intro
video »how to do stuff with MKVToolNix GUI« on Youtube and show a link
to it the first time the user runs the GUI.

> I went to the Attachments tab, before and it had the "Add files"
> button,

That's definitely on my TODO list and is going to change. The buttons
will probably become part of the »input« tab, even if I decide to keep
those four buttons.

> At the same time it was not obvious that I had to right-click in the
> Input tab to append files. The box could have a description asking the
> user to input files with a right-click.

It's not quite trivial to add a placeholder text to an empty tree view,
I think. What I can definitely do is put that information into tool
tips, e.g. »You can add or append files by right-clicking here.« or
something like that. That would be used for the files, tracks and
attachments tree views.

> mmg presented a muxing window, while MKVToolNix does not.

Yes, another issue I haven't been able to find a good solution for. The
idea is to have jobs running in the background (they already do). If
your muxing job would have run a bit longer then you would definitely
have seen some visual feedback as there's a progress bar in the status
bar as well.

I know it's unintuitive and confusing for everyone using the GUI for the
first time. Like I said, I don't have a good solution. Maybe a popup
explaining what happens the first time the user starts a job? »Jobs are
executed in the background. You can see the output on the 'job output'
tool.«

What I will definitely not do (but you're likely not asking for that
anyway) is bring back the old modal way of »now a job is running and you
cannot do anything else with the GUI«.

> Maybe the GUI can have an option to jump to the "Job Output" when the
> muxing starts or when it is finished.

Maybe. Or a popup with an explanation. I'll have to think about this
some more.

> The file was muxed, but with a warning that was never brought to my
> attention.

Agreed, some kind of perpetual feedback on the jobs must always be
visible. The number of jobs running/waiting, the number of
warnings/errors that have occurred since the user has looked at the job
output tab, the current job's progress and the overall progress. Maybe
something like a second status bar devoted solely to this kind of
information.

> Due to the right-clicking in the Input tab where the files are, I
> right-clicked where the tracks are to see what I can do there. Select
> them all, enable or disable them all. Would be nice to see "xyz all
> for this type" and maybe even "xyz all from the same source".

I decided not to implement all kinds of »select all of…« options and to
wait a bit what the users were asking for. The two you've proposed sound
useful. Note, though, that even if you select tracks of different types
the options you change will only be applied to tracks for which the
option makes sense. For example, if you've selected both an audio and a
video track and change the aspect ratio settings then they'll only be
changed for the video track.

> Since stuff works with a mouse, I double-clicked on the "Mux this"
> check mark with a written yes to try to toggle it to an red cross with
> a written no.

I don't want to have hidden functionality in the tree views because it
is even less easy to discover than the context menus.

> The Edit headers tab (Header Editor, which I call Hæditor) greets me
> with the info that no file has been opened yet. It would be nice if
> there would be button or a link, right there to open a file.

True, will think about it.

> Maybe it would be helpful if the info mentioned that "CTRL+O" can be
> used to open a file.

The hint already mentions that you can open a file from the menu. Do you
really think mentioning a keyboard shortcut, too, will make this easier
for the majority of users?

> This is true for the Edit chapters tab as well. (Right clicking
> does not open a menu to open files either, I did not expect it, but gave
> it a try since it worked in other places.)

That's actually a good point. I'll think about adding context menus for
the »no file open yet« screens as well. The problem with that is that
the context menus that are shown once you've opened a file don't deal
with file operations (loading, saving, saving as new etc). If I used a
context menu with those file operations only on the »nothing's been
loaded yet« screen then I'm pretty sure users would find that confusing,
too.

> When I try to open a file that contains no chapters it get "File
> parsing failed" with the info that the file does not contain any
> chapters. So far so correct. It would be nice to point the user in the
> right direction, like "but you can create them with this editor by
> clicking 'Chapter Editor -> New' and merge them with the merge
> function."

Not sure about this.

> Maybe the Chapter Editor could create an Edition for new files. Maybe
> even with a sub-chapter for that Edition as this is where users start.

Good idea. I'll definitely implement that.

> The preference has an option called "Warn before overwriting existing
> items." which is not remembered so I assume is not working, yet.

Correct, that's one option that hasn't been implemented yet, only added
to the GUI. I thought I had it left disabled… meh.

> It would also be nice if there would be an option to get prompted
> before closing a file or the program if there are unsaved changes.

Definitely on the TODO list. It has already been implemented for the
header editor.

> There is no help menu or about menu where a user can get to
> https://www.bunkus.org  or github for additional help.

There's no help at all yet.

> This is just some feedback on the GUI or related, nothing that is a bug
> or a feature request, but if anything in here should be a ticket (an
> issue) I can create them.

Like I said I appreciate your feedback a lot. I also appreciate the
offer to create issues on Github. Please do so, maybe except for the
file size issue and the thing with the help message if the chapter
editor cannot parse chapters. Thanks.

> BTW: Without knowing the history of MKVtoolNix and its GUIs it appears
> strange that something with version 7.9.0 has unimplemented features.

Well… I can relate to that. Maybe I'll hide the tool selectors for those
things that haven't been implemented yet (extraction, info).

The next release should bring feature parity (at least I hope I'll get
it done), so that things like »warn before overwriting« won't be a
control without functionality any longer.

Kind regards,
mosu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.matroska.org/pipermail/matroska-users/attachments/20150510/bd2e66e6/attachment-0001.sig>


More information about the Matroska-users mailing list