Announcement

Collapse
No announcement yet.

GNOME 40 Released With Many Improvements

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

  • #51
    Originally posted by Delgarde View Post
    You know, when Gnome Shell was first released, the vertical layout was something it was criticised for, because it was "gratuitously different" to pretty much every other desktop that used a horizontal layout.
    What is this supposed to mean? Before 3D-accelerated desktop effects there was no concept of "horizontal" nor "vertical". Virtual desktops were just switched from A to B without any transitioning effect. The pager widget on a toolbar usually supported arbitrary configurations from fully horizontal to fully vertical to a grid composition. For those using a horizontal taskbar, the pager widget would have a horizontal layout, and for those using a vertical taskbar it would most likely be vertical.

    Compiz introduced the desktop effects and is most famous for the "cube" effect. Yeah, that effect indeed had a horizontal layout of vdesks. I believe there were other effects with alternate layouts, though. I cannot recall whether it was Kwin or Compiz, but while a KDE user myself, I actually favoured a 2x2 grid alignment of virtual desktops. The gist is, however, that the alignment was configurable.

    After moving to Gnome I understood how much its vdesk configuration made sense. Not only is vertical transitioning much more efficient, Gnome's transitioning effect always moved to the adjacent "virtual virtual desktop", skipping all the views in between the source and destination. KDE's effects to this day cannot do this, so if I switch from desktop 1 to desktop 4, the stupid effect will scroll through three virtual desktops and it looks hideous!

    Comment


    • #52
      Originally posted by linuxgeex View Post
      Really wish that there was standardisation around use of the compose key for the generation of emoji.

      ie [compose]+( "smile" [enter]
      or [compose]+( ":-)" [enter]

      or some such relatively intuitive pattern, and have the gnome keyboard settings app actually list what these patterns are instead of having everyone on the planet googling it because there's no coordination between the developers and the UI designers.
      In Gnome you can press Ctrl+Shift+e and you'll get an input prompt for emoji. Simply type in what you want, be it e.g. "smile" or ":-)", and then press Space and you'll get your input converted to an emoji. If at that point you want to see more choices or explore similar patterns, just press Space for a second time and you'll get exactly what you're asking for. There's also an equivalent widget for Unicode symbols with Ctrl+Shift+u.

      Also, IBus provides a separate tool called Emoji Picker which you can use as an IME for emoji, though I find that Gnome's internal tool is more than perfectly adequate for the job.

      Originally posted by Danielsan View Post
      I have never seen Gnome 1.x but the difference between Gnome 2.x and 3.x was abysmal. I would be expected the same pattern between Gnome 3.x and Gnome 40.x ... ... But unfortunately Gnome 40.x looks quite similar to Gnome 3.x it is always ugly but differently...
      Let me ELI5 that for you: in its GTK3 incarnation, Gnome has seen 40 releases up to this day. Up to the previous 38th release, the versioning scheme was tightly coupled with the GUI toolkit used to produce Gnome, aka GTK3, thus we had a pattern of GTK.Gnome, e.g. 3.38.

      Moving on, the Gnome devs have decided that instead of doing major re-releases of their software every few years, the kind that usually end up producing more issues than they solve (Gnome 2 -> 3, KDE 4 -> 5, Windows 7 -> 8, etc), they will instead maintain a single product and constantly improve on its design and technical quality in controlled increments (which seems to be the trend across all major desktops nowadays).

      The first step in that direction was to decouple Gnome's updates from GTK's updates, which in its GTK3 iteration has remained at 3.24 ever since. The second step was rebasing Gnome to GTK4. The third step was to remove the (now redundant in every single way) "3" in the versioning scheme and only track the DE's releases.

      Thus, what would have been "Gnome with GTK3, release 40" has now become simply "Gnome release 40" and it just so happens that behind the scenes the GUI toolkit has switched from GTK3 to GTK4.

      Thanks for reading, dear layman.
      Last edited by Nocifer; 25 March 2021, 07:43 AM.

      Comment


      • #53
        Funny, I just tried to open Gedit and

        (gedit:701575): GLib-GIO-ERROR **: 12:54:41.926: Settings schema 'org.gnome.nautilus.preferences' does not contain a key named 'confirm-trash'
        Trace/breakpoint trap
        So, in fact, the removal of the confirm trash option is actually problematic for me...

        Comment


        • #54
          oshan.wisumperuma
          BesiegedAce

          It's clear that Gtk and Nautilus don't care about people who work with images.
          It may suck, but they're not Red Hat's user target.

          Comment


          • #55
            Originally posted by Mez' View Post
            Funny, I just tried to open Gedit and


            So, in fact, the removal of the confirm trash option is actually problematic for me...
            If you're on Arch, it's probably because they've began selectively updating Gnome components to v40, but Gedit is still at v3.38.1 which is not compatible with the changes in Gnome 40. See here: https://bugzilla.redhat.com/show_bug.cgi?id=1931180 (follow the link to the duplicate bug report for more info).

            Comment


            • #56
              Originally posted by Nocifer View Post

              If you're on Arch, it's probably because they've began selectively updating Gnome components to v40, but Gedit is still at v3.38.1 which is not compatible with the changes in Gnome 40. See here: https://bugzilla.redhat.com/show_bug.cgi?id=1931180 (follow the link to the duplicate bug report for more info).
              Thanks, I'm on Manjaro and they did update selectively indeed.
              I've downgraded both nautilus and gsettings-desktop-schemas and that solved it. Gedit is working again. I've also added them to Ignorepkg to hold them for now.

              Comment


              • #57
                Originally posted by Nocifer View Post

                If you're on Arch, it's probably because they've began selectively updating Gnome components to v40, but Gedit is still at v3.38.1 which is not compatible with the changes in Gnome 40. See here: https://bugzilla.redhat.com/show_bug.cgi?id=1931180 (follow the link to the duplicate bug report for more info).
                I have to say the Gnome package maintainer of Arch Linux is an incompetent moron. For every damn release of Gnome the packages are pushed to repos one at a time, breaking the whole desktop and even GDM if you happen to upgrade at the wrong time. Yes, they are in the "testing" repository, but probably most Arch users have been running "testing" packages for years without any hiccups bar this r3tarded Gnome mess. (I know I have.)
                Last edited by curfew; 25 March 2021, 11:01 AM.

                Comment


                • #58
                  Originally posted by curfew View Post
                  I have to say the Gnome package maintainer of Arch Linux is an incompetent moron. For every damn release of Gnome the packages are pushed to repos one at a time, breaking the whole desktop and even GDM if you happen to upgrade at the wrong time. Yes, they are in the "testing" repository, but probably most Arch users have been running "testing" packages for years without any hiccups par this r3tarded Gnome mess. (I know I have.)
                  Let's just say that for quite some time now Arch as a whole has generally lacked in quality (especially that kind of quality that made it famous in the first place), and leave it at that. It's my hope, especially after watching some of the recent Arch Conf 2020 presentations, that the new project leadership will hurry up and fix these issues sooner rather than later, otherwise I fear that Arch will end up being deprecated to a kind of Debian, i.e. a base for other, better distros to build upon (if you ignore the server aspect, which Arch isn't suitable for).

                  Comment


                  • #59
                    Originally posted by aufkrawall View Post
                    Though on Wayland
                    -cursor still has input lag of a software cursor
                    Speaking as someone who actually used software cursor with GNOME Wayland for some time[0], I can assure you it's not really the same.

                    [0] Due to amdgpu kernel driver bugs; maybe you're hitting that as well? Check
                    Code:
                    journalctl [email protected] -b0
                    for cursor related messages.

                    -frame presentation with vsync < refresh rate for games in Wine/Proton looks more stuttery than it should
                    There is ongoing work which might help for this (Dynamic frame clock dispatch max render time for reduced input latency and WIP: Automatic frame-clock-dispatch and frame-callback delaying for reducing input- and presentation latency), but didn't make it for 40 unfortunately.

                    (The first one should improve HW cursor latency as well)

                    -grabbing scroll bar in FF Wayland isn't smooth
                    Which Firefox version? With WebRender enabled?

                    Not directly related to Wayland:
                    -changes to GPU gamma ramps still use legacy interface and thus cause missed vblanks
                    Actually this is directly related to Wayland (otherwise this is done in Xorg). This can be improved now that atomic KMS support has landed in 40, will happen for colour management / HDR support at the latest.

                    Comment


                    • #60
                      Originally posted by intelfx View Post
                      Do you have bug reports for any (or all) of that?
                      I mostly only report bugs to projects that I use, so no.

                      Originally posted by intelfx View Post
                      BTW: cursor is always "software". The GPU does not talk to the touchpad or the mouse adapter. Input lag refers to the lag in handling input events and converting them into cursor position updates or rendering commands (which happens on the CPU, obviously). Hardware rendering of the mouse cursor (which has been implemented in Mutter/Wayland quite some time ago) has nothing to do with input lag.
                      Yes, it has. Only a hardware cursor can avoid the vsync latency of a compositor. Which Gnome Wayland unfortunately doesn't achieve yet, despite of being hardware or not.

                      Comment

                      Working...
                      X