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?

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

[sibwaf]

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.

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

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

[ghost]

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.