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?

[Solarunit]

I think GUI for player is a must-have feature. I am using Potplayer on windows and it is probably one of the best player ever with awesome default settings, hotkeys; it has a very nice minimal OSD-info.

[SilverEzhik]

I went and made a little interactive mockup for the potential right-click menu that mpv could have: https://ezhik.me/mpv-mockup/index.html

Basically, it exposes functionality that is available right now with keyboard shortcuts.

[TingPing]

gnome-mpv works ok but is too restrictive being gnome only and keeps requiring newer gnome libs

Just wanted to say that this isn't accurate. It is generally DE independent (supports both headerbar/menubar style interfaces) and it is very reasonable with its dependencies.

I'm not saying that the author would or wouldn't want to become official just wanted to clarify.

[traktori]

@SilverEzhik why won't anime start playing when I click on it?

[SilverEzhik]

@traktori To my knowledge nobody ported mpv to run within a web browser (thankfully), so I just used two screenshots for the OSC. But if you insist, here's the video.

[ghost]

@SilverEzhik That mockup is great. All that would be needed is a configuration section where users can pick whether to enable hwdec, their choice of video output, the number of audio channels, etc and a full GUI begins to look unnecessary.

[TingPing]

Would it be valuable as a first step to write official bindings for like Gtk or Qt, so other frontends could at least easily consume it?

[nick-s-b]

If someone does create a GUI for mpv, I hope it gets its own project and a new name. mpv should stay the way it is. GUI just gets in the way with every player I've used.

[igv]

nuklear or something similar based UI extensible with lua/js scripts, so user scripts could have their own menus and stuff.

[kkkrackpot]

An official GUI will make mpv more popular -- I find this argument reasonable. Most people just don't know what command line is and don't want to bother with it, no matter how you explain them its advantages. Personally, I have such experience, and no longer advertize mpv on forums and such. Being asked about "What player should I use?" I say "Try mpv if you can, otherwise use vlc, kodi, mpc, madvr or something" A simple GUI with just some most simple and common settings will make mpv more popular. I doubt that it's possible to implement all of mpv's settings in a GUI (however, I'm not a developer). Of course that simple-GUI-ed mpv will be a yet another player -- but it's another question. It may be considered as a starting point or like that. An also I'd note, that up till now I didn't noticed in this discussion anyone (myself included) actually willing to start the work.

[TingPing]

An also I'd note, that up till now I didn't noticed in this discussion anyone (myself included) actually willing to start the work.

Well nobody knows what the work is yet.

If a simple Gtk frontend is wanted I could help with that but nobody here knows what is truely wanted.

[MilkyPL]

MPC-Qt is a good choice for people coming from MPC-HC. Obviously mpv itself should stay the way it is, but the frontend should be endorsed on e.g. mpv.io as the "GUI version" (or the other way around, core mpv as minimal version).

[bakomox]

i agree with others that say use nuklear https://github.com/vurtun/nuklear

[lgbaldoni]

you still have to code against the wxWidgets API and ship the wxWidgets DLL if you want it to work, and even then, it's "native", as in Win32 on windows (while most recent apps use WPF) and GTK+ on linux (so you're leaving on the shed a good part of the linux userbase :p)

@jcelerier doesn't wxWidgets 3.2 have a Qt5 option?

EDIT: it looks like wxQt is pretty much dead in the water 😞

[cj-sv]

I've always thought MPV's OSC was the official GUI. It's so simple and clean, it doesn't get in the way. Honestly one of the reasons why I like mpv. If it does get an official GUi, hopefully it's optional or perhaps a different project altogether.

[Artoriuz]

In my opinion as an user, trying to make mpv look like MPC-HC or PotPlayer will just make it look outdated and ugly. I think extending the current functionality while modernising it with nuklear is the best option to keep the current clean style.

[ghost]

I think extending the current functionality while modernising it with nuklear is the best option to keep the current clean style.

I support this just because it would actually give us more reason to give mpv a GUI: doing something new with an open source video player.

[ghost]

I went and made a little interactive mockup for the potential right-click menu that mpv could have: https://ezhik.me/mpv-mockup/index.html

I mean that's nice, but that doesn't help us with how we should render this.

[SilverEzhik]

@wm4 I was approaching this problem from the opposite end - first deciding what this UI should look like before picking the toolkit. If it's the right-click menu alone, it can be done using built-in Win32/Cocoa widgets, though I am not sure how this would work on Linux - might add a GTK/Qt dependency that may have not been there before.

This does imply that the hypothetical mpv GUI keeps the current OSC. If migrating away from that is what you want to do, then something like Nuklear might be the best option for that - in that scenario, the right-click menu can also be implemented with that.

[Solarunit]

