This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
RFC: there should be an official GUI #5500
Comments
|
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. |
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. |
|
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. |
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. |
|
Fine, I guess we can't have something portable. |
|
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 |
|
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. |
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:
@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. |
|
What would a right-click menu contain though? 200 options? |
|
Taken from Google's Xi Editor project:
Against cross-platform UI, for Native UI, facing a similar problem. 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. |
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).
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 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.
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.
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.
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.
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.
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. |
@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. |
|
Consider loading menu command list from config file and it should be pretty usable for anyone who wants such feature. Probably little bit more tricky to support nested list like audio tracks, but should be doable even in generic way. (this was the only use-case why I added cplugin support on Windows, hoping someone will do the GUI enchantments) EDIT: Also if it doesn't end-up overly complicated and would be customizable we could even consider upstreaming it to core mpv. |
|
My experience with the context menu in mpv.net is the following: In v7 which is now available as beta version release, I made a large change to how the context menu works, it's documented in the manual:
|
@kasper93 It's supported now. The syntax is taken from mpv.net by @stax76, so you can just drop an input.conf from mpv.net to test it. |
|
tsl0922: can you provide a build of your plugin ? |
Find it here: |
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) |
|
If you need dark mode code, I have this code here: https://github.com/stax76/Everything.NET/blob/master/src/ShellDarkMode.cs I have this code from the MSYS2 terminal code, it supports a dark mode Win32 context menu. I cannot find this code now. |
|
I currently work on a libplacebo GUI, the necessary code is done, which means I can now define the GUI in INI format.
|
|
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 |
|
What are the mpv version requirements to be able to use the menu plugin ? As mentionned in the readme, you now need to add a keybinding for the menu to show up, ex, input.conf: |
|
Maybe better to rename it to |
the
done |
@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:
then we can create a lua plugin that can load mpvnet or uosc style menu definitions from BTW: we can extend the support for this menu definition property to any other platforms later too (my plugin is windows only). |
|
You can now use the Debug tool from ImPlay on mpv as a cplugin:
https://github.com/tsl0922/mpv-debug-plugin
|
|
Request for a simple modern seekbar |
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: 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. 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? |
It is implemented as v2 version now, The core C code that render menu from mpv user property is about |
|
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: |
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 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 |
|
I just found this uosc UI (sorry if it was already mentioned before) uosc.webm |
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. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
and others
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)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?
The text was updated successfully, but these errors were encountered: