RFC: there should be an official GUI

[ghost]

While most mpv developers (including myself) have no interest in developing a GUI, it could be a good idea to make one of the existing GUIs "official". It would be part of the mpv-player github organization. It would receive special attention both by users and mpv core developers. The core would not need to pretend being a GUI as much as it needs now. Users prefer something more GUI-like could be redirected to it. If the core changes, the GUI could get some sort of preferential treatment to make sure it works well with it.

I don't know which existing project would be suited for that, or if anyone wants to try starting one. To make sense as an official GUI, I'd say there are the following conditions on the GUI project:

• portable (Linux/Windows/OSX)
• uses libmpv
• acknowledged by all mpv developers to be good enough (otherwise we don't need to do this)
• developers of that project must be willing to be named as official GUI
• moving to mpv-player github organization

A list of currently known GUI frontends is here: https://github.com/mpv-player/mpv/wiki/Applications-using-mpv#gui-frontends

Any comments on whether this is a good or bad idea, any project nominations, any comments by the GUI developers?

[paulguy]

I don't have much use for a GUI since I like how mpv is just its own self-contained window with no frills around it but it probably would allow more people to be able to use mpv and create more interest for it. Would this kill off the OSC/OSD? I could live without the OSC but I do like mpv being primarily command-line/keyboard driven and just giving status changes on the OSD.

[Akemi]

• portable (Linux/Windows/OSX)

i am probably a bit alone with my opinion, but i think this is a requirement that will restrict potential GUI devs too much. imo just from a usability standpoint it isn't the best idea, since GUI and interface requirements can vastly diverge. i would rather see one GUI per platform or multi-platform projects with one leading/target platform.

i myself had planned to start developing my own GUI, though i never really came around to do it. maybe this could be a good start.

[mc4man]

I've tried at one point or another most of the linux frontends.
bomi was the best, inc. libmpv in it's source, but dead for 3 years with little chance of coming back or being forked.
baka-mplayer is ok but it's dead for a year now
gnome-mpv works ok but is too restrictive being gnome only and keeps requiring newer gnome libs
kawaii-player is unfathomable to start, may get useable with use. I'll never know..
mpc-qt could be good but seems sensitive to qt5 library versions, currently on one older install it now ftbfs, on another with newer libs builds fine, segfaults on start up.
smplayer work fine, actively developed, acts like a gui but uses the binary
xt7 requires gambas3 so users would have to acquire that if not provide in distro, iirc it also uses the binary

[mia-0]

The real problem with mpv GUIs is that mpv by itself is so good most developers lose interest in maintaining them. I originally wanted to do this after letting SMPlayer2 die, but then mpv got almost all the features I wanted so there was no point in all that effort.

[kevmitch]

I think the idea of having a one true app is diminished if there is one for each platform. It also makes the tight coupling that @wm4 is talking about harder.

[Tsubajashi]

Bomi was very nice back in the day, would it be a very hard time to fork and "fix" it? If not so much I would just try to fork it since I actually wanted to have a nice project to work on in my free time.

[pigoz]

portable (Linux/Windows/OSX)

Main problem with this, is it forces it to be basically made in Qt (or Electron rofl). I don't think a single developer has the resources to make a cross-platform application that feels native on windows, linux and macosx.

For example IINA is really high quality from a user perspective, it would be quite criminal to recommend a cross-platform GUI that is worse.

[ghost]

Fine, I guess we can't have something portable.

[Flat]

I'm in agreement with mc4man. Bomi was great while it lasted. In my opinion no other GUI on Linux has the UX to even compete with stock mpv. Iina looks nice, but I'll never use it considering it's macos only. The rest of the GUI frontends for mpv are either lacking any new features over mpv, look like something from the early 90s, or both.

That being said a new GUI that is well designed for UX and includes heavy customization would be welcome.

[ghost]

Regarding Bomi, it used mpv internals, which changed so much in the last years that updating it will be hard. If it had strictly used libmpv, maintaining it would have been much easier. I don't know how much work it'd be to port it to libmpv. You can try.

[orbea]

My suggestion is to make the libretro-mpv project official and use RetroArch (Or any other libretro frontend really) as the gui. This would reduce a lot of the maintenance effort on maintaining the GUI once the initial roadblocks are fixed. @deltabeard would be better familiar with what is left to do.

https://github.com/libretro/RetroArch
https://github.com/libretro/libretro-mpv

[orbea]

Just to make it clear, this would cover the portability requirements (And then some) as well as the libmpv requirement.

[deltabeard]

@orbea Eventually, I would like to see libretro-mpv to be a great contender as an official mpv GUI. There's still some work to do with libretro-mpv before I would personally consider it as a good enough media player, which I've listed here.

There may be some limitations with Retroarch too, such as playlist support, which would need to be addressed. There was some discussion here with regards to that.

[SilverEzhik]

The core would not need to pretend being a GUI as much as it needs now

I fear that dropping the OSC, if that's what this suggestion implies, would turn away the users that specifically use mpv because of how simple the interface is.

[Dudemanguy]

Personally I don't care if there is an official GUI or not, but I very much like OSC and would be sad to see it go if that's what this issue implies. The OSC is my favorite mpv GUI.

[stax76]

I currently work on a libplacebo GUI, the necessary code is done, which means I can now define the GUI in INI format.

[tsl0922]

Support for nested lists like tracks/chapters/... are added for the contextmenu plugin now. The menu syntax is documented in the project README.

I've tagged a dev build for anynoe who want to try: https://github.com/tsl0922/mpv-plugin/releases/tag/dev

[butterw]

What are the mpv version requirements to be able to use the menu plugin ?
Does it only work with mpv x64 v3 Shinchiro v0.37 ?

As mentionned in the readme, you now need to add a keybinding for the menu to show up, ex, input.conf:
MBTN_RIGHT script-message-to menu show

[stax76]

Maybe better to rename it to mpv-menu-plugin or if you want to do more mpv-gui-plugin.

[tsl0922]

Does it only work with mpv x64 v3 Shinchiro v0.37 ?

the cplugins support for windows was added in 0.37.0.
shinchiro build is not a requirement, but the the cplugins feature must be enabled when compile mpv.
I have updated the project README for mpv requirement.

Maybe better to rename it to mpv-menu-plugin

done

[tsl0922]

Also if it doesn't end-up overly complicated and would be customizable we could even consider upstreaming it to core mpv.

@kasper93 now the code is over 500 lines, most of them are handing property change and menu update. so if we are going to upstream this feature, I would recommend moving the menu update logic to a scriptable language:

• mpv: watch the menu definition from a property, create menu on the fly
• lua: a user may set the property to create/update menu definition

then we can create a lua plugin that can load mpvnet or uosc style menu definitions from input.conf, or just create any custom menu items the user wants with code.

BTW: we can extend the support for this menu definition property to any other platforms later too (my plugin is windows only).

[tsl0922]

You can now use the Debug tool from ImPlay on mpv as a cplugin:

• Visual view of mpv's internal properties
• Console with completion, history support
• Colorful mpv logs view with filter support

https://github.com/tsl0922/mpv-debug-plugin

[butterw]

Request for a simple modern seekbar
mpv should provide an option for a simple clean hidable seekbar (nice looking, usable in a small window, some configuration options, no extra features) and neither osd-bar nor OSC can currently achieve this. I haven't seen it done in user scripts either. Some OSC replacement can provide a modern seekbar, but they tend to be bloated and broken at ex: 3000 lines of lua code.

[Kagami]

#5500 (comment)
Many have built a frontend, with an own main window implementation, which has the huge disadvantage of loosing all the rich cross-platform window functionality mpv already has.

I agree, it seems too much work to build frontend for every platform, especially because mpv already works on many platforms, so it feels unnecessary. Most devs nowadays use Electron and Qt for cross-platform apps (that work on Windows, Linux and macOS) but both doesn't feel very nice and people would switch to another app once it's available. (With VS Code being the only major exception.)

So the extension approach seems better. So considering this, is anyone aware of some kind of Lua-widgets-for-mpv effort (or JavaScript)?

I've looked into existing Lua user scripts with a lot of GUI elements and found:

• built-in osc.lua, 3k lines (and also many forks listed here)

This doesn't look very reusable. If someone wants to re-create similar UI, they would need to just copy it and heavily modify all over the place.

• uosc/elements

This looks better, I had something like that in mind regarding "Lua widgets". But again, not sure how reusable those Lua modules are.

Does anybody know similar projects?

[tsl0922]

Also if it doesn't end-up overly complicated and would be customizable we could even consider upstreaming it to core mpv.

@kasper93 now the code is over 500 lines, most of them are handing property change and menu update. so if we are going to upstream this feature, I would recommend moving the menu update logic to a scriptable language:

• mpv: watch the menu definition from a property, create menu on the fly
• lua: a user may set the property to create/update menu definition

then we can create a lua plugin that can load mpvnet or uosc style menu definitions from input.conf, or just create any custom menu items the user wants with code.

BTW: we can extend the support for this menu definition property to any other platforms later too (my plugin is windows only).

It is implemented as v2 version now, The core C code that render menu from mpv user property is about 150 lines (excluding the menu syntax parsing logic, can be move to lua later).

[butterw]

On windows (win32 native) c-plugins seems to be the right approach for GUI elements.

Open File Dialog + copy/paste strings to Clipboard have just been added to mpv-menu-plugin in latest actions builds:
tsl0922/mpv-menu-plugin@f396ed1

[tsl0922]

tsl0922: can you provide a build of your plugin ?

You can download from the Actions Artifacts. This plugin is still in ealy development, once the basic functionality is implemented, I will publish a Release soon. (currently missing features: open dialog, nested list like audio tracks)

With the 2.2.0 release, the open dialog and clipboard support was added now, and all the features provided by mpv-menu-plugin are Scriptable (You can modify menu with script, or even update menu state in input.conf with lua expression).

You should give it a try, if you want better native gui experience for vanilla mpv on Windows.

Tip

Why do you add dialog / clipboard support again? There're scripts like mpv-open-file-dialog / mpv-clipboard already!

These scripts are both using PowerShell to implement features on Windows, There may be 1s or above cold start delay on the first time. Another feature that is not supported by the PowerShell Get-Clipboard is tsl0922/mpv-menu-plugin#41.

[Kagami]

#5500 (comment)

So considering this, is anyone aware of some kind of Lua-widgets-for-mpv effort (or JavaScript)?

@ahaoboy just implemented exactly that in mpv-easy. Amazing!

[Solarunit]

I just found this uosc UI (sorry if it was already mentioned before)
It looks very good in the demo, especially menus in the center.
I think something like this would be nice to have as official GUI, maybe disabled by default, but easly activated from the config (maybe shortcut?) or some button from the current GUI.

uosc.webm

https://github.com/tomasklaen/uosc

[ahaoboy]

I just found this uosc UI (sorry if it was already mentioned before) It looks very good in the demo, especially menus in the center.

UOSC is indeed the most comprehensive functionality in Lua scripts. Inspired by it, I have implemented a toolkit mpv-easy using TS and React, which also supports right-click menus and playlist. Although the project is still in its early stages, I believe this approach can bring new ideas to MPV scripts.