Re: [arch-general] mkvtoolnix-gtk: The new GUI is missing
Hello Giovanni Scafora,
I am trying to contact you about the bug reports opened about the mkvtoolnix package. Please see the email below posted on the mailing list.
Thank you, Benjamin
Hi,
We do have trouble with some bug reports [1], [2] and [3]. The maintainer (Giovanni Scafora) does not answer, nor update the PKGBUILD. In the last bug report [3] we kindly offer a working example of PKGBUILD which fix the problem : bring back the GUI (Qt5 instead of Gtk) The first bug report [1] is more than 4 years old without any respond...
What do we need to do to resolve this issue ?
[1] https://bugs.archlinux.org/task/24532 [2] https://bugs.archlinux.org/task/44948 [3] https://bugs.archlinux.org/task/45439
Antonio Rojas wrote: Have you tried directly emailing the maintainer?
On Mon, Sep 28, 2015 at 6:20 PM, Benjamin Robin dev@benjarobin.fr wrote:
Hello Giovanni Scafora,
I am trying to contact you about the bug reports opened about the mkvtoolnix package. Please see the email below posted on the mailing list.
Thank you, Benjamin
Hi,
We do have trouble with some bug reports [1], [2] and [3]. The maintainer (Giovanni Scafora) does not answer, nor update the PKGBUILD. In the last bug report [3] we kindly offer a working example
of
PKGBUILD which fix the problem : bring back the GUI (Qt5 instead of Gtk) The first bug report [1] is more than 4 years old without any respond...
What do we need to do to resolve this issue ?
[1] https://bugs.archlinux.org/task/24532 [2] https://bugs.archlinux.org/task/44948 [3] https://bugs.archlinux.org/task/45439
Antonio Rojas wrote: Have you tried directly emailing the maintainer?
Hi all,
@Giovanni: being a somewhat heavy user of mkvtoolnix myself I'd like to co-maintain mkvtoolnix with you. I rewrote most of the PKGBUILD, here are the changes I'd iike to push [1], I chose to name the Qt-enabled mkvinfo binary mkvinfo-gui to mirror how the main GUI is named. Also, as Moritz Bunkus pointed out, it appears all current workarounds can be removed. Please let me know what you think.
@Benjamin: Feel free to give the diff a spin before we push it, it's working fine here, the only gripe I have with the new GUI is that the left toolbar is completely black, but that may just be because my desktop is powered by GNOME.
[1] https://paste.xinu.at/oX2o/
Cheers, -- Maxime
Le 28/09/2015 22:12, Maxime Gauduin a écrit :
On Mon, Sep 28, 2015 at 6:20 PM, Benjamin Robin dev@benjarobin.fr wrote:
Hello Giovanni Scafora,
I am trying to contact you about the bug reports opened about the mkvtoolnix package. Please see the email below posted on the mailing list.
Thank you, Benjamin
Hi,
We do have trouble with some bug reports [1], [2] and [3]. The maintainer (Giovanni Scafora) does not answer, nor update the PKGBUILD. In the last bug report [3] we kindly offer a working example
of
PKGBUILD which fix the problem : bring back the GUI (Qt5 instead of Gtk) The first bug report [1] is more than 4 years old without any respond...
What do we need to do to resolve this issue ?
[1] https://bugs.archlinux.org/task/24532 [2] https://bugs.archlinux.org/task/44948 [3] https://bugs.archlinux.org/task/45439
Antonio Rojas wrote: Have you tried directly emailing the maintainer?
Hi all,
@Giovanni: being a somewhat heavy user of mkvtoolnix myself I'd like to co-maintain mkvtoolnix with you. I rewrote most of the PKGBUILD, here are the changes I'd iike to push [1], I chose to name the Qt-enabled mkvinfo binary mkvinfo-gui to mirror how the main GUI is named. Also, as Moritz Bunkus pointed out, it appears all current workarounds can be removed. Please let me know what you think.
@Benjamin: Feel free to give the diff a spin before we push it, it's working fine here, the only gripe I have with the new GUI is that the left toolbar is completely black, but that may just be because my desktop is powered by GNOME.
[1] https://paste.xinu.at/oX2o/
Cheers,
Maxime
Tested here, build fine (although I was surprised by the amount of time required), but the left toolbar background is also completely black here under KDE/Plasma 5.
Bruno
There is a problem with your PKGBUILD. The build performances set aside. The PKGBUILD [1] provided in the bug report is built much faster.
You try to be able to install mkvtoolnix-qt alone without the mkvtoolnix-cli package, right ? Well this cannot work since mkvtoolnix-qt needs the locale/translation.
And since mkvtoolnix-cli *must* be a dependency of mkvtoolnix-qt, there is no point to have the manual mkvinfo-gui.1 which is identical to mkvinfo.1. You can if you want create a symbolic link.
[1] http://pastebin.com/rtguGrbR
@Benjamin: Feel free to give the diff a spin before we push it, it's working fine here, the only gripe I have with the new GUI is that the left toolbar is completely black, but that may just be because my desktop is powered by GNOME.
On Tue, Sep 29, 2015 at 12:01 AM, Benjamin Robin dev@benjarobin.fr wrote:
There is a problem with your PKGBUILD. The build performances set aside. The PKGBUILD [1] provided in the bug report is built much faster.
There's no difference here, and there shouldn't be anyway, drake can be multithreaded make-style with the -j flag or by setting the env variable like it's currently done. Make-style happens to look neater, and the number of threads is configured by the user instead of being hardcoded in the PKGBUILD.
You try to be able to install mkvtoolnix-qt alone without the mkvtoolnix-cli package, right ?
Hmm, no?
Well this cannot work since mkvtoolnix-qt needs the locale/translation.
You don't say. Read the depends array once more.
And since mkvtoolnix-cli *must* be a dependency of mkvtoolnix-qt, there is no point to have the manual mkvinfo-gui.1 which is identical to mkvinfo.1. You can if you want create a symbolic link.
Indeed, in that case I'd rather get rid of the duplicates. If it were up to me, I wouldn't even package the Qt-enabled mkvinfo, the GUI doesn't bring anyhting more compared to the CLI tool, and if people need a GUI, I would highly recommend MediaInfo instead.
[1] http://pastebin.com/rtguGrbR
@Benjamin: Feel free to give the diff a spin before we push it, it's
working
fine here, the only gripe I have with the new GUI is that the left
toolbar
is completely black, but that may just be because my desktop is powered
by
GNOME.
-- Maxime
There's no difference here, and there shouldn't be anyway
In the PKGBUILD the first "drake" doesn't build everything: ./drake apps:mkvinfo != ./drake
You try to be able to install mkvtoolnix-qt alone without the mkvtoolnix-cli package, right ?
Hmm, no? You don't say. Read the depends array once more.
Oops, sorry, I should have read the PKGBUILD more than once.
Indeed, in that case I'd rather get rid of the duplicates. If it were up to me, I wouldn't even package the Qt-enabled mkvinfo, the GUI doesn't bring anyhting more compared to the CLI tool, and if people need a GUI, I would highly recommend MediaInfo instead.
I cannot say that I am not agree :-)
Benjamin
On Tue, Sep 29, 2015, 9:52 PM Benjamin Robin dev@benjarobin.fr wrote:
There's no difference here, and there shouldn't be anyway
In the PKGBUILD the first "drake" doesn't build everything: ./drake apps:mkvinfo != ./drake
You try to be able to install mkvtoolnix-qt alone without the mkvtoolnix-cli package, right ?
Hmm, no? You don't say. Read the depends array once more.
Oops, sorry, I should have read the PKGBUILD more than once.
Indeed, in that case I'd rather get rid of the duplicates. If it were up
to
me, I wouldn't even package the Qt-enabled mkvinfo, the GUI doesn't bring anyhting more compared to the CLI tool, and if people need a GUI, I would highly recommend MediaInfo instead.
I cannot say that I am not agree :-)
Benjamin
Oh, I thought you were talking about the multithreading. I guess that trick can be used to do things the other way around and build only mkvtoolnix-gui in the second build folder. I'll have a look tomorrow and remove mkvinfo-gui, I guess most people will agree that it's unnecessary to package it.
Cheers, -- Maxime
Hey,
the MKVToolNix author here. First of all I appreciate all the effort of packaging MKVToolNix for Arch. Thanks for that.
The orignal PKGBUILD in the repositories builds the whole of MKVToolNix twice, once configured with GUI support, once configured without it. However, this is not really necessary.
Being configured with and without GUI support only affects two programs: mkvinfo and mkvtoolnix-gui. If configured with GUI support then mkvinfo will be built including a Qt-based GUI in addition to the always-included text mode interface, and mkvtoolnix-gui will be built in the first place. If configured without GUI support then mkvinfo will only include that text mode interface and mkvtoolnix-gui will not be built at all.
Therefore the PKGBUILD in the pastebin cuts down on compilation time by only compiling the whole of MKVToolNix once when it's configured with GUI support. For the text-mode only version of mkvinfo you only have to configure MKVToolNix and build mkvinfo (and then preserve that binary over the »drake clean«, of course); nothing else has to be built. Hence the pastebin'ed PKGBUILD being a lot faster.
There's only one version of mkvinfo's man page in my upstream MKVToolNix source, and the installed version is identical in both cases (configured with/without GUI). Therefore including it in each Arch package is indeed wasting space.
The mkvtoolnix-gui (and therefore the Arch mkvtoolnix-qt package) cannot work without the mkvmerge executable as the GUI uses the CLI-only mkvmerge for all of its actual work. Therefore the mkvtoolnix-qt package must depend on the mkvtoolnix package, and preferably of the same version: I only guarantee that mkvtoolnix-gui version a.b.c will work with mkvmerge version a.b.c, nothing else. The GUI will even emit warnings if the mkvmerge executable's version differs. Therefore upgrading the mkvtoolnix-qt package without upgrading the mkvtoolnix package should ideally not be possible.
If you don't want to include mkvinfo's Qt GUI then you still have to do both builds. Well, you could leave out mkvinfo during the with-GUI- configured build, but that wouldn't cut down on compilation time a lot as mkvinfo only consists of three source files on top of the common library.
I don't particularly care whether or not mkvinfo's GUI is included in the mkvtoolnix-qt package. I've created it mostly for Windows users as those are pretty resilient to the advice of using the command line version ;) On the other hand I can really understand them when I think of cmd.exe…
Kind regards, mosu
…and I screwed up the subject. Sorry for that; I wasn't subscribed and tried to stitch the reply to the thread properly. And I've failed, obviously :(
Kind regards, mosu
On Wed, 30 Sep 2015 09:28:33 +0200 Moritz Bunkus moritz@bunkus.org wrote:
…and I screwed up the subject. Sorry for that; I wasn't subscribed and tried to stitch the reply to the thread properly. And I've failed, obviously :(
Mailman provides links to help you with that in the list archive[1]. Just click on the email address of the sender in the second line at the top. It will set the correct recipient, subject and in-reply-to headers. Might be that mutt doesn't support such links though, I don't use it.
[1] https://lists.archlinux.org/pipermail/arch-general/2015-September/039919.htm...
Apart from the subject you got the in-reply-to correct so all is good and threading works properly.
On Wed, Sep 30, 2015 at 9:26 AM, Moritz Bunkus moritz@bunkus.org wrote:
Hey,
the MKVToolNix author here. First of all I appreciate all the effort of packaging MKVToolNix for Arch. Thanks for that.
The orignal PKGBUILD in the repositories builds the whole of MKVToolNix twice, once configured with GUI support, once configured without it. However, this is not really necessary.
Being configured with and without GUI support only affects two programs: mkvinfo and mkvtoolnix-gui. If configured with GUI support then mkvinfo will be built including a Qt-based GUI in addition to the always-included text mode interface, and mkvtoolnix-gui will be built in the first place. If configured without GUI support then mkvinfo will only include that text mode interface and mkvtoolnix-gui will not be built at all.
Therefore the PKGBUILD in the pastebin cuts down on compilation time by only compiling the whole of MKVToolNix once when it's configured with GUI support. For the text-mode only version of mkvinfo you only have to configure MKVToolNix and build mkvinfo (and then preserve that binary over the »drake clean«, of course); nothing else has to be built. Hence the pastebin'ed PKGBUILD being a lot faster.
There's only one version of mkvinfo's man page in my upstream MKVToolNix source, and the installed version is identical in both cases (configured with/without GUI). Therefore including it in each Arch package is indeed wasting space.
The mkvtoolnix-gui (and therefore the Arch mkvtoolnix-qt package) cannot work without the mkvmerge executable as the GUI uses the CLI-only mkvmerge for all of its actual work. Therefore the mkvtoolnix-qt package must depend on the mkvtoolnix package, and preferably of the same version: I only guarantee that mkvtoolnix-gui version a.b.c will work with mkvmerge version a.b.c, nothing else. The GUI will even emit warnings if the mkvmerge executable's version differs. Therefore upgrading the mkvtoolnix-qt package without upgrading the mkvtoolnix package should ideally not be possible.
If you don't want to include mkvinfo's Qt GUI then you still have to do both builds. Well, you could leave out mkvinfo during the with-GUI- configured build, but that wouldn't cut down on compilation time a lot as mkvinfo only consists of three source files on top of the common library.
I don't particularly care whether or not mkvinfo's GUI is included in the mkvtoolnix-qt package. I've created it mostly for Windows users as those are pretty resilient to the advice of using the command line version ;) On the other hand I can really understand them when I think of cmd.exe…
Kind regards, mosu
Hi Moritz,
Thanks for the explanation. I keep thinking that we don't need the mkvinfo GUI.
I tried to use apps:mkvtoolnix-gui to build only that one the second time around. While it works in build(), invoking drake install in install() seems to ignore the argument and goes on to build everything else before installing. Is that expected behavior or am I doing something wrong? Either way, my CPU has seen worse, building the whole thing twice isn't that big of a deal.
Cheers, -- Maxime
Hey,
I tried to use apps:mkvtoolnix-gui to build only that one the second time around. While it works in build(), invoking drake install in install() seems to ignore the argument and goes on to build everything else before installing.
That's correct. »install« is the generic »install everything that's been configured« target. It therefore depends on all the build targets for the configured components.
Note that several things are only installed by the »install« target if the package has been compiled with GUI support, including but not limited to:
- the mkvtoolnix-gui.1 man page and its translations - the icons - the .desktop files - the MIME files
Basically it's easier to run »install« from a GUI-enabled build for packaging purposes, I guess.
Like I said, if you don't need mkvinfo's Qt GUI I still recommend you build the whole package once with GUI enabled, run »drake install« for that, and compile only mkvinfo with the GUI disabled (»drake apps:mkvinfo«). You can throw away the GUI-enabled mkvinfo binary. The PKGBUILD will be simpler to write than if you try to only build mkvtoolnix-gui and install all the things manually instead of just using »drake install«.
Kind regards, mosu
participants (5)
-
Benjamin Robin
-
Bruno Pagani
-
Florian Pritz
-
Maxime Gauduin
-
Moritz Bunkus