Mpv: 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?

[EzeKees]

It seems to me an excellent idea, but for the majority of non-professional domestic users, since I think it is an excellent player and to orient an interface for those people does not seem bad to me.
I am a graphic designer, in case you need someone to make the images of the GUI.

[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.

[elitepleb]

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.

[ghost]

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.

[rien333]

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.

[ghost]

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?

[kkkrackpot]

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.

[dya-tel]

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.

[The-Soulless]

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.

[ghost]

@wm4 There's really only 2 options here, neither of which involve using any of the existing frontends:

1) 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.

2) 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.

[wiiaboo]

What would a right-click menu contain though? 200 options?

[Hrxn]

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.

[SilverEzhik]

@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.

[SilverEzhik]

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.

1. 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.

1. 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.

1. 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.

[ghost]

@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.

[SilverEzhik]

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.

[ghost]

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.

[SilverEzhik]

There's middle ground to be found between the minimalist-to-a-fault suckless approach and the "just throw it all into one big pile of fuck!" VLC approach.

A good piece of software will be capable of being both convenient to use for the average user, and expose all the options a power user could want - without becoming an incomprehensible mess for one, and sacrificing too many features for the other.

[Hrxn]

Is it actually making the rounds on Reddit, or are you just making stuff up for the sake of an otherwise weak argument?

[Starz0r]

@Hrxn Dude is hurt that his project can't be a exclusivity club for those who are technically adept or have good computer skills. A GUI would open a realm of possibly to boost mpv's use everywhere, not just people who know how to use a terminal (even though you don't entirely need one to use mpv for very, very, basic use)

A official front-end for mpv is a amazing idea, and I really doubt there is any reason sizable enough to stop this.

[Hrxn]

Sad. I'm usually in favor of exclusivity clubs. Everyone needs something to brag about, no?

A official front-end for mpv is a amazing idea, and I really doubt there is any reason sizable enough to stop this.

Well, it depends. It's a shit ton of work to actually implement a good GUI, and if that is not a good enough reason to stop this then I don't know what is. But I'm not against it, don't get me wrong.
Whoever feels like doing something here in the end: best of luck.

[jcelerier]

@SilverEzhik

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.

No consensus on existing toolkits does not means that there will be a consensus on from-scratch toolkits. It just means that you will have to compromise, one way or another. Plenty of people would be saddened by having to have yet another widget implementation in memory aside qt, gtk, fltk, and whatever other toolkit.

[ghost]

It isn't because there is no consensus on existing toolkits that there will be a consensus on from-scratch toolkits

You could spawn a second window for the right-click menu and get libmpv+libass to render it. Your only dependency would be mpv.

[nguyenhimself]

Official GUI apps? Probably not a good idea, both technically and, uh, philosophically?

But Officially endorsed GUI apps? Definitely 👍 . Put that to a vote, or decide it among the maintainers yourselves.

For example, with macOS, one mainstay feature for video apps is Picture-In-Picture, which mpv (rightfully) refused to implement as it is macOS-specific. But IINA has that built-in, so that hugely benefits user experience. I'm sure Linux and Windows users can point out similar examples for their OS-es.

[Akemi]

For example, with macOS, one mainstay feature for video apps is Picture-In-Picture, which mpv (rightfully) refused to implement as it is macOS-specific.

that's wrong i never refused to implement it. i even said i might do it when i've got time. you even commented on #3612 where i didn't reject that proposal.

[haasn]

We could also just expand the OSD and improve the quality of its appearance and rendering. For example, instead of using libass-based hacks for the OSD, we could start using one of those fancy immediate mode UI toolkits that have stuff like right click menus solved already.

The major downside is that it probably wouldn't work with obscure VOs like -vo x11 or -vo xv, and possibly also not with whatever shitty hardware overlaying stuff some of those obscure platforms use. But I don't think requiring vo_gpu for a UI would be a sin, honestly. (And we could probably take the current OSD and “deprecate” it as a user script that the 5 people on platforms not supported by vo_gpu could install manually to preserve the current status quo)

[SilverEzhik]

@jcelerier

It's possible to avoid the framework mess at least within the mpv executable if the functionality it needs to provide is very small - namely, the right click menu and the open dialog. It's going to depend on what the vision for this mpv UI is. My suggestion was a way to avoid extra libraries - I have a hard time calling a few ifdef'd calls to draw a Win32/Cocoa/GTK context menu and open dialog a full widget toolkit, but it is also limiting in that adding things like a playlist menu would still be complicated, since this idea assumes the current OSD is kept as it is.

It'd probably be better to first draw up some concepts for what the mpv UI needs to look like and what functionality it would provide before committing to any UI option.

[Riamse]

Main problem with this, is it forces it to be basically made in Qt (or Electron rofl)

I'm not really a gui developing expert, but aren't there libraries like wxWidgets that compile to the actual native gui controls?

[CounterPillow]

but aren't there libraries like wxWidgets that compile to the actual native gui controls?

wxWidgets is hot ass though.

[jcelerier]

@Riamse sure but 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)

