Announcement

Collapse
No announcement yet.

MATE 1.26 Desktop Released With Some Wayland Support, Other Improvements

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

  • #31
    Originally posted by pgoetz View Post

    Because some people just want to get work done, don't care about eye candy, and want their desktop to consume a minimal amount of resources.
    I think that people who need to get work done also don't care about "minimal" resources. For them the value of MATE is that it's a classic UI where they naturally feel at home.

    Comment


    • #32
      Originally posted by Pajn View Post
      They are using Mir.
      You don't know what you're talking about. MATE has never used Mir. You're thinking of Unity.

      To answer jacob 's question: MATE uses it own compositor, derived from Metacity.

      Comment


      • #33
        Originally posted by jacob View Post
        I think that people who need to get work done also don't care about "minimal" resources. For them the value of MATE is that it's a classic UI where they naturally feel at home.
        Yeah, pretty much.

        That said, it's nice that I can *also* use it on the Pi, where pretty much every byte or cycle you can save matters, rather than have to use something different there just because my main PC's DE is wasting enormous amounts of CPU and RAM because the developers are clowns; and likewise for my VMs.
        i.e. MATE's "lightness" may rarely be a *reason* to use it (though it certainly matters if the HW is weak, like a 10-year-old laptop or something), but that lightness can be a very nice unexpected bonus once you *are* using it.

        Comment


        • #34
          Originally posted by arQon View Post

          Yeah, pretty much.

          That said, it's nice that I can *also* use it on the Pi, where pretty much every byte or cycle you can save matters, rather than have to use something different there just because my main PC's DE is wasting enormous amounts of CPU and RAM because the developers are clowns; and likewise for my VMs.
          i.e. MATE's "lightness" may rarely be a *reason* to use it (though it certainly matters if the HW is weak, like a 10-year-old laptop or something), but that lightness can be a very nice unexpected bonus once you *are* using it.
          I get what you're saying but still, I wonder how much does it really show up in reality. GNOME's slowness relates first and foremost to its (initially) horribly inefficient rendering, but 1) that is getting much better now with each release and 2) besides, since MATE is using Mutter as another poster said, wouldn't it suffer from the same problems (and receive the same improvements)?

          Another performance problem with GNOME is of course the use of JavaScript, but the GJS interpreter is really not that bad actually (not as good as Google's V8 but better than many commonly used scripting languages). If there are some serious performance problems on the Pi, maybe the real issue is that GJS should be better optimised for the ARMv7/Aarch64?

          Then there are stupid architectural decisions within GNOME, like when Gnome Shell used to do IO within the main UI thread. Some of those have been or are being addressed and some can't be changed and we are stuck with them for the foreseeable future, maybe that's one point where MATE has a distinct advantage then.

          Comment


          • #35
            Originally posted by arQon View Post

            You don't know what you're talking about. MATE has never used Mir. You're thinking of Unity.

            To answer jacob 's question: MATE uses it own compositor, derived from Metacity.
            You do not know what you are talking about. Mate uses Mir for wayland https://www.phoronix.com/scan.php?pa...land-Mir-Video Metacity is an X11 compositor.

            Comment


            • #36
              Originally posted by Pajn View Post
              Mate uses Mir for wayland
              "for wayland" is the piece you missed out in your original comment. You might have thought it was implicit given the context, but I didn't. Thanks for clearing that up.

              Using Mir as a shim for Wayland (which I now can't stop thinking of as "Fail Land", so thanks for the brainworm, whoever started it that) makes sense, I guess. Marco (Metacity) remains the compositor for the working/current version of MATE though, which is what I read the original question as. Regardless, he has both answers now at least.

              Comment


              • #37
                Originally posted by jacob View Post
                I wonder how much does it really show up in reality.
                "Enough", apparently, judging by anecdotal comments in the Pi forums etc: pretty much everyone complains about GNOME being "slow", pretty much no-one makes the same complaint about MATE (or LXDE).

                > GNOME's slowness relates first and foremost to its

                "... developers not caring about performance at all, for years on end".
                The fact that Van Vugt is improving that - despite strenuous resistance from the GNOME devs, you'll recall - doesn't fix the underlying systemic problem. There are a lot of pieces involved: Shell, GTK, compositor, etc, and GNOME has had ample time to make a mess of all of them. If your car has 4 flat tyres, replacing one of them still leaves you with a car that doesn't drive well, regardless of how much more air *one* of them has.

                > Another performance problem with GNOME is of course the use of JavaScript, but the GJS interpreter is really not that bad actually (not as good as Google's V8 but better than many commonly used scripting languages). If there are some serious performance problems on the Pi, maybe the real issue is that GJS should be better optimised for the ARMv7/Aarch64?

                I try to ignore GNOME as much as possible, but my understanding is that the current claim at least is that the JS is only a minor issue. How much you believe GNOME's PR is up to you.

                > Then there are stupid architectural decisions within GNOME, like when Gnome Shell used to do IO within the main UI thread.

                Which takes us back to those earlier points: that GNOME devs don't care about performance, and that there are multiple pieces involved. Stupidity in GNOME Shell has no impact on MATE regardless of the components that are shared, ergo it does indeed make sense that GNOME can be (and is) a significantly worse experience despite the common ancestry. A high-end PC may be able hide most of GNOME's problems through sheer horsepower, but the much weaker Pi will only highlight them even more.

                You could also argue that GNOME's focus is Wayland, which is still "immature". For all I know there are valid reasons to do things in a way that yields better performance there at the expense of worse performance under X. Since Wayland was supposed to be ready 5-10 years ago, it would be perfectly reasonable for GNOME to have made such tradeoffs. I'm not stupid enough to *believe* that, but it's an argument that could be made.

                Comment


                • #38
                  Originally posted by arQon View Post

                  "Enough", apparently, judging by anecdotal comments in the Pi forums etc: pretty much everyone complains about GNOME being "slow", pretty much no-one makes the same complaint about MATE (or LXDE).

                  > GNOME's slowness relates first and foremost to its

                  "... developers not caring about performance at all, for years on end".
                  The fact that Van Vugt is improving that - despite strenuous resistance from the GNOME devs, you'll recall - doesn't fix the underlying systemic problem. There are a lot of pieces involved: Shell, GTK, compositor, etc, and GNOME has had ample time to make a mess of all of them. If your car has 4 flat tyres, replacing one of them still leaves you with a car that doesn't drive well, regardless of how much more air *one* of them has.

                  > Another performance problem with GNOME is of course the use of JavaScript, but the GJS interpreter is really not that bad actually (not as good as Google's V8 but better than many commonly used scripting languages). If there are some serious performance problems on the Pi, maybe the real issue is that GJS should be better optimised for the ARMv7/Aarch64?

                  I try to ignore GNOME as much as possible, but my understanding is that the current claim at least is that the JS is only a minor issue. How much you believe GNOME's PR is up to you.

                  > Then there are stupid architectural decisions within GNOME, like when Gnome Shell used to do IO within the main UI thread.

                  Which takes us back to those earlier points: that GNOME devs don't care about performance, and that there are multiple pieces involved. Stupidity in GNOME Shell has no impact on MATE regardless of the components that are shared, ergo it does indeed make sense that GNOME can be (and is) a significantly worse experience despite the common ancestry. A high-end PC may be able hide most of GNOME's problems through sheer horsepower, but the much weaker Pi will only highlight them even more.

                  You could also argue that GNOME's focus is Wayland, which is still "immature". For all I know there are valid reasons to do things in a way that yields better performance there at the expense of worse performance under X. Since Wayland was supposed to be ready 5-10 years ago, it would be perfectly reasonable for GNOME to have made such tradeoffs. I'm not stupid enough to *believe* that, but it's an argument that could be made.
                  Ok troll. I thought for a moment we were having a serious discussion.

                  Comment


                  • #39
                    Originally posted by jacob View Post
                    Ok troll. I thought for a moment we were having a serious discussion.
                    Wow - that raced to the gutter all of a sudden...

                    What part did you think wasn't serious? Because at a minimum, all the technical aspects are obviously true (except the JS part which as I said is taken on faith), and the opinion parts (except the final paragraph, which I admit is tongue-in-cheek even if theoretically possible), while certainly opinion, are aligned with all available evidence and contradicted by none of it. Whatever it is that triggered this sudden sulk is on you, not anything I wrote.

                    Comment

                    Working...
                    X