These screenshots from iina project look very nice and modern! https://lhc70000.github.io/iina/features/

Love the idea of side-panel for Video, Audio and Subtitle settings!

[haasn]

Would anybody even care about iina if they didn't provide shitty frosted-glass effects that won't work on every platform anyway?

[SilverEzhik]

That's just a part of macOS' visual style. IINA is pretty damn cool, but it's 200% a Mac application. There are lessons to be learned from it (the settings that it allows changing, for example), but beyond that, there probably isn't a whole lot of reusable code that can work well on Windows/Linux.

[Solarunit]

Could nuklear be used to implement IINA side-panel concept even without glass effects? https://github.com/vurtun/nuklear

[ghost]

nuklear is being mentioned a lot, but it has the following problems:

• we'd have the font loading & rendering rendering problem again and would have to make a libass backend for it or so
• it's an immediate GUI, which is not a good match to make it usable from Lua
• it's a single header thing which causes all kinds of issues

[haasn]

FWIW I did play around with nuklear a bit (and also wrote some mpv integration code) and basically came to the same conclusions as @wm4

• immediate mode GUI is probably not what we want; we'd be more interested in an asynchronous/event-driven GUI so we can expose it to lua user scripts without the dreaded “UI logic inside main rendering loop”
• single header library is just complete bullshit, and it would at the very least have to be forked and cleaned up first
• it's basically undocumented unless you consider “the source code” to be adequate documentation
• libass font handling integration would potentially be a nightmare

[DiabolusExMachina]

Hi,

just my 2 cent's as a someone who currently switched to mpv. I love the current ui because it is so minimalistic.

Like Antoine de Saint-Exupery said:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

The only thing I whish I could do is edit the mpv.conf file more intuitive. I'm a big fan of Visual Studio Code and how they deal with settings. There are no complex dialogs. You basically edit a text file but you see the available settings and the documentation. I wish there would be something similar to mpv.

You can see it in action here: https://code.visualstudio.com/docs/getstarted/settings

[ghost]

With respect to particular toolkits needing a lot of libs in the same folder as the executable, static builds are also available for them where from what I read the only files in the folder would be the exe, the c/c++ runtime library dll and the mpv dll (if it can't be statically linked). This is in the context of a third-party application.

For cplayer, it would seem that the existing osc could be made more robust with a hamburger menu in the top-right corner, revealing a similar tabbed layout to iina. File-open dialogs can be made from lua right now with zenity --file-selection, gtk file picker meme not withstanding.

[Lastique]

I don't see the point of declaring something "official", especially if not portable. People will choose whatever frontend they like, and that is a good thing. Let mpv deal with what it's best at - actually playing the content. If there's anything to do, it's to improve the ability to control mpv from an external frontend.

[Samillion]

Either I'm confused or many people here are confused.

The discussion is about an endorsement of sorts, of a GUI, not completely overhauling and turning mpv into it, correct?

Everyone suggesting that mpv would change, it wouldn't. The same packages will be there, with just an addition in the list "For a GUI, try [insert-name]". At least that's for the front end of business.

Behind the scenes the GUI will get attention from mpv developers and its community.

That is all. I see no problem whatsoever if there is a decent enough project out there that would enhance the mpv experience for both the tech savvy and your average Joes.

I'm honestly surprised that SMPlayer hasn't been mentioned more. It's cross platform, Qt and offers portable packages.

The only problem I have with SMPlayer is the inability to hide the top menu bar, and this is me being extremely picky. I still use it as my default player on Windows and Debian.

It has an extensive set of options, and you can pass mpv options easily in its advanced preferences.

Whichever GUI is picked, I honestly think this would be a great move. mpv is greatly underappreciated simply because it mostly caters for power users. Which is fine, great even, but with this it'll introduce a whole new experience for a new set of users, like I said, the average Joes.

If there is ever a vote, I'd go with SMPlayer for Windows/Linux and IINA for MacOS.

[wiiaboo]

SMplayer doesn't use libmpv, so it's entirely unlikely to get picked.

[Samillion]

@wiiaboo Ah. Shame. Only assumed it does because it has an option to use mpv engine.

Either way, I honestly can't wait to see which GUI project will be picked.

[mhertz]

TrendaFet, well, it started like that, but the lead-dev didn't seem especially against thinking about incorporating right-click menu's or alike, which made some of us slightly nervous ;) I apologize in advance if i'm mistaken here.

There's also something to be said about not being mainstream/widespread, to not e.g. get the issues section spammed etc.

[Samillion]

@mhertz That's a great point about the issues section being spammed. If the original suggestion holds, as in both projects would be separate, just teamed up, I think it can be avoided. Though I could be completely wrong.

Also, about the GUI changes, yeah, that's why I said I could be misunderstanding this as well.

