Announcement

Collapse
No announcement yet.

KDE Readies More Changes For Next Month's Plasma 6.1

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

  • #11
    Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post

    This is exactly why even some long-term GNOME users are getting fed up and leaving. This just keeps happening over and over and over again.

    Somone has a simple idea to increase interoperabilty...

    KDE dev: This will be great for our users.
    Budgie dev: Hell yeah, let's do this!
    Pop!_OS dev: Great idea!

    GNOME dev: Fuck you.
    I would say I'm such user. I'm really getting fed up with the toxic behavior of some of their devs and their refusal to cooperate with the rest of the Linux ecosystem which hurts the standardization across the different DEs. However, that doesn't mean I currently want to ditch Gnome because I still like it for many reasons (not gonna get into that).

    Since we're talking about icon theming, I recently stumbled upon this gitlab issue. Apparently they now want to remove icon theming support in GTK 5. The way the GTK developer started the description really infuriated me: "Icon themes are no longer a thing". Really? Who said that? Since when "Icon themes are no longer a thing" became a consensus in the Linux desktop space? It seems like you just made up this claim and posted it as undeniable truth for you own comfort.
    Of course they might just end up changing the way icon themes are loaded in GTK 5. After all, if the icon format in GTK 5 is still going to be SVG or PNG images (or even a sheet that contains multiple icons) that are external to the app, there's no reason that it wouldn't be possible to change them just like it's possible to theme Libadwaita apps after all. But I also wouldn't be surprised if they'll end up just hardcoding the icons in GTK 5 so that it wouldn't be possible to change them.
    Last edited by user1; 04 May 2024, 12:05 PM.

    Comment


    • #12
      Originally posted by pWe00Iri3e7Z9lHOX2Qx View Post

      This is exactly why even some long-term GNOME users are getting fed up and leaving. This just keeps happening over and over and over again.

      Somone has a simple idea to increase interoperabilty...
      ​​​​​​​
      KDE dev: This will be great for our users.
      Budgie dev: Hell yeah, let's do this!
      Pop!_OS dev: Great idea!

      GNOME dev: Fuck you.
      I don't get that impression at all from reading the thread. It seems like the Gnome developers are interested in solutions that work for everyone, but are simply no longer interested in the goal of the FDO icon spec. Personally, I can understand their reasoning. There are more important things to put resources towards than interchangeable icon sets.

      Comment


      • #13
        Originally posted by user1 View Post

        I would say I'm such user. I'm really getting fed up with the toxic behavior of some of their devs and their refusal to cooperate with the rest of the Linux ecosystem which hurts the standardization across the different DEs. However, that doesn't mean I currently want to ditch Gnome because I still like it for many reasons (not gonna get into that).
        Standards exist for the purpose of uniting implementations around a common goal so that they can be interoperable. Standards are not meant to chain you to to the goal if you no longer believe in it. You always need the option of ditching the standard when it no longer serves your purpose. That's what I like about Gnome. They are ruthlessly pragmatic. If they simply accepted the Windows 98 or Gnome 2 desktop metaphor as the standard way of presenting the desktop, we would never have Gnome 3, which is my favorite desktop environment.

        Comment


        • #14
          ngraham
          Can we please get the trash icon disappearing off the desktop when you send something to it or empty it bug fixed please.

          Comment


          • #15
            Originally posted by krzyzowiec View Post
            If they simply accepted the Windows 98 or Gnome 2 desktop metaphor as the standard way of presenting the desktop, we would never have Gnome 3, which is my favorite desktop environment.
            But that's the thing, it seems like everything that everyone else agrees on but Gnome doesn't, is actually not something that fundamentally breaks their paradigm or their desktop vision. As an example let's take Wayland protocols. DRM Leasing is a VR protocol everyone agreed on, but Gnome didn't. As a result, VR on Gnome Wayland is not an option. And they didn't even give a clear technical explanation to why they don't want to support DRM Leasing.

            Comment


            • #16
              Originally posted by user1 View Post

              But that's the thing, it seems like everything that everyone else agrees on but Gnome doesn't, is actually not something that fundamentally breaks their paradigm or their desktop vision. As an example let's take Wayland protocols. DRM Leasing is a VR protocol everyone agreed on, but Gnome didn't. As a result, VR on Gnome Wayland is not an option. And they didn't even give a clear technical explanation to why they don't want to support DRM Leasing.
              Let me explain it with science. When a Red Hat is worn too long the excessive heat build up from constantly wearing a hat can bake brains. Brain issues are compounded when the dyes in the hats run off leading to their skin becoming orange. Orange tinted skin blocks the UV spectrum so they quit absorbing vitamin D when they're in sunlight which leads to even more mental fatigue, depression, and exhaustion.

              Then they buy a new hat and the viscous cycle continues. It's a vicious cycle.

              Comment


              • #17
                Originally posted by user1 View Post

                But that's the thing, it seems like everything that everyone else agrees on but Gnome doesn't, is actually not something that fundamentally breaks their paradigm or their desktop vision. As an example let's take Wayland protocols. DRM Leasing is a VR protocol everyone agreed on, but Gnome didn't. As a result, VR on Gnome Wayland is not an option. And they didn't even give a clear technical explanation to why they don't want to support DRM Leasing.
                That's not true. They do give a clear reason for their preference for a portal instead.

                Originally posted by Jonas Ådahl​
                The better reason for making it a portal is that portals are the components in the system that act as the "firewall" between sandboxed applications and both privacy sensitive content (files, screen content, ..) as well as "special" hardware (camera, eventually USB and serial devices, cryptographic devices ...), and it makes perfect sense to make it handle VR headsets as well (and gamepads etc too IMO, but that's another story). Portals can integrate with the permission store, which is used for these kind of things. It is a design choice in flatpak/portal land to not try to rely on compositors directly for handling these kind of things. Often portal backends need to integrate with the windowing display server and/or the DRM master, but those are implementation details.

                Mutter also approved the protocol, so what has changed?

                It's still "acked", but people are expressing their opinions. I agree that portal would IMO definitely be a better place to do this from a system architectural point of view, but a Wayland protocol isn't "too bad" in this particular case, (same with inputfd, IMO), so personally I'm fine with it getting in implementation. That's why I also started with one.

                so it seems harmless to expose it right now

                No it is not. By exposing it to Wayland clients in general, we're making a promise to keep it exposed "forever". It'll make it practically impossible to eventually migrate to a portal, because the incentive for applications to migrate are practically zero. Wayland is generally a poor choice of API for anything where one one day might want to handle things outside of the display server, or for things that are not strictly tied to a particular windowing system, which is practically most API that doesn't involve windows. By doing leasing in Wayland, we'll be stuck with it forever, since the API itself more or less encodes where exactly it must be implemented.
                So it's not as simple as you are making it seem. If they agree to expose the protocol, they are forfeiting any ability to implement it using a portal, in order to preserve compatibility. This is actually a case of them taking a conservative approach and weighing their options before committing to anything, as opposed to rushing ahead. Which is ironic, since that's what a lot of people complain that Gnome keeps doing.

                Comment


                • #18
                  Originally posted by skeevy420 View Post

                  Let me explain it with science. When a Red Hat is worn too long the excessive heat build up from constantly wearing a hat can bake brains. Brain issues are compounded when the dyes in the hats run off leading to their skin becoming orange. Orange tinted skin blocks the UV spectrum so they quit absorbing vitamin D when they're in sunlight which leads to even more mental fatigue, depression, and exhaustion.

                  Then they buy a new hat and the viscous cycle continues. It's a vicious cycle.
                  At least red hats are somewhat better than black hats because black color absorbs the most heat. I assume that's the reason black hats aren't even worn nearly as often. Since wearing them turns the above of your head into literal oven, it immediately becomes unpleasant to wear them. That's why this vicious cycle doesn't exist with black hats.

                  Comment


                  • #19
                    Originally posted by krzyzowiec View Post

                    That's not true. They do give a clear reason for their preference for a portal instead.



                    So it's not as simple as you are making it seem. If they agree to expose the protocol, they are forfeiting any ability to implement it using a portal, in order to preserve compatibility. This is actually a case of them taking a conservative approach and weighing their options before committing to anything, as opposed to rushing ahead. Which is ironic, since that's what a lot of people complain that Gnome keeps doing.
                    Actually yeah, I remember that. I was thinking about totally different issue and confused it with this one.
                    But here I'd say that even if using a portal is the superior solution, DRM Leasing is already something that Valve officially supports and pretty much every other major Wayland DE's / compositors support. So given these circumstances, how can we be sure that Valve will also agree to support a different Wayland VR solution just because one DE didn't want to support DRM Leasing? I mean for now we can't know what will happen in the future, but at least I think it's possible that Valve will simply not care and continue to support DRM Leasing.

                    Btw, the same developer said this just 2 weeks ago:

                    We have discussed this among the maintainers, and would like to make it clear that a Wayland protocol implementation has never been blocked, and this is still the current state.

                    We appreciate that there are probably sounder approaches, but given how the ecosystem now looks right now, supporting DRM leasing in GNOME using a Wayland protocol right now we believe is the most pragmatic thing to do. This of course does not leave out exploring alternatives, as they shape up.
                    Last edited by user1; 04 May 2024, 01:25 PM.

                    Comment


                    • #20
                      Originally posted by krzyzowiec View Post
                      You always need the option of ditching the standard when it no longer serves your purpose.
                      In this particular case one of the issues is that this wasn't communicated clearly enough.

                      So some distributions (e.g. Fedora) mistakingly installed adwaita-icon-theme as the default without realizing that it was missing several of the important standard files.

                      Which then led to issues for all programs which tried to load these icons from the system's standard icon theme.



                      Comment

                      Working...
                      X