[Matroska-users] MKVToolNix GUI (7.9.0) feedback
Sebastian G. <bastik>
bastik.public.mailinglist at gmx.de
Sun May 10 22:18:14 CEST 2015
10.05.2015, 21:14 Moritz Bunkus:
> 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 ;)
I just gave feedback and did not really ask for anything.
>> 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.
My .(dot) should have been a ?(question-mark) and I was just curious.
>> 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
>> 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.
Indeed, just cosmetic and low priority.
>> 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.
I have no clue either.
> 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.
If there is a written description and/or a video that should be helpful
>> I went to the Attachments tab, before and it had the "Add files"
> 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.
Let's see what others have to say here in case you get more feedback on
the buttons. I won't miss the "Add files" button.
>> 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.
I was unaware of it being non-trivial. Tool tips seem useful to me.
>> 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'
Maybe a pop-up actually helps and once you know what's going on I think
it is easy to understand.
> 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«.
I would not have thought about locking down the GUI, preventing further
input. Nothing I would want.
>> 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.
Whatever it is easier to do and will be understood by most people.
>> The file was muxed, but with a warning that was never brought to my
> 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
At least I think that is useful.
>> 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.
Sounds plausible to only apply things so tracks where it would have an
>> 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.
I understand that it would make things more complicated.
>> 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?
I'm not sure. Maybe too many option confuse users.
Nothing I would really care about. Once they opened the menu they can
see the short-cut and can use it if they want to.
>> 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,
I didn't expect it to work and I did not suggest adding a right-click
menu. Well, if you want to go that route it is fine.
>> 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
> Not sure about this.
Well, it is nothing I would have written an email for if I hadn't tried
it and was sending an email anyway.
(I don't know how to treat users. Some download a .zip with a portable
binary, extract it and don't know what to do, or can't find the
executable. I had not imagined that, therefore I considered giving
>> 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.
Well, your website contains documentation and github has a wiki with
content. Even though the documentation can not be fully applied to the
new GUI, details like setting delay or cropping can be found there and
are still useful.
>> 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.
The question about the file size was just my curiosity, nothing I had
opened a ticket for.
I will create tickets within the next week, or so. There is nothing
really important anyway.
I like to be able to give feedback and I appreciate your answer, which
was given really fast. The wider of matroska depends on the tools that
create them, modify them and play them and if my feedback can help to
make those tools better or easier to use, that's only good.
Still matroska isn't used as widely as I would want to.
More information about the Matroska-users