mpv
mpv copied to clipboard
mpv-player
RFC: there should be an official GUI
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?
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.
- 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.
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
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.
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.
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.
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.
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.
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.
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
Just to make it clear, this would cover the portability requirements (And then some) as well as the libmpv requirement.
@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.
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.
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.
A right click menu could make for a great compromise between usability and minimalism, although that might cause issues to those who prefer right click to pause.
Has anyone thought of splitting cplayer from libmpv? If enough people want that to be an official gui, development on it could happen in independently without polluting the libmpv commit history.
There is barely any advanced multi-platform app that I know with a good, native feeling, nice looking GUI across all supported platforms. The work required together with the resources hit (more disk space, dependencies, GPU complications) would probably not be worth it for many. I think the community should rather step in and provide wrapper apps like IINA that take advantage of really specific OS frameworks and functionality to provide native GUI apps, while maintaining powerful mpv features of course. Most current mpv users are probably satisfied with the current setup anyway (why would they be using mpv otherwise?), and newer, less technically inclined (?) users would probably not really feel at home with a half working, semi-intergrated GUI app and would prefer more catered solutions.
It would maybe a good idea to point people to apps like IINA on the homepage for one click GUI solutions for the people that prefer that.
A right click menu would make a simple GUI, but still requires a GUI framework on Linux. Unless we do it ourselves (in ASS?), which would be complicated again. I agree it's probably a good way to bring a lot of GUI-like functionality to mpv CLI, but on the other hand it furthers the "pretend being a GUI" issue. Anyway, if someone has a good Lua script for this, we could consider including it as builtin.
Splitting cplayer would not make that much sense, because the libmpv API uses a lot of cplayer functionality. Even the CLI output and the status line can be helpful for debugging libmpv things. This is just a consequences from the fact that mpv originated as CLI only application that was later turned into a library.
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?
I'm not a developer and actually don't use any GUI with mpv. However, I'd say that having an official GUI seems beneficial as long as it allows to get rid of "pseudo-gui" features inside mpv (though personally i have no problems with "pseudo-gui" so far), and as long as gui development follows mpv development but not vice versa.
As for me, existing OSC is good enough: mpv is excellent at keeping it lightweight, simple and persistent across different platforms. The only feature I'm lacking a lot at this moment is "boss key", which could be easily implemented with Lua scripts as long as #4661 is implemented. There is also file thumbnailing, but I imagine it is pretty hard to do this in a crossplatform way and there are applications for this anyway.
Main problem here is that text configuration might be too much for casual users and it scares a lot of people. As I see it, implementing an official GUI can help, but it seems like an overkill. Keeping a list of good enough applications on mpv.io (like Git does) would be pretty nice.
I see no reason to create a GUI, I believe the current way is perfectly straight forward and easy enough even the average Windows user would figure it out pretty quickly.
@wm4 There's really only 2 options here, neither of which involve using any of the existing frontends:
-
Make a right click menu a permanent part of mpv, giving us all the major functionality, organized in a logical manner. This would be the simplest option for everybody.
-
Create a VERY basic, multi-platform UI from scratch similar in design to MPC-HC/mpc-qt. The reason it has to be done from scratch is that the frontends you listed all have issues in some way and we will never get a consensus as to which one we can adopt as an official UI. It's best to start from scratch in the most basic way possible with direct input from the community. The only difficult part will be finding somebody willing to build out such a UI. If we can't find somebody to do that, we simply have to default to option 1.
@The-Soulless The average Windows users is a point and click person. They are not going to edit conf files unless they are an enthusiast who is more than willing to try new things, and such Windows users are rare. At the very least, Windows users need a right click menu in addition to the current OSD so they don't have to edit conf files. However, they would feel most at home with a basic UI that looks somewhat like Media Player Classic. Once a Windows user sees playback controls and drop down menus as soon as they fire up mpv, it will be nearly impossible for them to get confused. This is why we need to first consider making a basic UI from scratch and if that isn't possible, default to adding only a right click menu.
Taken from Google's Xi Editor project:
Design decisions
Here are some of the design decisions, and motivation why they should contribute to the above goals:
Separation into front-end and back-end modules. The front-end is responsible for presenting the user interface and drawing a screen full of text. The back-end (also known as “core”) holds the file buffers and is responsible for all potentially expensive editing operations.
Native UI. Cross-platform UI toolkits never look and feel quite right. The best technology for building a UI is the native framework of the platform. On Mac, that’s Cocoa.
[.....]
Against cross-platform UI, for Native UI, facing a similar problem. I don't see how it should be possible to get around that, even aiming for a very basic, multi-platform UI. Let's say we just start with a simple right-click/context menu, how should this be done in a straightforward cross-platform way? I would not know..
Personally I'd say that Qt is not too bad, but the habit of shipping each app with its own integrated Qt libs is absurd. It would be better if it were possible to use a system-wide Qt installation, but the problem is how to rely on that on different platforms, I guess. I haven't really seen this solved, and this should actually be the important first step. It's really as they say, I guess. Pick your poison.
@Cormak
Make a right click menu a permanent part of mpv, giving us all the major functionality, organized in a logical manner. This would be the simplest option for everybody.
Unless it only exposes a basic set of functionality, or some sort of a settings screen, it will become a submenu hell.
If it's the submenu system alone, it would be reasonable to basically expose the functionality bound to the keys, and more granular controls over things such as choosing audio tracks (showing all at once, as opposed to going through each one by one).
Create a VERY basic, multi-platform UI from scratch similar in design to MPC-HC/mpc-qt. The reason it has to be done from scratch is that the frontends you listed all have issues in some way and we will never get a consensus as to which one we can adopt as an official UI. It's best to start from scratch in the most basic way possible with direct input from the community. The only difficult part will be finding somebody willing to build out such a UI. If we can't find somebody to do that, we simply have to default to option 1.
We come back to the UI library problem. It's native or get out - dragging Qt or (god forbid) Electron in would be unreasonable.
The average Windows users is a point and click person. They are not going to edit conf files unless they are an enthusiast who is more than willing to try new things, and such Windows users are rare.
The way I see it, the average user you describe doesn't even care about whatever the config files offer. They open a file in mpv, play it, and go on with their lives. There is a discoverability problem in terms of keyboard shortcuts, but exposing all of mpv's hidden options all at once would turn the simple interface into hell.
At the very least, Windows users need a right click menu in addition to the current OSD so they don't have to edit conf files. However, they would feel most at home with a basic UI that looks somewhat like Media Player Classic. Once a Windows user sees playback controls and drop down menus as soon as they fire up mpv, it will be nearly impossible for them to get confused. This is why we need to first consider making a basic UI from scratch and if that isn't possible, default to adding only a right click menu.
Exposing config functionality via a right-click menu would get very messy - it would get big and painful to navigate.
The way I see it, there are three things that the hypothetical complete UI, if you really want to go down this route, would need to have.
- OSD
This already exists, and this is already good - don't do anything - maybe add a discoverability option to keep the OSD on-screen when paused.
- Right-click menu
This should expose the options offered by the default set of shortcuts, things like taking a screenshot, looping the video, and a few extra options for things like opening new files. Basically, this would be for non-persistent options, things you change for the current video/playlist.
- Settings screen
This is the place where the .conf functionality would be exposed, giving people control over that. These are the persistent options, and would be stored in the preferences.
Now, how this should be built is a better question. Right-click menu is simple enough - not worth bringing in a big UI toolkit in for a context menu. It can essentially be the same list for all platforms (or even something exposed as a separate config file). That'd take coming up with the list of menu items, then some per-platform code to draw the described menu with native Win32/Cocoa/GTK widgets. You could even add an API to let scripts add their own menu items.
The settings screen will be harder. Here's a sample of representative settings screens from various platforms:
Things are similar enough that you could, in theory, get away with the list of settings and the groups they belong to, then write some Win32/Cocoa/GTK code to make the settings window and draw the corresponding checkboxes and option pickers.
This settings screen could actually live in a separate executable - then in the actual mpv executable you'd just need a little piece of code that puts the "Settings" option in the right-click menu if mpv-settings or whatever the settings executable would be called exists.
That's the best approach to cross-platform UI that I can think of that also avoids the issues of non-native UX and of adding external UI toolkits as dependencies.
mpv's OSD already does a good enough job at exposing playback options, so it should just stay the way it is. A right-click menu would be nice to have, for improving discoverability of more interesting options that are currently only usable through keyboard shortcuts.
The one missing piece here is working with playlists - I never particularly did anything more advanced than queue a folder's worth of files to play, so I'll need some feedback from others on this. I would, however, advice against turning mpv into a full-blown media manager - as then the UI approach that I'm suggesting would quickly break down.
@wiiaboo @SilverEzhik Have you guys even seen right click menus these days? The ones in popular players like VLC, MPC-HC, etc are all quite lengthy and do a lot. Also, playback functions should be left to the OSD, while everything else should go to the right-click menu. There's no point in putting play, stop or enable/disable subs in the right click menu. The point of the right click menu is to customize the player so that new users can tailor mpv to their hardware and make mpv behave the way they want.
I personally would prefer to create a brand new, basic, MPC-HC-like UI from scratch for all platforms with a dedicated settings screen, but if that isn't possible, you can easily create a right click menu by simply asking users what they are first most likely to change on a fresh install and using that data to narrow down all of mpv's options to a manageable size. I'd guarantee that people would be most likely to want to do things like enable HW acceleration, change the screenshot format to png, change the video output, change the number of audio channels, etc. Anything that is unlikely to be changed by most users would only be accessible by editing the conf file.
I think most people here can agree that the whole point of all this UI talk is to open mpv to a wider audience and this is easily achievable with a carefully handpicked and organized right click menu.
VLC is not exactly something to strive for, and it also does not expose the kind of settings that you suggest in its right-click menu - instead it exposes shortcuts to preferences and the per-video options in the vein of those I suggested.
enable HW acceleration, change the screenshot format to png, change the video output, change the number of audio channels
These are all already advanced options - which, while I agree with you could be exposed better, have no business in a right-click menu. Stick them in the settings screen.
The best thing about mpv as it is today, if you're the kind of person that does not care about customization, is that it's just the player screen, and that's it. I would advise against turning it into a big media machine in the vein of VLC or MPC-HC, with mountains of different modes and screens.
There is no need for complexity for the sake of complexity.
VLC is not exactly something to strive for, and it also does not expose the kind of settings that you suggest in its right-click menu
@SilverEzhik VLC made the mistake of having its right click menu be mostly redundant by putting playback functions in the right click menu and MPC-HC goes even further and lets you change renderer settings. I think we should let the OSD do the playback work only, while the right click menu acts as a "quick configurator" for functions like changing the number of audio channels, and enabling hardware decoding.
I agree with you that mpv doesn't need to be made more complex, which is why both my options were to create a basic UI or a carefully crafted right-click menu, but if @wm4 is talking about a official GUI, even going so far as to suggest that one of the existing GUIs should be made the official GUI, we should try to steer things into the creation of a GUI more basic than existing GUIs or just adding a right click menu to keep things simple.
Also, I wouldn't call MPC-HC a "big media machine". MPC-HC was pretty lightweight. Moreso than VLC which is also a streaming solution. We should consider MPC-HC or the current MPC-Qt as a good example of what mpv should look like, and then try to make something even more lightweight than those examples.
I think the fact that @wm4 is open to adopting a GUI for mpv is enough motivation for somebody to start creating a completely new, from-scratch, basic GUI for mpv since it will become THE official GUI instead of yet another buggy, bloated frontend with no official support.