Announcement

Collapse
No announcement yet.

MATE Developers Are Considering Mir-Over-Wayland

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

  • #31
    Originally posted by TheOne View Post
    It is funny, because Wayland is supposed to make everything easier
    Where did you get that idea? Wayland is supposed to make for better infrastructure and user experience, but they certainly don't claim that writing your own desktop will be *easier*.

    Comment


    • #32
      Pretty cool outside the box thinking, why use one when you can have both? But will it really work well?

      Comment


      • #33
        Originally posted by tigerroast View Post
        I read the title and and all I could think of whas, "Huh?!!?" In the end though, this kind of makes sense. MATE has no Wayland compositor.

        The whole point is to have someone else develop the compositor, so the only work to be done is have Mir work on MATE with little-to-no issues. Mutter is out of the window because MATE devs hate GNOME 3.
        Pantheon has no problems using libmutter. It does all the heavy lifting (incl. NVidia support) and allows a tiny team to write their own compositor. Using libmutter is no different than using GTK 3. Both are libraries by the Gnome project.

        Originally posted by bregma View Post
        Even if they broke down and used Mutter at the other end of the client-server socket because it already supports Wayland, they would need to do a whackload of customization to Mutter and the client libraries to get the same functionality already supported out of the box by Mir. The entire philosophy of clients doing their own decorations and window management that is at the heart of Gnome3 is functionality the opposite of what Gnome2 did.
        And by “supported out of the box by Mir” you mean missing Wayland support? I’m open to be proven wrong but 1.) porting Mir to Wayland, 2.) write Mir bugfixes, 3.) sign Canonical’s CLA to hand them over all that work for free, 4.) binding themselves to “GPLv3-only” for all eternity (not LGPL and no “or any later version” and Canonical doesn’t change that even after they killed software, see Upstart and Unity), and 5.) finally create a shipable product seems so much more work than just developing server-side decoration support for something based on libmutter. Heck, Gnome devs may even be open to accept that code. At least one Red Hat-employed developer would be interested in it.

        Originally posted by Luke View Post
        switched to Cinnamon because I could get everything into one panel.
        So exactly like Gnome with https://github.com/jderose9/dash-to-panel/ but fewer people working on it?

        Originally posted by BaronHK View Post
        KDE has issues. For example, their SDDM login manager […] KDE is rotting from the inside out.
        SDDM is not a KDE project. It doesn’t have anything to do with KDE. It’s a 3rd party display manager whose maintainer the developer of Liri, a totally different desktop environment that’s competing against KDE and Plasma.

        You can’t even troll right…

        Comment


        • #34
          Originally posted by Mystro256 View Post

          Assuming I'm not misinformed in how GJS works, I feel like gnome should have a AOT compilation for JS scripts. I don't exactly imagine the JS scripts changing often enough to justify using JIT every time, at least with the scripts provided by the distro, i.e. in /usr. Plus, the distros can bundle in AOT binaries into the gnome-shell packages. Less CPU use, less power use, likely faster start up: I see no disadvantage to this.
          Only thing is, that would still use more CPU and more time than precompiled binaries unless you could cache and keep the just-in-time compiled binaries. I saw an extreme version of this in late 2014 with Mintmenu/Matemenu (gtk 2 in those days) and a very large list of installed applications. Mintmenu/matemenu is a replacement menu for MATE with some nice feartures but it is written in Python (which is up to 20x slower than JS). If I ran this on the netbook with that long list of apps, compiling the menu would take over a minute at each session start, pegging that Intel Atom so it could do nothing else. After that the menu was quick and responsive. Caching that menu, and only recompiling if a program was added or removed would have fixed this without porting to another language.

          Comment


          • #35
            Originally posted by Awesomeness View Post
            <snip>So exactly like Gnome with https://github.com/jderose9/dash-to-panel/ but fewer people working on it?<snip>
            That didn't exist in that 2012/2013 period where I switched from GNOME 3 to Cinnamon. The Github history only goes back to an import from a previous address in Sep 2016, and I don't recall ever seeing this back in the day.

            The way I ended up hacking on MATE was simple: in fall 2014 I ran a mix of MATE (gtk2 version) and cairo-dock and was not satisified with either. Whether MATE got GTK3 working or cairo-dock gained a true window list (with the named buttons) first would decide which way I went, and MATE was ready first and with better applets.

            Comment


            • #36
              As for using Mutter, Mutter in X is a fat pig with poor performance compared to compiz and was even worse in the old days. In 2010 it was so bad Ubuntu did the massive amount of work in porting their Unity interface (now dropped) from Mutter to Compiz. Compiz is so complex it would be a nightmare to port to Wayland but if some high priority compiz plugins (e.g cube, expo) could be re-implemented in a wayland compositor (such as this Mir port) that would be a damned nice development and perfect for MATE.

              Comment


              • #37
                Originally posted by Luke View Post
                That actually exists, I think GNOME calls it the classic mode or some such thing
                From what I remember, at the time MATE and Cinnamon split off, GNOME devs were hinting very strongly that they wanted to eventually deprecate and remove classic mode.

                Originally posted by Luke View Post
                No matter how big your system, you are saving CPU cycles and probably electricity as a result.
                Yyou don't need to talk to me about desktop weight. I run a mixture of LXDE and KDE components with the divide determined by what functionality I can't live without. (eg. I use Filelight because Baobab's radial graph view is a cheap knock-off that was clearly written to tick a box, rather than with understanding of what makes Filelight so desirable.)

                Comment


                • #38
                  Originally posted by Pajn View Post
                  Because that example implements a full compositor with all features a modern desktop like MATE needs?
                  Oh, and it's fully tested just like Mir right?
                  The example program uses libweston, which in turn implements a full compositor with all features a modern desktop like MATE needs. Correct, yes. But I didn't suggest using this very example. There are window managers out there using libweston for their needs. Pick one and be happy.

                  Originally posted by Pajn View Post
                  Is the MIR hate so strong that people actually prefer MATE to use a bare minimum weston based compositor [...]
                  MATE is currently using a bare minimum window manager, metacity. It was always able to run on any window manager out there. Why dropping that flexibility? Why dragging in a huge code base as dependency, whose future is unclear? Why not using an existing libwayland based window manager and keep the dependency footprint small?

                  Comment


                  • #39
                    Originally posted by Awesomeness View Post
                    SDDM is not a KDE project. It doesn’t have anything to do with KDE. It’s a 3rd party display manager whose maintainer the developer of Liri, a totally different desktop environment that’s competing against KDE and Plasma.

                    You can’t even troll right…
                    SDDM is the de facto display manager of KDE and if you read the explanation for why distributions are all moving to SDDM it becomes obvious that it's because KDE has taken such poor care of KDM that is borderline unusable at this point.

                    In fact, the KDE developers even recommend it over KDM.

                    Four years ago, when Fedora made the switch, it said "As of July 2013, KDM's maintenance consists of bugfixes for the most painful bugs, consisting of only about 20 actual commits to the repository in last two years (excluding translation, themes and merges), adding many new features would require major changes to a lot of the code and there is no active maintainer."

                    SDDM sucks as bad as the rest of KDE. KDE is just somewhat broken on HiDPI and you can fix part of it yourself. There is no "Oh, this is a HiDPI display! Bam! Scaled that for you!".

                    And even when you do scale KDE itself, SDDM doesn't respect that setting, much less autodetect HiDPI like GDM does. And even after you scale KDE, its broken font scaling makes inline spell checking basically useless because it doesn't show the red underline when you make a typo.

                    I think that KDE is suffering from years of most distributions defaulting to some form of Gnome, which has a coherent release system and considers every component to be part of the whole. This whole KDE "Let's split everything up and make a bajillion combinations so bugs are hard to reproduce because like four people in the world use KDE software on Windows." thing is a laugh riot. When someone asks what version of Gnome you run, you can say "3.24.3" and they know what you are talking about. With KDE just devolving into a semi-supportable mess of packages, you have opportunities for things to break that only affects some users some of the time under some circumstances. Some form of inline spell checking not working has been going on in KDE now for over three years but the bug report is still a ghost town. KDE's bugzilla is becoming worse than Launchpad.

                    Comment


                    • #40
                      Originally posted by Awesomeness View Post
                      [...]sign Canonical’s CLA[...]
                      The CLA is only one of the troubling things about Ubuntu. They now have an "IP" policy that mentions "Ubuntu patents" among other things, and as a user you have to agree to all of their evil legal crap to even use it, and they have been openly hostile to distributions based on Ubuntu. So basically they're bending over backwards to make sure you understand that Ubuntu is not Free (as in Freedom).

                      The legal crap that I refuse to agree with is sort of secondary to the fact that their software never seems to work quite right or that every time they try to go their own way with something it ends up dying a horrible death. It's very ironic, because one of the sound samples that used to be included with Ubuntu was a reading of The Fox and the Grapes, and that's essentially the tone that Mark Shuttleworth's posts take every time some crap Ubuntu software flops. Nobody in their right mind would sign Canonical's CLA. Unity and Mir might have caught on if they were genuine FOSS projects, but all the distributions that tried to package them gave up because they refused to compromise the quality of the rest of the distribution to make packages fit in with Unity.

                      Comment

                      Working...
                      X