Announcement

Collapse
No announcement yet.

MPV Player 0.32 Released With RAR5 Support, Bash Completion

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

  • #41
    Originally posted by intelfx View Post
    Says someone who got banned from there for obnoxious trolling and generally being an asshole.
    to fractal and his cronie of a mod? (or vice versa) that's a must for a good mannered gentleman!
    Originally posted by intelfx View Post
    Go away.
    nah.
    you could try and grass me to that albatross fella... who knows.. ahaha

    по теме есть чего-нибудь?

    Comment


    • #42
      Originally posted by ssokolow View Post
      Except that the things which expect SSD tend to be things like SDL-based games, where it makes all the sense in the world to ask the platform APIs to take care of it for you,it was probably lucky that you got a Linux port to begin with, and it's likely it doesn't get supported very well.
      No. SSD doesn't fix any problem, it just creates them. Drawing windows decorations is just one another simple task, which can be done by any app itself or by delegation to some library of developer's choice. In CSD-only world app, toolkit, or library can just draw several primitives and fire some messages to wayland server when getting some mouse events within certain areas. Wayland window header is just a rectangle which issues 'start move window' command when getting mousedown event. I don't believe in 1-click linux ports, so adding CSD support will be least problem for developer, even without any support library.
      With optional SSD all becomes times harder: developer may ignore SSD and will have answer to 'your prog doesn't conform my fancy KDE theme, fix immediately' requests, or may support two code paths to make everybody happy. With SSD DE's developers will add tons of unnecessary features to their decorations and there will be always problems with these features don't work with CSD apps, so user will bombard apps support asking to make CSD optional and developers will have to support two different layouts and users will have to choose if they will loose DE's functionality or application's

      With their SSD extension, KDE developers have created a big problem for every developer and all is just to save their f***ng theming feature!

      And when everything is done perfectly, SSD will still look like shit, because app uses dark color theme and colors for SSD were selected to look good with lite theme.

      ...and, last I checked, the SDL approach was basically "If GNOME persists with not supporting SSD requests, maybe we can draw the bare minimum that can be called window decorations and consider it done."
      And this is the correct answer. Everyone should do the same and deprecate SSD.

      Comment


      • #43
        You're making a lot of assumptions there.

        Originally posted by Khrundel View Post
        No. SSD doesn't fix any problem, it just creates them. Drawing windows decorations is just one another simple task, which can be done by any app itself or by delegation to some library of developer's choice. In CSD-only world app, toolkit, or library can just draw several primitives and fire some messages to wayland server when getting some mouse events within certain areas. Wayland window header is just a rectangle which issues 'start move window' command when getting mousedown event. I don't believe in 1-click linux ports, so adding CSD support will be least problem for developer, even without any support library.
        Ahh, so you ascribe to the GNOME developers' delusion then? That users agree with their ideological "If game developers aren't willing to come on our terms, then screw those games"? I certainly don't.

        That said, do you really think it'll make GNOME look good if it's the only desktop where games get a fugly "black rectangle with some colored squares"-type titlebar provided by SDL as "There. We've met requirements. Now shut up about it."?

        Originally posted by Khrundel View Post
        With optional SSD all becomes times harder: developer may ignore SSD and will have answer to 'your prog doesn't conform my fancy KDE theme, fix immediately' requests, or may support two code paths to make everybody happy.
        What do you think happens to CSDs drawn by non-GTK applications on GNOME right now?

        Originally posted by Khrundel View Post
        With SSD DE's developers will add tons of unnecessary features to their decorations and there will be always problems with these features don't work with CSD apps, so user will bombard apps support asking to make CSD optional and developers will have to support two different layouts and users will have to choose if they will loose DE's functionality or application's
        Yes, and this didn't used to be a problem until GNOME broke from the conventions agreed upon by every other DE, so it's GNOME that has to deal with the fallout.

        Who is supposed to be the arbiter of whether a feature is "unnecessary". You? Until Windows 10, GNOME 3 and Microsoft disagreed pretty fundamentally over whether having multiple workspaces (ie. virtual desktops) was an "unnecessary" feature. Are you arrogant enough to believe that GNOME gets to rule by fiat on what direction all Linux desktops will go?

        Originally posted by Khrundel View Post
        With their SSD extension, KDE developers have created a big problem for every developer and all is just to save their f***ng theming feature!
        Screw theming. I want my f***ing customizable titlebar button loadout, enhanced titlebar context menu, and no stupid widgets crowding out the title.

        I've heard rumours that some WMs even support *gasp* grouping arbitrary windows into a single window with WM-level tabs in the titlebar. Horror of horrors!

        Thank God for Alt+F3 to pull up the KWin context menu for the active window via the keyboard.

        (But, while you're on the topic of theming, it's bad enough when I have to reconfigure the theme because some idiot theme designer made it hard to identify the active window at a glance because they made only the text colour on the titlebar change between active and inactive to keep it "harmonized" with the widget theme.)

        Originally posted by Khrundel View Post
        And when everything is done perfectly, SSD will still look like shit, because app uses dark color theme and colors for SSD were selected to look good with lite theme.
        Then fix it properly and standardize a means for a window to indicate to the WM whether it's using a dark-on-light or light-on-dark scheme. Don't just write a crappy "80% of the users use 20% of the features" hack and ignore the "but each user uses a different 20%" part by dismissing those users as "wrong".

        There's a reason that things like JWZ's The CADT Model get written.
        Last edited by ssokolow; 30 January 2020, 07:19 PM.

        Comment


        • #44
          Originally posted by ssokolow View Post
          Ahh, so you ascribe to the GNOME developers' delusion then? That users agree with their ideological "If game developers aren't willing to come on our terms, then screw those games"? I certainly don't.
          And with which other terms game developers can disagree? Can they disagree with OpenGL specification, for example? No? They should conform to specs? And if so, why game developer can assume DE supports SSD, when even xdg-decoration specs say it is optional?
          That said, do you really think it'll make GNOME look good if it's the only desktop where games get a fugly "black rectangle with some colored squares"-type titlebar provided by SDL as "There. We've met requirements. Now shut up about it."?
          If game has ugly sprites or buttons why this is game's problem but when it has ugly titlebar - that is DE's fault? That is an universal answer to every pro-SSD argument: "why it is ok to you to have application's own buttons but not own titlebar". That is up to game developers. Most games are fullscreen only. If developers want some custom interface (i.e. without toolkit) and windowed mode they should draw titlebar with their style themselves.
          What do you think happens to CSDs drawn by non-GTK applications on GNOME right now?
          Hmm.... I've mentioned a problem which will always belong to SSD world and you've confirmed that that problem exists now. And we are living in SSD world. So, I was right. What is your point?
          Yes, and this didn't used to be a problem until GNOME broke from the conventions agreed upon by every other DE, so it's GNOME that has to deal with the fallout.
          I like that argument. Just tell "everybody agree with me". KDE and sway aren't everybody. There are actually more wayland servers which don't support SSD. And if you will look to marketshare... I bet at least half of users use Gnome.
          Then fix it properly and standardize a means for a window to indicate to the WM whether it's using a dark-on-light or light-on-dark scheme. Don't just write a crappy "80% of the users use 20% of the features" hack and ignore the "but each user uses a different 20%" part by dismissing those users as "wrong".
          Yep, lets make crappy decision and then we will figure out how to cope with consequences. Now app developer have to had two UI layout (one for CSD and one for SSD) and have to support standardized themes or some protocol extension to tell WM about his apps color theme. That is what I've meant. SSD creates problems, doesn't fix any.

          Comment


          • #45
            Originally posted by Khrundel View Post
            And with which other terms game developers can disagree? Can they disagree with OpenGL specification, for example? No? They should conform to specs? And if so, why game developer can assume DE supports SSD, when even xdg-decoration specs say it is optional?
            1. "What GNOME wants" isn't a standard
            2. Under Wayland, things like having support for multiple windows on the same display device are optional. It's designed to not treat things like In-Vehicle Infotainment consoles as second-class citizens the way X11 does.

            Originally posted by Khrundel View Post
            If game has ugly sprites or buttons why this is game's problem but when it has ugly titlebar - that is DE's fault?
            It's the DE's fault if it expects applications to draw CSD the way they do on Windows or MacOS, without acknowledging that, as far as CSD is concerned, Windows and MacOS APIs are equivalent to making Wayland APIs inaccessible, unstable, and internal, forcing all Wayland environments to guarantee availability of GTK+, and requiring all applications, Qt or otherwise, to go through GTK+ to request a drawable surface.

            Originally posted by Khrundel View Post
            That is an universal answer to every pro-SSD argument: "why it is ok to you to have application's own buttons but not own titlebar". That is up to game developers. Most games are fullscreen only. If developers want some custom interface (i.e. without toolkit) and windowed mode they should draw titlebar with their style themselves.
            Except that, on Windows and MacOS, they don't have to. There's an API that they can trust to always be there which will render OS-provided CSD for them. As I've said before, come back with this argument after libdecoration is sufficiently mature.

            Originally posted by Khrundel View Post
            Hmm.... I've mentioned a problem which will always belong to SSD world and you've confirmed that that problem exists now. And we are living in SSD world. So, I was right. What is your point?
            Which problem? The pressing need for titlebars to blend in with the windows they wrap? Thanks, but it's bad enough that Firefox implemented the CSS rules that allow sites to apply their own garish colours to the scrollbar.

            Are you next going to argue that Plasma should be pressured into implementing some kind of API that allows the taskbar to be restyled to match whatever the active window is?

            There's a reason we have "common components" which are drawn by the desktop for consistency.

            Originally posted by Khrundel View Post
            I like that argument. Just tell "everybody agree with me". KDE and sway aren't everybody. There are actually more wayland servers which don't support SSD.
            That's not as solid an argument as you think, given that CSD has existed for much longer than the APIs to negotiate for SSD, that you're counting compositors that may be planning to implement SSD but haven't gotten around to it yet, that CSD is the default "do nothing" option, that it's also the standard design tiling WMs, X11 or otherwise, and that some compositors you didn't mention not only fall on the SSD side, but that the Arcan developer was so annoyed by the GNOME position that he blogged about how he'll go about implementing forced SSD if need be. (Involving cropping the surface the application draws to and providing a toggle-button in the SSD for when you need access to it.

            Originally posted by Khrundel View Post
            And if you will look to marketshare... I bet at least half of users use Gnome.
            1. "i bet" is not a very solid statement
            2. GNOME was first to something marginally usable. Of course they have a head start.
            3. If you're going by market share, we should all give up and go back to Windows.

            Originally posted by Khrundel View Post
            Yep, lets make crappy decision and then we will figure out how to cope with consequences. Now app developer have to had two UI layout (one for CSD and one for SSD)
            Are you listening to yourself? That's an argument that has been thrown at GNOME 3 ever since they went off on their wildly divergent take on how a desktop should look and act.

            Originally posted by Khrundel View Post
            and have to support standardized themes or some protocol extension to tell WM about his apps color theme.
            We already had this problem since the beginning. It's called "Qt and GTK don't use the same theming interface and don't even start about the lesser toolkits".

            Originally posted by Khrundel View Post
            That is what I've meant. CSD creates problems, doesn't fix any.
            FTFY

            Comment


            • #46
              Originally posted by ssokolow View Post
              "What GNOME wants" isn't a standard
              Wayland specs say xdg-decoration is optional.
              Under Wayland, things like having support for multiple windows on the same display device are optional. It's designed to not treat things like In-Vehicle Infotainment consoles as second-class citizens the way X11 does.
              Wayland specs don't say xdg-decoration support is required for multiple windows interface. So it is optional even on desktop.
              It's the DE's fault if it expects applications to draw CSD
              Just listen to yourself. This is nonsense.
              without acknowledging that, as far as CSD is concerned, Windows and MacOS APIs are equivalent to making Wayland APIs inaccessible, unstable, and internal, forcing all Wayland environments to guarantee availability of GTK+, and requiring all applications, Qt or otherwise, to go through GTK+ to request a drawable surface.
              Nobody requires GTK+ to draw CSD. GTK+ is just one possible solution. One of many,
              Except that, on Windows and MacOS, they don't have to. There's an API that they can trust to always be there which will render OS-provided CSD for them.
              Windows api has not only decorations, but all GUI primitives and even some standard dialogs. Wayland doesn't offer any GUI primitives, including titlebars and borders. That is called "consistency". And I don't see why linking with some toolkit is different from using system-embedded one.
              Which problem? The pressing need for titlebars to blend in with the windows they wrap?
              Problem is a stupid idea about same decorations for every window.
              Are you next going to argue that Plasma should be pressured into implementing some kind of API that allows the taskbar to be restyled to match whatever the active window is?
              No. This is a terrible idea, just like SSD itself. Plasma should just deprecate and then remove their crappy xdg-decoration support and then there will no problem at all, all CSD decorations will naturally blend with their windows. Isn't it simplest and perfect solution?
              There's a reason we have "common components" which are drawn by the desktop for consistency.
              Yes, and this reason is the X11 design which had windows manager which draws decorations. Same decorations for every windows wasn't a goal, it was side effect of X11 architecture. Now, with wayland, that reason is gone.
              Are you listening to yourself? That's an argument that has been thrown at GNOME 3 ever since they went off on their wildly divergent take on how a desktop should look and act.
              And that was wrong argument. Gnome 3 didn't force anyone to conform their vision. Not even builtin Gnome's apps were following their new guidelines from the start. SSD, contrary, creates a fuzzy borders between a window and DE, both sides don't know what to expect from other and have to do something with it.
              We already had this problem since the beginning. It's called "Qt and GTK don't use the same theming interface and don't even start about the lesser toolkits"
              And Gnome's answer to this is "this is not a problem at all, stop tilting wildmills, you don't need same theming interface and you'll never get one. Just relax". And now, when user 50%+ of time interacts with websites, each having their own theme, requiring other half to be "consistent" is insane.

              Look at the Steam interface. Or any other CSD app. Do you realy need these window to have a native titlebar? No. Then why you require all windows except these to have it?

              Comment


              • #47
                Originally posted by Khrundel View Post
                Wayland specs say xdg-decoration is optional.
                [...]
                Look at the Steam interface. Or any other CSD app. Do you realy need these window to have a native titlebar? No. Then why you require all windows except these to have it?
                I could continue arguing, but it's clear we're not achieving rational discourse, so we're going to have to agree to disagreee.

                I've got more productive things to do with my time.

                Comment


                • #48
                  Originally posted by ssokolow View Post

                  I could continue arguing, but it's clear we're not achieving rational discourse
                  I am 100% rational.
                  If it is pain to see for example 30% of windows having GTK style (including decorations) it is must be even more pain to see just one window having it's own unique style. So, if you're right, all skinnable apps and all apps with their own theme just shouldn't exist. Their appearance must antagonize most users. But we see other way, even enterprise apps like MS Office tend to replace standard controls with customized. So, logic tells me that nobody cares about native look and feel. That is why both GTK and QT developers don't care about negotiating some common theme format.

                  Same logic tells me that simplest way to achieve a solid window appearance is not to invent 15 protocols to tell external decorator about apps color theme, and then another one protocol to allow to add some controls to the titlebar, that will just add complexity. The simplest way is to make every window to draw it's decorations itself. Most apps won't have to do anything, they are using default toolkit theme and they will got default toolkit decorations. And CSD will fix a problem with theming inconsistency: If user will choose a GTK theme and some incompatible KDE theme and install some app with minor toolkit, which doesn't support theming, there won't be problems with frankenstein UI, all titlebars will looks like parts of their windows, with perfect contrast and solid styles.

                  I agree with you, it is good to have access to some additional features from DE, but it can be achieved with some simple protocol extension, like delegation of contextmenu event after rigthclicking on titlebar, you don't need DE's buttons on windows headers.

                  Unfortunately, nobody listens to the logic. KDE developers don't want to throw out their customization features, SDL and MPV developers don't want to do additional work and hope their whining will force adult responsible people to change their mind, users are afraid of changes.

                  What I don't understand is why these people want to spend time and efforts to transit to wayland if their goal is to reimplement X11? X11 already exist, just use it.

                  Comment

                  Working...
                  X