[mhertz]

Personally I would be sad to see mpv including some additional GUI additions, but not my call of course... No better GUI exist than already currently implemented i.e. a video-frame and two config-files; one for settings and other for keybinds :)

[paulguy]

I suppose it depends on if the developers want mpv to be a media player for the intellectually elite, since command lines and config files are pretty steep to learn for a media player for someone who doesn't otherwise do much with computers or aren't familiar at all with those things, or whether the basics (transport navigation, track selection, playlists, etc.) should be available for everyone or whether all the nice tweakables should be available for video enthusiasts who aren't necessarily computer-savvy, and various other considerations like that.

It's certainly appreciable that maybe it should be barebones though, considering there aren't THAT many regular contributors doing the work in their spare time that they wouldn't necessarily have the ability to keep up with the core player codebase on top of a GUI (or multiple, as seems to be a popular opinion.), it'd just be a shame if more GUI-centric folks couldn't get a similar tweakability they get from stuff like madvr.

[CounterPillow]

I suppose it depends on if the developers want mpv to be a media player for the intellectually elite

To be fair, you have to have a very high IQ to understand the command line. The invocation is extremely subtle, and without a solid grasp of shell quoting most of the options will go over a typical user's head. There's also wm4's nihilistic outlook, which is deftly woven into his code - his personal philosophy draws heavily from Narodnaya Volya literature, for instance. The intellectually elite understand this stuff; they have the intellectual capacity to truly appreciate the depths of these options and config files, to realize that they're not just configuration- they say something deep about LIFE. As a consequence people who dislike using mpv from the command line truly ARE idiots- of course they wouldn't appreciate, for instance, the humour in --scale=haasnsoft which itself is a cryptic reference to --scale=ewa_lanczossharp. I'm smirking right now just imagining one of those addlepated simpletons scratching their heads in confusion as Niklas Haas' genius unfolds itself on their computer screens. What fools... how I pity them. 😂 And yes by the way, I DO have a mpv tattoo. And no, you cannot see it. It's for the ladies' eyes only- And even they have to demonstrate that they're within 5 IQ points of my own (preferably lower) beforehand.

[paulguy]

From a user's perspective who has never dealt with a command line or editing config files, it really is just unfamiliar and difficult to grasp and might just be totally unintuitive for certain people to not be able to see and adjust the settings. Might not need to go all-out like VLC's settings window, but they do have their simple and advanced mode with that too. I didn't mean to imply people who prefer GUIs are idiots, more the opposite really, saying that certain people might have interest in video and tweaking settings but not necessarily computers, but then a lot of people who prefer command lines and config files tend to not be particularly interested in the interface needs of people who prefer GUIs.

[CounterPillow]

I have an alternative suggestion: an auto-generated GUI configuration tool. It contains all the options as dropdown selection dialogues, with the documentation for the specific selection displayed on the side. The tool parses the user's current configuration and can save it for various purposes such as a portable config, a custom location or the usual user-wide config.

This means users don't have to muck about with finding where the location of the config file should be and creating the folder. We can also make sure to hide or strongly advise against not recommended options, and best of all, if it's auto-generated from some index + the documentation, it doesn't duplicate any maintenance overhead.

I guess it's not quite as "comfortable" to use as a full GUI thing, especially with regards to opening URLs and such, but it can help people's first time experience.

