Announcement

Collapse
No announcement yet.

MPV Player 0.32 Released With RAR5 Support, Bash Completion

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • lu_tze
    replied
    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


    Leave a comment:


  • uid313
    replied
    But does it work with 7z and XZ compression?

    Leave a comment:


  • discordian
    replied
    Originally posted by Britoid View Post

    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.

    Leave a comment:


  • Britoid
    replied
    Originally posted by zxy_thf View Post
    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.

    Leave a comment:


  • zxy_thf
    replied
    Originally posted by cl333r View Post
    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.

    Leave a comment:


  • Britoid
    replied
    Originally posted by Gusar View Post
    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.

    Leave a comment:


  • Britoid
    replied
    Originally posted by brent View Post

    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.

    GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.


    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.

    Leave a comment:


  • Gusar
    replied
    Originally posted by Britoid View Post
    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.

    Originally posted by Chugworth View Post
    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.

    Leave a comment:


  • intelfx
    replied
    Originally posted by phoronix View Post
    MPV 0.32 also adds an explicit warning when running the player on GNOME's Wayland session due to "serious issues with their compositor."
    Originally posted by https://github.com/mpv-player/mpv/wiki/FAQ#is-gnome-actively-sabotaging-the-linux-desktop
    <...> Is GNOME actively sabotaging the Linux Desktop?
    Clearly they are <...>
    What a moron.

    But then again, you shouldn't expect much from a GitHub profile with no real name and an anime picture for an avatar. 4chan-style development, jfc.

    It's not developers' business to tell users what they should or what they should not run, or make political statements on that matter, lest we end up with another xscreensaver.
    Last edited by intelfx; 27 January 2020, 12:26 AM.

    Leave a comment:


  • DanL
    replied
    Originally posted by brent View Post
    ...So we've got major fragmentation now, which really hurts the Linux desktop.
    Does this mean I can't shake my GNOME pom-poms all over Phoronix? Bummer...

    Leave a comment:

Working...
X