Announcement

Collapse
No announcement yet.

MPV Player 0.32 Released With RAR5 Support, Bash Completion

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

  • #21
    Originally posted by lu_tze View Post

    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.
    Well, another benefit of using something like GTK or Qt to create your window and interface with the OS rather than trying to talk directly to the display server is that you'll inherit any advancements made in the toolkit.

    Apple wants to change how HiDPI works? They can make that adjustment in Application Kit, and since you need to use AppKit to create a window on macOS (the display server api is private), everything follows.
    Last edited by Britoid; 01-27-2020, 08:44 AM.

    Comment


    • #22
      Originally posted by Britoid View Post

      Well, another benefit of using something like GTK or Qt to create your window and interface with the OS rather than trying to talk directly to the display server is that you'll inherit any advancements made in the toolkit.

      Apple wants to change how HiDPI works? They can make that adjustment in Application Kit, and since you need to use AppKit to create a window on macOS (the display server api is private), everything follows.
      Exactly. Meanwhile, in the Linux world, we are wasting time trying to make 20 years old programs running on hidpi diplays. Only because they can talk directly to X11. Or, more generally, because apps talk directly to the wrong layers in the stack, only because they can. That temporary effectivity is biting in the form of long term support. (Here, the Linux frameworks are at fault too... they were breaking ABIs too often in the past).

      Comment


      • #23
        It isn't just philosophical or integration issues. Also referenced with regards to that warning was this:

        https://gitlab.gnome.org/GNOME/mutter/issues/957

        Stutter caused by mistimed and delayed frames that only occurs on Gnome Wayland. That by itself makes it a worse watching experience than using X, and people will complain to the MPV devs about it when it's a Gnome-specific problem.

        Comment


        • #24
          Originally posted by BwackNinja View Post
          It isn't just philosophical or integration issues. Also referenced with regards to that warning was this:

          https://gitlab.gnome.org/GNOME/mutter/issues/957

          Stutter caused by mistimed and delayed frames that only occurs on Gnome Wayland. That by itself makes it a worse watching experience than using X, and people will complain to the MPV devs about it when it's a Gnome-specific problem.
          if that was what was complained about, rather than the whole paragraph about how GNOME Is trying to hurt the Linux desktop, that would be cool. It's a well known fact that GNOME on Wayland has problems with it's internal clock.

          Comment


          • #25
            Originally posted by Gusar View Post
            But there are people still getting their content in this format and they want to play it without unpacking it.
            Because, at least for older formats, RARs can be treated like redneck Matroska files by containing multiple subtitles, audio tracks, and other things we take for granted with modern formats.

            Comment


            • #26
              Originally posted by Britoid View Post

              if that was what was complained about, rather than the whole paragraph about how GNOME Is trying to hurt the Linux desktop, that would be cool. It's a well known fact that GNOME on Wayland has problems with it's internal clock.
              It's both. I think it's valid for a staunchly desktop-agnostic application to be upset that one environment refuses to implement the same protocols that every other one of note has agreed upon. And that's made worse because they instead insist on other protocols that are not only specific to Gnome, but also require additional dependencies to work at all.

              If a platform is hostile to the idea of applications being desktop-agnostic, that's their prerogative. However, that doesn't mean that projects like mpv are in the wrong for only trying to be a good application rather than trying to be a good Gnome application.

              It also makes sense for them to be desktop-agnostic, and not just because they want to work on more than Gnome. They want the control to be able to display video as well as possible, and that includes avoiding as much of the stack that can get in the way as possible. They aren't the only ones. The fastest and most feature-complete terminals aren't libvte-based, they use no toolkit. urxvt and alacritty are the the big players there. On the other end of the spectrum, st has its popularity for being so lightweight. If you spend all of your time only listening to "best" or "suggested" practices, you'll miss the opportunity to learn for yourself how everything works and assert that things can be done better. While you may desire more out of an application, it's largely accepted that mpv is the best at its primary objective -- playing videos.

              Comment


              • #27
                Originally posted by BwackNinja View Post

                It's both. I think it's valid for a staunchly desktop-agnostic application to be upset that one environment refuses to implement the same protocols that every other one of note has agreed upon. And that's made worse because they instead insist on other protocols that are not only specific to Gnome, but also require additional dependencies to work at all.

                If a platform is hostile to the idea of applications being desktop-agnostic, that's their prerogative. However, that doesn't mean that projects like mpv are in the wrong for only trying to be a good application rather than trying to be a good Gnome application.

                It also makes sense for them to be desktop-agnostic, and not just because they want to work on more than Gnome. They want the control to be able to display video as well as possible, and that includes avoiding as much of the stack that can get in the way as possible. They aren't the only ones. The fastest and most feature-complete terminals aren't libvte-based, they use no toolkit. urxvt and alacritty are the the big players there. On the other end of the spectrum, st has its popularity for being so lightweight. If you spend all of your time only listening to "best" or "suggested" practices, you'll miss the opportunity to learn for yourself how everything works and assert that things can be done better. While you may desire more out of an application, it's largely accepted that mpv is the best at its primary objective -- playing videos.
                Technically Alacritty is using NSWindow (part of AppKit, a toolkit) on macOS, this gives it the advantage that it can make windows that look like this.



                It does this while remaining "desktop agnostic". We're talking about using the platform toolkit to create a window, which is how it's done on other platforms (as someone else mentioned) and is what GNOME wants to use, how an application renders on top of that window is still completely up to the application, whether they want to use gtk widgets (like Nautilus) or render using its own system (like Firefox). Wayland you could potentially use something like a subsurface to draw directly on top of a GTK window and ignore the stack, I think this is what GNOME MPV tries to do.

                I believe the design of Mutter makes it hard for Mutter to start drawing on behalf of clients because of the way windows are handled, each "window" is just a dumb surface. Wayland it was already agreed that the compositor may not be able to draw decorations, and you have to agree to this to technically "speak Wayland". If you don't like that, don't implement Wayland.
                Last edited by Britoid; 01-27-2020, 10:03 AM.

                Comment


                • #28
                  Originally posted by Britoid View Post

                  Technically Alacritty is using NSWindow (part of AppKit, a toolkit) on macOS, this gives it the advantage that it can make windows that look like this.

                  It does this while remaining "desktop agnostic". We're talking about using the platform toolkit to create a window, which is how it's done on other platforms (as someone else mentioned) and is what GNOME wants to use, how an application renders on top of that window is still completely up to the application, whether they want to use gtk widgets (like Nautilus) or render using its own system (like Firefox). Wayland you could potentially use something like a subsurface to still draw directly on top of a GTK window and ignore the stack, I think this is what GNOME MPV tries to do.

                  I believe the design of Mutter makes it hard for Mutter to start drawing on behalf of clients because of the way surfaces are handled, each "window" is just a surface.
                  On MacOS, that's the base idea of a window. On Linux running X, the platform toolkit isn't GTK or Qt, it's xlib or xcb. On wayland, it's a (usually EGL) surface.

                  It's not invalid for Gnome MPV (now rebranded as Celluloid) to use GTK as the toolkit and have that kind of Gnome integration. It is unreasonable to have mpv do that itself, particularly because it has an api and is meant to be used like Celluloid uses it (another good example is IINA on MacOS) when greater integration with the desktop environment is desired. Again, mpv intends to be the best video player on the platforms it supports. Out of scope (and largely an orthogonal set of skills) is being the best video player application for that platform.

                  Edit:
                  And alacritty does that on MacOS because of the underlying toolkit that it uses, winit. That's special because they still suggest not using wayland support in winit for some of the same reasons that are mentioned on the mpv wiki.
                  Last edited by BwackNinja; 01-27-2020, 10:10 AM.

                  Comment


                  • #29
                    Originally posted by Britoid View Post
                    Interoperation does not make things the same platform.
                    It makes things more user friendly, more flexible and less of a mess for developers/vendors to target.

                    Comment


                    • #30
                      Originally posted by BwackNinja View Post

                      On MacOS, that's the base idea of a window. On Linux running X, the platform toolkit isn't GTK or Qt, it's xlib or xcb. On wayland, it's a (usually EGL) surface.

                      It's not invalid for Gnome MPV (now rebranded as Celluloid) to use GTK as the toolkit and have that kind of Gnome integration. It is unreasonable to have mpv do that itself, particularly because it has an api and is meant to be used like Celluloid uses it (another good example is IINA on MacOS) when greater integration with the desktop environment is desired. Again, mpv intends to be the best video player on the platforms it supports. Out of scope (and largely an orthogonal set of skills) is being the best video player application for that platform.

                      Edit:
                      And alacritty does that on MacOS because of the underlying toolkit that it uses, winit. That's special because they still suggest not using wayland support in winit for some of the same reasons that are mentioned on the mpv wiki.
                      Right. I don't think it would be unreasonable for mpv to have some sort of basic GTK window creation, akin to what it does on macOS, although whether someone actually wants to do that work and link to all of GTK is a valid discussion. I think an idea was some sort of libdecoration library for clients to draw decoration with (that would use xdg-decoration if available) to be available for clients that don't want to use a toolkit for window creation.

                      One of the reasoning behind Wayland was that a lot has moved from the display server to the toolkit. Mutter and Weston were both made with this in mind. I also think it's possible to have these kinds of discussions without pulling the "GNOME IS EVIL HURR DURR" line. You have two different viewpoints, and neither is particularly wrong or right.

                      Comment

                      Working...
                      X