That being said, haasn's suggestion of using a GPU accelerated UI toolkit still seems great to me, because it would allow for some long standing UI headaches to be solved (long playlists, long titles) and give scripts an easier way to make more complex interfaces, with the added benefit of also being faster than CPU-rendered ASS.

[shinchiro]

Honestly, I prefer the 'gui' as now since it looks clean. mpv has thousands of settings and trying to fit some of them will clutter it. Modernize the osc with nuklear also a great idea. I prefer blurred transparency, just like iina (idk whether it's possible with nuklear)

[dd86k]

I'm 100% fine with the way mpv is at the moment.

People simply want to avoid reading manuals and set-up configuration files. The OSD is just right up simple and what makes mpv _mpv_.

RTFM people.

[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).

[ckmox]

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.

[seniorivn]

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.

[seniorivn]

@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.

[seniorivn]

@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

[seniorivn]

@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.

[TingPing]

@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.

WxWidgets already proved years ago that the result of abstracting different platform UIs like that just results in a bad lowest common denominator UI.

Relevant to libmpv usage it has no abstraction of GL rendering it looks like.

[shinchiro]

There's also LÖVE framework which used for 2D games in Lua

[Akemi]

@SatoMew i don't think the root of the problem are the multi-platform framework, but rather the different needs and conventions on different platforms. just having the looks of a platform doesn't give one the feel of it.

[SatoMew]

@Akemi I know. But currently mpv has a basic frontend with the OSC. Would it be preserved in a more elaborate GUI?

I learned about libui from melonDS, which uses it to implement its frontend. If the goal of providing an official GUI for mpv is also to keep it simple and lightweight, then it seems like a good choice.

I think the only thing mpv needs is some sort of menu bar (optional) and/or context menu plus a property window for personalizing the most important settings. Using custom widgets for this seems unnecessary, and that is something that would be easily noticeable on Windows if mpv's UI was built on Qt, for example (it tries to look native but it doesn't actually match the standard OS widgets, see the Windows version of Transmission as an example of this).

Of course, if technical constraints such as those pointed out by @TingPing pose a barrier, then it's not suitable for mpv, in which case an alternative must be found.

mpv is currently already easy to use (either drag a video to its window as the app itself says or set it as the default player) but, especially for Windows, it may need a one-click installer to attract users more so than a new GUI.

These are my 2¢.

[Akemi]

it seems you and others seem to misunderstand this issue. mpv will stay like it is, keeping the OSC as long as it is maintained and not buggy (like any other feature). i believe the goal is to keep all more elaborated GUI stuff out of mpv (and delegate that to a full blown application) and keep the status quo.

this here is about an external program utilising libmpv that should provide a (full blown) GUI, like playlist, preferences/config, etc. obviously when a proper GUI is being developed the OSC won't (or rather shouldn't) be used to get a consistent look and feeling.

so in the end we keep the 'simplicity' of mpv and gain another well maintained and supported alternative for less tech savvy people. if everything goes according to plan that is.

[seniorivn]

@Akemi
i think what most people are struggling to understand is how is that different then current state or just posting links to all those libmpv based projects on main page and in the readme?

[wiiaboo]

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.

[ghost]

It would also fall to an official GUI frontend to provide common features out of the box, where raw mpv would require user scripts that aren't included by default.

[ghost]

It would also fall to an official GUI frontend to provide common features out of the box

We must also not forget to include an easy way to configure mpv via the GUI because a lot of people who come to mpv are hearing about how they can improve video quality according to their hardware and they get dissuaded when they hear they have to assemble a conf file whereas in another player like MPC-HC switching the video renderer was only a few clicks away.

[wiiaboo]

Well, switching video renderer is an option away, or even a key away if you put it in input.conf and need to change that often.

[ghost]

@wiiaboo Switching the video renderer is just one example. People need to be able to enable hwdec for certain hardware, change the number of audio channels, change the various gpu options, keybinds, etc.

It doesn't have to change every single option in the documentation, just the ones that most people are going to change when they install mpv.

[gitterliu]

Is it possible to draw a OSD layer as GUI?

[wiiaboo]

