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?

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

[ivanbalashov239]

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