Announcement

Collapse
No announcement yet.

GNOME Shell + Mutter See Big Last Minute Improvements With The GNOME 3.36 Beta

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

  • #21
    Geary over Evolution? Is this an April fools joke?

    Comment


    • #22
      Originally posted by Shiba View Post
      Geary over Evolution? Is this an April fools joke?
      Agree 100%. I was just testing Geary (3.34.2 Flatpak version provided by Fedora) last month with my staging email account and it definitely needs a lot more work... I will just name two issues: huge memory consumption (to the point of having to close Geary after a couple of hours to recover memory) and the simple dialog to show email headers not working at all?.

      Comment


      • #23
        Originally posted by 144Hz View Post
        brent Asking for not-ready-yet MRs to get prematurely merged is just another example of instant gratification. That’s pretty much the worst flaw in the human mind. Kids struggle with it quite a lot but it has no place in release engineering. Linus Torvalds would probably say something like “Do not send me Untested Crap” and demand you leave the gene pool.

        So no, that will not be merged for now. Almost-ready-to-be-merged MRs will always be there. Use them as you like. What matters is that Shell/mutter got massive improvements on merge and review capacity. 2 new maintainers and 2 new merging developers got appointed this release cycle.
        Like someone else noted, I'm, not asking for immature MRs to be merged with no proper review. I thought that was clear, because frankly, that's what I said: MRs don't get enough attention by the maintainers. I'm asking the GNOME maintainers to actually work with the author's of the MRs: that is, provide actual reviews, response to questions in a timely fashion etc. to get them ready in due time, instead of frustrating contributors. The comparison with other projects is spot-on.
        Last edited by brent; 07 February 2020, 06:04 AM.

        Comment


        • #24
          Originally posted by 144Hz View Post
          Isedonde Vanvugt is sometimes spamming immature MRs. A large ratio he just closes again. He does zero reviews. It is all there in the logs.
          It's just a different style of development: many MRs, not just by Daniel van Vugt are of the "request for comments" type. So he's proposing a possible change and asking if it is the right way to do it. This is typical, what's wrong with it? In fact, this is what MRs are supposed to be used for! (They're basically a formalized version of the "send patches to mailing list and discuss them" style of development.)

          It looks like you see it as a kind of responsibility even for external contributors to do code reviews. Why is that? I don't know of any other projects that require it and it doesn't make much sense either. Reviews should be primarily done by people that are familiar with particular subsystems. This is how it works for other projects, too. GNOME isn't special.

          Couldn’t get any worse than that. It’s really difficult for the maintainers to work with. Worst part is how this pretty bad developer behavior triggers random users who suffer from instant gratification issues. Those users just want everything commited NOW.
          Ok, so "NOW" is apparently equal to wanting some action after months of patiently waiting?

          Comment


          • #25
            Originally posted by Mez' View Post
            By favourite, we are talking about default (for vanilla Gnome), or am I wrong?
            In that case, I'm not complaining about being forced. I'm just saying I'll have to revert these changes as I would personally do (almost) the exact opposite. But that's not too important, it'll be done by Ubuntu or I will do it in a few minutes.

            It was also ironic.
            Gnome has such a long way to go before being fully usable at this point I just hope they're going to focus on more important things (workflow, design, extensions, multi-monitors, Hidpi) than their always-in-alpha-stage apps that not many people actually use before downloading real apps. It might have a good appeal to have sorts of working integrated apps for very basic features, but when there is basically always another app that does it better, it's a bit of a waste of resource. Especially when Gnome needs a tremendous amount of work.
            I use GNOME with no extensions, can confirm I find it way more usable than Windows.

            Comment


            • #26
              Isedonde A lot of MRs will get picked up late in the cycle because there's a rush to get any UI changes in before the UI freeze. Discussions also happen in IRC a lot so there may be other reasons why it isn't merged yet.

              Comment


              • #27
                Originally posted by Isedonde View Post
                ...
                However, I still feel like mutter lacks review capacity / maintainers / mergers. Take this MR for example: https://gitlab.gnome.org/GNOME/mutte...e_requests/724
                It was proposed 5 months ago, so well before the previous 3.34 release. As is to be expected for such a change, there was some initial discussion and clarifications of the change, which is a good thing.
                ...
                I just want to add that a lot of communication between the devs and maintainers does not happen in gitlab but on IRC. And I can assure you that these MRs got way more attention than it seems from the outside.
                Still, reviewing is a heck lot of work, because you want to make sure no to regress and, even more importantly in many cases, want a long term perspective in mind. Otherwise it becomes very easy to create unmaintainable code, which hurts much more than not having a certain optimization :/

                Comment


                • #28
                  Originally posted by Teggs View Post
                  These arguments often include that holding down a key and pressing three others, or opening a search bar and entering characters, is faster than moving a mouse and double-clicking on a screen object: an argument that was false, is false, and will remain false in future.

                  I wonder what is really driving this push to kill desktop icons.
                  I don't believe that you're able to show the desktop and double-click an icon in 0.2-0.5 seconds, which is the time a moderately slow keyboard user spends tapping four or five keys. Maybe a few professional gamers are faster with the mouse than most users are with a keyboard, but it's very difficult to believe. But obviously, modern systems should learn what you want and provide fast access to that, rather than requiring you to maintain a map manually.

                  The desktop icons was removed from the default file manager because nobody wanted to maintain it and it was in the way of other things, but also because the desktop should belong to the desktop shell rather than a file manager or web browser.

                  Comment


                  • #29
                    ...Rhythmbox to GNOME Music...
                    Gnome Music fails to import my music collection which is ~320GB, mostly .flac. It just locks up in the face of that amount of files.

                    CMUS can import that many in speedy fashion. Though I have issues with the UI in CMUS.

                    I really haven't found a music player I like for Linux, I just have to use MediaMonkey on Windows. I've seriously considered coding my own.

                    Comment


                    • #30
                      Originally posted by brent View Post
                      I really hope they land a lot more stuff! The most important area of GNOME, performance, still didn't get the attention it deserves. And this time it's not just Daniel's MRs that have been stalled. E.g. fullscreen unredirection on Wayland has been quite ready for months, but doesn't get any attention from maintainers. Many of the performance-oriented MRs would only require a little bit of additional work, if any. It's a bit sad.

                      The gnome-with-patches copr shows the potential of the current set of performance patches: with the patches, GNOME runs at solid 60 fps at all times, for the first time. Doesn't matter if you have 100 windows in the overview or if a heavy build runs in the background, it's still nearly flawless.
                      Is this it? I'm tempted to give it a try.
                      https://copr.fedorainfracloud.org/co...-with-patches/

                      Comment

                      Working...
                      X