[Solarunit]

IINA GUI video https://www.youtube.com/watch?v=PKBhVvfoSpY

[Stefan986]

If this is to be done properly, complete GUI is a must. Context menu only idea is just not sufficient, there is no way to select font, font colour, sub coding, or any subtitle related settings at all. It would go way too deep into submenus, and that is subtitle only. What about screenshot format, compression, size, destination folder... you see where I am going. A lot of settings needs a dropdown menus, pickers, sliders etc.

Cross-platform is another issue with two approaches

• to go with uniform app look on all platforms (better one, in my opinion)
• or making different app look for every platform to represent OS design language, which is insane for free non-commercial video player to maintain

I am not a developer, so I don't know how difficult is it to make uniform app look and how to do it, so I'll skip commenting on that part at all.

From an user perspective, MPV's current simplicity is good and bad at same time. It is too bare-bone for my taste and requires keyboard all the time (making and editing mpv.conf and input.conf was difficult to get used to, ant it is a no-go for most of users), but I still proffer MPV to likes of VLC, PotPlayer, MPC-HC, SMPlayer because on the other hand these players are too cluttered with so many stuff, menus and buttons crammed into main window (SMPlayer has 22 options in Subtitle context menu alone, just counted). The balance would be, of course, somewhere in between.

Main windows should stay simple and clean as it is now (adding Preferences button), carefully selected few for right click context menu and full Preferences window like all other players have where all player related settings should be. I had an idea how faster and more versatile mouse controlling can be achieved explained in issue #5496.

Having all non-default settings stored and set in mpv.conf, advanced users can use it for super-fine tuning with total of 782 options with current version of MPV which majority of users wouldn't ever need.

[deltabeard]

I don't really get those Retroarch ideas. Isn't it a game emulator frontend? How does that make it a good fit for a media player GUI?

Retroarch is a libretro frontend, that can play libretro cores. Other libretro frontends exist, such as Phoenix, and minir. All libretro frontends should be able to play any libretro core.

So libretro-mpv will not only work with Retroarch, which is best used with a game pad, but with other libretro frontends such as minir which is focused on using keyboard and mouse input.

[ivanbalashov239]

Why would anyone need an official GUI if it's not gonna be supported by core developers?

If core developers want popularity for mpv, they should develop gui themselves, or beter fork existing one, like bomi(it's actually the best one, but abandoned)

Or at least gui for settings and preferences and maybe userscripts repository, so people will use them more.

[Djaler]

Yet another vote for bomi. It's a coolest video player ever. I like his UI and UX so much. But yes, it is abandoned, so your support will be very important for all bomi users.

[wiiaboo]

But yes, it is abandoned, so your support will be very important for all bomi users.

No core mpv dev is going to directly support any GUI, to be clear. That's not the point of this RFC. Especially not an abandoned GUI not using libmpv.

Supporting a GUI comes with a whole bunch of issues and needs specific expertise to that front.

[ivanbalashov239]

@wiiaboo but maybe you could consider to support gui mpv config editor? It stil will be geeky but more understandable for newbies.

[wiiaboo]

That exists already https://github.com/MattMcManis/Glow. Also, the manual seems much more user-friendly that this. At least in the manual you can ctrl+f.

[ivanbalashov239]

@wiiaboo personaly i think the only better solution then current mpv config is turing complete config and addons/userscripts package manager

But for newbies gui like Glow with search function could be more suitable And it probably better be crossplatform.

the only problem everyone who can develop something like this don't need it.

[ghost]

@wiiaboo That is useful but all of that should be built into an official GUI along with mouseover tips on what is best for certain hardware as I often see newbies asking things like "What hwdec should I use for my X CPU and Y GPU?"

Or just add such advice to the official documentation.

[Djaler]

Also, I think I should summon @d-s-x, author of the most actively developing bomi fork

[wiiaboo]

mpv's source on that fork is still 3 years old. How is that considered "active developing"?

[Djaler]

You can see actions in this directions in one of branches

[ivanbalashov239]

@Djaler https://github.com/d-s-x/bomi/issues/10#issuecomment-353769812 i have bad news for the fans of bomi, if it's true, then there is no future for bomi as an mpv gui, without reimplementation it as a nonfork

[d-s-x]

@wiiaboo, it's not "active", it's "most active" yet stagnant.

@Djaler, Sorry, but I'm not that interested in developing bomi. I just realized that I rarely use it these days. And when I use it it's fine as it is (with my patches :wink:).

[ghost]

@seniorivn Bomi was always kind of a bloated mess. It never kept in line with the minimalism of mpv.

[SatoMew]

@Akemi Would something like libui be helpful for a cross-platform GUI? It fits in on each OS by default though it is by no means perfect.