Sure it is. It's called the OSC.

[gitterliu]

@wiiaboo I mean draw a setting screen as well, not only osc.

[Argon-]

Well, of course it's possible for some definition of "possible". Question is, would it be a good idea?
Regarding settings, the problem isn't really about what UI (that's more of a general problem), it's more about generating it based on mpv sources because there are too many options which are changed with a high frequency. Creating such an UI by hand is not an option.

[Samillion]

@gitterliu Like IINA?

I honestly love how IINA looks and functions, from my understanding it would be easier to port it to Windows than Linux. When I say easier, I mean subjectively speaking not that it's an easy thing to do.

Always wanted to use IINA on Windows, would definitely use it on Linux as well but platform differences and GUI limitations would be an issue I would think.

[wiiaboo]

Well, unless iina's dev suddenly decides to refactor it to some other language other than Swift, for some reason, I very much doubt iina will come to Windows.

[Samillion]

Yeah, it was wishful thinking really. All the active GUI projects that I'm aware of seem to be dedicated to a specific platform or they don't use libmpv.

Baka probably is the most suitable candidate considering the mentioned requirements, but it needs someone to take over development or fork it. I'm honestly surprised it hasn't been picked up already, but understand that it is no easy task.

[Akemi]

swift really isn't the major problem here, since it's open source and at least also somewhat supported on windows besides linux and macOS. the problem here are the various macOS only cocoa frameworks that are used for the look, feel and eye candy. it's plainly impossible to port this without throwing away everything and rewriting, and that can't be called a port anymore imo.

[Samillion]

Ignore my question if it will cause problems, I'm just curious.

Does the mpv dev team have consideration or preference toward a specific GUI project out there?

I'll be completely honest, it seems kind of an impossible task to pick a GUI project that already exists, mainly due to inactivity and multi-platform support.

In my opinion, something like Glow getting more attention would probably be the best bet, at least one that won't require massive projects to be started or restarted.

[Et0h]

I think having a menu bar and/or a context menu will make new users familiar with more traditional media players feel a lot more comfortable with mpv. After they get used to "the mpv way" they can always disable these elements (or go from 'mpv official GUI' to 'mpv classic') to give themselves more screen real estate and so they can use right click for other things, but it will at least prevent new users from being overwhelmed by how different it so that they are used to.

I don't think all of the most advanced features have to be easily accessible, but things which improve performance would be helpful as we don't want people to just run it, get poor video performance, then leave. There's also an issue that accidentally pressing a key will do things that can be hard to undo unless you know how, so if we are to retain the current keybindings then there needs to be an obvious way for people to reset settings that can be changed by pressing keys (e.g. gamma) to their default state.

