Announcement

Collapse
No announcement yet.

New Gestures Code Squeezes Into GNOME 46

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

  • New Gestures Code Squeezes Into GNOME 46

    Phoronix: New Gestures Code Squeezes Into GNOME 46

    While the GNOME 46 desktop is being released next week, one of the very last minute feature items being merged hit the Mutter codebase on Friday...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    This and previous major feature freeze exceptions gone into this release shows just how unnecessary and counterproductive such concept is.

    From what it looks like, feature freeze exists to give a simple stop to non-inside development so the golden boulward can get more time allocated to their special needs..

    Comment


    • #3
      Merge requests sitting around for years seems to be the norm for GNOME

      Comment


      • #4
        if mutter ever gets traction on mobile I'll be very impressed and will apologize for doubting them all this time. but for now it's a shame that gnome-shell folks decided to put a as of now non-existant mobile/touch interface userbase on par with desktop use case, let alone us power users.

        Comment


        • #5
          Originally posted by varikonniemi View Post
          This and previous major feature freeze exceptions gone into this release shows just how unnecessary and counterproductive such concept is.

          From what it looks like, feature freeze exists to give a simple stop to non-inside development so the golden boulward can get more time allocated to their special needs..
          I like your confidence.

          1. mutter is not subject to feature freeze. Any request for freeze break is politeness only and not needed.
          2. This merge request is not the only merge request that has gone in recently. There are multiple others and you will see the same before previous releases too.
          3. Its not about gatekeeping - the main mutter developers are employed by Red Hat, but both major merge requests that have gotten phoronix articles were by non-red hat contributors.
          and 4. there is a freeze break request mechanism that was created to allow features in during freezes. It exists for a reason. Using it would not be a conspiracy.

          Comment


          • #6
            Originally posted by fitzie View Post
            if mutter ever gets traction on mobile I'll be very impressed and will apologize for doubting them all this time. but for now it's a shame that gnome-shell folks decided to put a as of now non-existant mobile/touch interface userbase on par with desktop use case, let alone us power users.
            what makes you think they put it on par with the desktop use case, or replaces power user functionality?

            Why should gnome-shell developers prevent other developers improving the mobile capabilities if they do not harm the desktop/power users?

            What if those same mobile developers develop features which benefit the desktop/power users, as is the case here?

            PS this is just plumbing, code that will be made use of later, but gets somethings in order to allow building on later. AFAIK it doesnt add anything user facing yet.

            Comment


            • #7
              Originally posted by You- View Post

              I like your confidence.

              1. mutter is not subject to feature freeze. Any request for freeze break is politeness only and not needed.
              2. This merge request is not the only merge request that has gone in recently. There are multiple others and you will see the same before previous releases too.
              3. Its not about gatekeeping - the main mutter developers are employed by Red Hat, but both major merge requests that have gotten phoronix articles were by non-red hat contributors.
              and 4. there is a freeze break request mechanism that was created to allow features in during freezes. It exists for a reason. Using it would not be a conspiracy.
              The conspiracy is to make Linux programs shitty by freezes and freeze exceptions and stable releases and whatever else shit they come up with that steals developer resources.

              When we have a perfectly fine model of rolling development and rolling release, with the curation happening at the point of merging.

              I have been running manjaro twice as long as ubuntu before that, and i have had twice as many system breaking updates on ubuntu. That's +400% difference for rolling release and development model. No freezes. Just cutting the software for release when it is deemed stable.
              Last edited by varikonniemi; 16 March 2024, 03:13 PM.

              Comment


              • #8
                Running a distro is not the same as developing one.

                As a user I would also wish developers could code everything to the best possible on their first attempt and without making any errors by the time I need to use it for the first time. But as a sane person I know that isnt possible.

                I also love how you are doubling down on your position with such confidence when you dont even know that gnome doesnt have code freezes since a while.

                1. There are string freezes. This is to allow translation teams time to translate the software for users.
                2. There are UI freezes. These are to allow release teams to gather screen shots, to check the UI works are other similar reasons.
                3. There are feature freezes for many gnome components, but mutter and gnome-shell are exempt from them, so irrelevant here.

                So keep to your conspiracy theories.

                Comment


                • #9
                  Originally posted by You- View Post

                  what makes you think they put it on par with the desktop use case, or replaces power user functionality?

                  Why should gnome-shell developers prevent other developers improving the mobile capabilities if they do not harm the desktop/power users?

                  What if those same mobile developers develop features which benefit the desktop/power users, as is the case here?

                  PS this is just plumbing, code that will be made use of later, but gets somethings in order to allow building on later. AFAIK it doesnt add anything user facing yet.
                  i've used gnome from the beginning. every design decision for the last 15 years has been for touch interface. it is peak gas lighting not to admit this.

                  for example, when they re-did the settings tray to make it a more touch friendly interface, they didn't even put in mouse over tooltips for those icons. because in their world, mice don't exist, so why bother. there's more than one way to shutdown a machine, but what does the power button in the settings tray do? bring up a menu? reboot? shutdown? sleep? who knows. it could be one action this release and a different thing the next release. there's just no way for us to know.

                  the one thing gnome-shell has going for it is that the phoc/phosh people aren't getting it done, and they are the only gnome-ish touch interface out there. maybe once cosmic shows them the way to build a lean gnome interface for desktop, the phosh/phoc people will rebase their work on cosmic. that would be interesting for sure.

                  Comment


                  • #10
                    Originally posted by fitzie View Post
                    for example, when they re-did the settings tray to make it a more touch friendly interface, they didn't even put in mouse over tooltips for those icons. because in their world, mice don't exist, so why bother.
                    Oh, that's easy to debunk. "why bother" you say? There's been an initiative going on for a while to streamline tooltips in *all* GNOME apps. It means they care about desktop/mouse workflows, but tooltips didn't make sense for quick toggles in a system tray.

                    Comment

                    Working...
                    X