MPV Player 0.32 Released With RAR5 Support, Bash Completion

[Gusar]

KDE is also a seperate platform. It has it's own design language, own toolkit, own ecosystem, own way of doing things.

And yet, KDE and wlroots can interoperate, because they implement the protocols both parties have agreed upon. Like xdg-decoration.

And despite KDE, Gnome, other DEs and smaller monkey-patched environments being "separate platforms", they interoperate in the X world because of well defined underlying protocols like EWMH.

It's only Gnome on Wayland that is the outlier.

The support for RAR compression strikes me as a little odd. I thought most videos were already highly compressed. Would you really gain much further compression by sticking them into RAR files? That would limit what applications you can play them back with without decompressing them.

The thing with video in RAR isn't to compress the content, it's purely about delivery. In the olden days, multi-volume RAR is how content was delivered due to practical reasons, like slow internet connections or use of platforms like usenet groups or ftp servers. Splitting up the content made sense then, each part is checksummed and you didn't need to get all parts at once. Why multi-volume RAR is still used today when there's much better delivery mechanisms like bittorrent (where each chuck is checksummed by design) and internet connections are much faster, I have no idea. But there are people still getting their content in this format and they want to play it without unpacking it.

[Britoid]

The problem is that someone needs to decide what protocols and APIs should be implemented and used. The Wayland standardization project (wayland-protocols) has decided that xdg-decoration is a standard protocol. So compositors *should* implement it. Basically, everyone accepted that, *except* GNOME. FWIW, there are also valid technical reasons why xdg-decoration is needed.

So we've got major fragmentation now, which really hurts the Linux desktop.

Bull-shit.

It's entirely possible to implement the xdg-decoration and inform clients that they should always use client-side decoration, although that would be pointless because that's the implicit behaviour for not implementing it.

https://github.com/wayland-project/wayland-protocols/blob/master/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml

If compositor and client do not negotiate the use of a server-side

decoration using this protocol, clients continue to self-decorate as they

see fit.

FYI Weston, the reference compositor, does not implement it either. The Linux desktop is not hurting over this decision, if applications do not want to speak Wayland properly, XWayland is probably going to be here for the next couple of decades.

[Britoid]

And yet, KDE and wlroots can interoperate, because they implement the protocols both parties have agreed upon. Like xdg-decoration.

And despite KDE, Gnome, other DEs and smaller monkey-patched environments being "separate platforms", they interoperate in the X world because of well defined underlying protocols like EWMH.

It's only Gnome on Wayland that is the outlier.


The thing with video in RAR isn't to compress the content, it's purely about delivery. In the olden days, multi-volume RAR is how content was delivered due to practical reasons, like slow internet connections or use of platforms like usenet groups or ftp servers. Splitting up the content made sense then, each part is checksummed and you didn't need to get all parts at once. Why multi-volume RAR is still used today when there's much better delivery mechanisms like bittorrent (where each chuck is checksummed by design) and internet connections are much faster, I have no idea. But there are people still getting their content in this format and they want to play it without unpacking it.

Interoperation does not make things the same platform.

[zxy_thf]

Edit: A few interesting quotes from the link above:

These statements are more like "we mpv developers do not use Gnome at all, so you should be thankful if it works on Gnome".
Hmm, sounds exactly monopolistic attitude towards media player users to me.

[Britoid]

These statements are more like "we mpv developers do not use Gnome at all, so you should be thankful if it works on Gnome".
Hmm, sounds exactly monopolistic attitude towards media player users to me.

If you want to use mpv under GNOME, you're almost certainly going to be better off using Celluloid / GNOME MPV instead.

[discordian]

If you want to use mpv under GNOME, you're almost certainly going to be better off using Celluloid / GNOME MPV instead.

This.

I don't understand why a common-denominator version should be your first choice (unless that's the only option of course). It might make sense to either support UI-plugin from mpv or use a libmpv for the common code from an UI-client.

[uid313]

But does it work with 7z and XZ compression?

[lu_tze]

On the other hand, the methods they provide for integrating with GNOME are technically bad and unacceptable, such as depending on GTK and giving it control over your window just to render CSDs, or needing dbus for disabling the screensaver during playback.

Is GNOME's apparent behavior stupid or evil? You decide. The end result is that the "Linux Desktop" remains a dumb shit show. Writing software only for win32 or OSX is a much nicer experience, thus bad consequences for Linux.

Do these guys read after themselves, have reading comprehension problem, or what is the issue? This is prime example of how to undermine what I said a paragraph earlier.

Do they realize, that win32 and osx do exactly the thing they say Gnome is wrong doing? In win32, to create a window, you must link to user32.dll (bringing in the entire win32 widget machinery into your process), on macOS you must link to AppKit.framework (detto). But somehow, that's wrong in Linux.

So no, the problem with Linux on desktop are exactly the people who don't know what they are doing, but think that X11 is the pinnacle of desktop development and want to keep it forever. Folks like Gnome are dragging them kicking and screaming into present, but they still don't understand anything. Nothing has changed since this happened: https://www.youtube.com/watch?v=ZTdUmlGxVo0

[Britoid]

Do these guys read after themselves, have reading comprehension problem, or what is the issue? This is prime example of how to undermine what I said a paragraph earlier.

Do they realize, that win32 and osx do exactly the thing they say Gnome is wrong doing? In win32, to create a window, you must link to user32.dll (bringing in the entire win32 widget machinery into your process), on macOS you must link to AppKit.framework (detto). But somehow, that's wrong in Linux.

So no, the problem with Linux on desktop are exactly the people who don't know what they are doing, but think that X11 is the pinnacle of desktop development and want to keep it forever. Folks like Gnome are dragging them kicking and screaming into present, but they still don't understand anything. Nothing has changed since this happened: https://www.youtube.com/watch?v=ZTdUmlGxVo0

The one thing I will argue, in the other way, is that on Linux there is no "standard toolkit" like there is on Windows and macOS. That said, I'm not sure there's any Linux desktop distro that doesn't ship with GTK.

[lu_tze]

The one thing I will argue, in the other way, is that on Linux there is no "standard toolkit" like there is on Windows and macOS. That said, I'm not sure there's any Linux desktop distro that doesn't ship with GTK.

Yes, I agree, and this is both a strong and weak point.

Strong in that, that it allows competition and evolution of different approaches, let the best win (however, there will be always at least two: see Intel vs AMD, Nvidia vs AMD, Android vs iOS, Chrome vs Firefox... the threat of the second one keeps the first one on the toes and won't let them fall behind. So GTK vs Qt is perfectly fine).

Weak in that, that it is one of the few technical problems that the competition is successfully using against Linux. On other platforms, you have SDKs that target specific OS releases (let's say Windows 7 SP1 or macOS 10.14). That allows ISVs to target supported platforms. On the Linux side, they must pick a distribution/version, which shrinks the potential reach even more (let's say Ubuntu 16.04/18.04 as GoG is doing, or Centos7 as BlackMagic Design is doing).

But the good news is, that flatpak runtimes also allow for exactly this approach. I expect there will be a lot of resistance, because it will be something different. Communicating via sockets with system daemons (be it display server, audio server, ipc bus, whatever) should be done by "standardized" libraries (shipped by the likes of flatpak runtimes), applications like mpv have no business doing it directly - if they want to be compatible with more than just a specific distro release. If you want to try something better, build an alternative flatpak runtime and you will see, whether it is worth something if/when it gets adopted and trusted by third parties.

No, mainstream users are not going to build from source - you can see that in Windows and macOS. That option should be there for those interested, not as a mandatory to make stuff work.