If there is an official GUI then I think it is important that it supports software which can currently run and then control mpv via stdin/stdout such as Syncplay. I know IINA labelled Syncplay support as 'low priority' (https://github.com/lhc70000/iina/issues/396) so I'm guessing it doesn't support Syncplay yet.

[ghost]

@Et0h A menu bar would actually make more sense than a context menu. It would just be added to the top of the current window and be more obvious to new users than a context menu, while keeping the right click functionality as it is.

[Solarunit]

@Cormak right click = pause video? I don't like this default behavior. I expect to open a context menu by RMB. Sure in the settings there may be options how to pause video: left click, double left click, right click...

[Et0h]

@Cormak The menu is obvious to access when in window mode and a context menu works well for if you are in full screen mode. Why not both? Old-timers can always change RMB functionality to its old behaviour.

@timofonic Syncplay already exists and supports mpv (alongside other media players). If someone wanted to make an implementation of the Syncplay client entirely inside mpv/libmpv (or any other player) then they could take that on as a project as the protocol is public.

In addition to the official implementation at https://github.com/Syncplay/syncplay (Python 2.7) there are some alternative implementations of the client by Irfan available from https://github.com/mo3rfan/syncplay-java (Java) and https://github.com/mo3rfan/syncplayer (Android) and https://github.com/mo3rfan/syncplay-web (Javscript). These alternative implementations include the basic functionality but not all of the more advanced features available in the official Syncplay implementation.

[ghost]

@Solarunit I don't like it either but other people said they didn't want a context menu because it would take up a function, so the menu bar would work for me, is all I'm saying. This is of course, assuming there will be no settings page. It seems like a settings page is too much for most people here.

@Et0h It sounds like a lot of people here want the most minimalistic solution possible so I was just fleshing out what would make for a bare-minimum GUI. I don't really care if people want a full MPC-HC GUI or a solitary right click context menu, as long as it makes mpv more accessible to people.

[ghost]

Just bring back the MPLAYER MENU. It's better then any GUI.

[ghost]

Just bring back the MPLAYER MENU. It's better then any GUI.

Do you think there's anything salvageable from it?

[ghost]

Do you think there's anything salvageable from it?

I dont't understand what you have in mind.
It can do the same things as GUI, but it is customizable and very useful if you have a remote control.
So if the source is bad, you can just write a new one, perhaps in LUA.

[ghost]

@cranes-bill At this point, it's best to start from scratch. The existing GUIs are either incomplete or not ideal. MPlayer Menu is not suited to a modern player like mpv.

This thread isn't helping the situation because it still leaves open the possibility of adopting an existing GUI. The mpv community should seriously start to brainstorm what an original GUI should look like and find somebody to take upon the task of creating a GUI, making sure to create something as minimalistic as possible instead of piling it with bloat from the onset.

[lgbaldoni]

What do you make of mochi-player? It looks like a fork or a reimplementation of Baka from the same author.

[v-fox]

Sorry for bringing noise to this giant thread but I really frustrated that this ingenious idea had almost no support and didn't get any traction:

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 know how versatile and important libretro/RetroArch is/are BUT their UI is horribly over-engineered with no semblance of usefulness, similarly to VLC but even worse. Even for experienced hacker using them from CLI is easier and more reliable than messing with that monstrosity of the UI that can't even list available media files properly. AAAAND for any other way there is the toolkit/portability problem…

BUT all you really need from mpv UI is a simple and fast __visual method of accessing only by mouse, touch or gamepad__ (basically, pointer device) its track selection, playlist, filter effects, playback & general media stream stats and most important options such as bindings __without the need to remember any hotkeys__. Maybe also with that fancy hovering thumbnail/preview seek-reel from Bomi with an addition to audio track's spectrogram (or/and spectrogram-like moodbar reimplementation from Clementine which is better for visualising sounds from music than from video tracks, that thing is simply genius). By doing it in __ASS, LUA and other internals__ you would get it to look nice, to work fast and even to have nice integration with possible LUA-based scripts which would be able to add their own graphics and settings into UI, acting as fully-fledged addons. Maybe then add automatic network-based updates for all scripts and shaders (update URLs can be set in them by their authors) residing in mpv's user directory.

mpv+ffmpeg is already a super-media-amalgamation in itself, might as well use that to the fullest. With some Vulkan/OpenCL/super-multi-threaded motion-based interpolation mpv can bury all other players but that's another matter entirely.

[deltabeard]

libretro/RetroArch is/are BUT their UI is horribly over-engineered with no semblance of usefulness

libretro-mpv aims to work with any libretro frontend. Retroarch happens to be the most popular implementation of the libretro frontend. Another libretro frontend could be created, and if it conforms to the libretro API, it should be able to work with any libretro core such as libretro-mpv.

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?

The libretro API is not limited to just emulators. If Retroarch is not a good fit for a media player, another libretro frontend could be written to resemble a traditional media player. One of the motives for making libretro-mpv was to allow users of Retroarch to play media without leaving the application --- like how a modern game console can play movies. But as mentioned above, a libretro frontend could be written to resemble a media player specifically, if preferred.

[v-fox]

libretro-mpv aims to work with any libretro frontend. Retroarch happens to be the most popular implementation of the libretro frontend. Another libretro frontend could be created, and if it conforms to the libretro API, it should be able to work with any libretro core such as libretro-mpv.

Indeed and in theory it couldn't be any better. That's why I cannot fathom how RA came to looking as it does and being horrible with all possible input methods. I feel like one can write a thesis on UI design by analysing everything that is wrong with it :(

Thinking about mpv UI I want to add: with using internals it would be better to __not focus attention on menus__ and instead think about context-sensitive overlays (such as in fullscreen-mode of some image viewers). You can put at least 4 different types of them being triggered just by hovering the cursor to edges or corners of the screen, for example. Avoid using text and prefer visuals, even if it's something simple as single pictograms from specially-crafted font. Wouldn't even need to translate it which would also get rid of the need to align entries because of their size differences.

[ek4]

Just bring back the MPLAYER MENU. It's better then any GUI.

This.

[brontosaurusrex]

Personally I'd like to see the ability to mice rearrange playlist (and drag drop files or urls to that playlist in specific position) in mpv-hud-gui itself. p.s. Gui not taking any screen pixels is an absolute win.

[uralets]

There are things that a media player can benefit from which are awkward to implement without some sort of a GUI model.
Eg having an actual playlist, direct audio/subs switching, MRU list, context menus, etc.

I'd prefer having mpv alongside eg gmpv with a built-in GUI (rather than master/slave style).

I'll get my coat..

[Blast-City]

Just a gui that would replace (same options) the osc when in window mode would be great.

This way the osc would not cover the subtitles when mpv is not in fullscreen mode.

[lgbaldoni]

Since mpc-qt has been abandoned, perhaps someone might want to take it over?

[stax76]

As author of the Windows GUI mpv.net I don't know what I should think of an official GUI, it might make my little project obsolete. I still have fun working on this project and feedback started to increase slightly in the last two weeks.

If I had to do a cross platform GUI I would use Electron or QT Quick.

[omeringen]

Simple and functional, i like the Bomi's GUI. Looks like the maintainer is not active anymore.

[stax76]

Unfortunately on Windows 10 with 288 DPI I think Bomi GUI is not working, so I cannot examine it.

[barolo]

I would like to point into direction of smplayer with MPV backend, while it's defaults are horrid, after switching to native skin and minimal UI it's decently looking and fully featured player.

[DoTheEvo]

Please please be inspired by bomi.

If sole backend starts to be boring please check it out.

At first maybe just try to implements its playlist idea, how it integrating to the edge of the window and how it keeps transparency and scrolls unlike current one.

https://i.imgur.com/qi4l0vE.gif

[stax76]

It's nice but there are more important things like working High DPI support.

[pigoz]

Did you know it's Walpurgisnacht?

[ghost]

If you want Bomi, you only need to port it to libmpv.

[TheOddler]

For me the only two things MPV is missing right now are, that are not easily added with plugins, are:

1. Opening files in the current/existing window
2. Remembering the position of the window (not the position of the video)

Both of these things seem to need at least some native code that can't be added with pure js/lua scripts.

Other than that I like the very minimalist OSC right now, and don't mind the text-based settings.

[stax76]

Create a mpv feature request issue/ticket then, mpv.net supports it because somebody had requested it.

[tanvir175]

This comment was like 2 years ago so I'm not going to unnecessarily ping the user who wrote it but:

easy enough even the average Windows user would figure it out pretty quickly

LMAO, idk how anyone could say/type/think this with a straight face.

[emanuelserpa]

https://github.com/cmdrkotori/mpc-qt-origin can be a good start but it's a one man(or girl, or wtv) show.

[Aurareus]

I also think MPC-QT is by far the best existing option for an "official" mpv frontend.
Aside from VLC I think MPC is probably the most widely recognized media player software out there.

I do understand where people are coming from in saying that mpv doesn't need a GUI, that it's usability is as good or better than what a GUI would provide, but that's missing the point that for the average end-user any application without a GUI is extremely unintuitive to use.
The average end-user doesn't even have a conception of the separation between the underlying software and the GUI, every application they ever use has a GUI.

[ghost]

Why do you think we want to enable the "average end-user" to use mpv? It's better if they fuck off.

I'm considering adding some kind of OSD menu though, because at some point having too many key bindings becomes inconvenient. I only need to make a PoC, but I guess nothing is happening.

[bitsper2nd]

I use this script.

[barolo]

@bitsper2nd That script is pretty freakin amazing. Exactly what I wanted

For bomi fans, there's upcoming qt/mauikit player called cinema which uses mpv

[soredake]

https://github.com/g-fb/haruna/