Announcement

Collapse
No announcement yet.

GNOME OS Working On A New Installer & Other Enhancements To Make It More Practical

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

  • #21
    Originally posted by eagleoneraptor View Post

    Man, I hope that most people in this forum never get a job in UX/UI, they insist in stupid things like server side decoration (that is not really a thing anywhere except in X11) and menus with no other reason than "I'm too rigid to accept anything else".
    Windows has SSD with optional CSD, as does macOS. Not sure why you said "not really a thing anywhere". Gnome is the only desktop environment that I can think of that forces CSD on all applications. Additionally, even Gnome applications utilize a standard menu layout, using the hamburger menu. So again, I don't see where you're coming from.

    Comment


    • #22
      Originally posted by Daktyl198 View Post
      Windows has SSD with optional CSD,
      That is not the case. Have you not noticed that a frozen window under MS windows the buttons the the titlebar don't work.

      MS windows is standard toolkit provided window decorations but those are in fact client side decorations.

      Same with macos where it a standard toolkit doing the decorations. The reality is neither MacOS or MS Windows is SSD.

      Comment


      • #23
        Originally posted by oleid View Post

        Why must we have posts like these on every GNOME news?

        It's like this joke:

        How do you know if a person doesn't like GNOME?
        - they tell you


        So how bout them plugins?

        Comment


        • #24
          Originally posted by oiaohm View Post
          That is not the case. Have you not noticed that a frozen window under MS windows the buttons the the titlebar don't work.

          MS windows is standard toolkit provided window decorations but those are in fact client side decorations.

          Same with macos where it a standard toolkit doing the decorations. The reality is neither MacOS or MS Windows is SSD.
          Not sure if you're aware, but an unresponsive or frozen application on KDE *also* has buttons in the titlebar that don't work. KWin can't visibly remove an application if the process still exists, or else you end up with zombie applications in the task manager that you don't know are there.

          I looked it up and you are correct. That being said, while technically Windows and macOS both render as client side decorations, they both have a single unified toolkit that provides a default window decoration out of the box for anybody using said toolkit to draw any window at all. It requires zero developer effort, window decorations just come free with the toolkit, and the toolkit is tied to the compositor. From an application developer standpoint, it basically acts like server-side-decorations unless the developer explicitly asks to customize the decorations.

          Overall, I'm not sure exactly what the issue is with a compositor providing decorations, while allowing an application to ask to draw their own as an option. Many Linux toolkits don't provide basic CSD to windows as a default (afaik, not even GTK provides a window decoration without you writing the code to create one?) and you can't just assume all new toolkits will. On top of that, as long as the compositor allows CSDs, all applications that utilize the feature will work as expected. Meanwhile, there are many applications (such as video games) that expect to have decorations out of the box on Linux when creating a window just like how it works on Windows or macOS, but then get bug reports that it is not the case on Gnome. Factorio just had a great writeup about this. SSD on Linux gives developers the benefit of it "just working" like it does on Windows or macOS, with a native-looking window decoration, without every toolkit having to implement window decorations at all, let alone ones that look native on different DEs.

          Comment


          • #25
            GNOME pracitcal and/or useful is an oxymoron...

            Comment


            • #26
              Originally posted by Daktyl198 View Post

              Windows has SSD with optional CSD, as does macOS. Not sure why you said "not really a thing anywhere". Gnome is the only desktop environment that I can think of that forces CSD on all applications. Additionally, even Gnome applications utilize a standard menu layout, using the hamburger menu. So again, I don't see where you're coming from.
              Windows and macOS doesn't have server side decorations, the only reason they have consistent decorations is... Oh wait, it's not even consistent there, the only difference is that nobody cares to the point of clusterfucking the Wayland protocol.

              I've read the Factorio blog, I see there is an incompetence of the SDL devs of no providing that transparency themselves.

              OTOH, what's the point on having decorations on programs that are supposed to be ran on fullscreen like games, maximizing and moving are still available on GNOME with the super key.

              The hamburger and traditional menu are two totally different UI concepts.

              Comment


              • #27
                Originally posted by skeevy420 View Post

                I've disliked it since the 6.x days. The UI hasn't changed all that much (especially true since I've used custom roms that innovated all sorts of spiffy UI things that Android still doesn't do) so it just feels like the point of the biyearly updates are to force me to buy new hardware when my phone's manufacturer doesn't want to support a phone for more than two years or my phone's carrier drags ass when it comes to verifying and allowing the OTA to take place so I never even get an update in two years. Fuck AT&T. Never get the AT&T model of a phone. Not every Android runs AOSP straight from Google.

                It isn't Android itself. It's how updates are handled and the frustrations involved with that. That's different, yet similar, to how I feel about biyearly GNOME updates and plugin maintenance. GNOME itself is nice, especially with plugins, but the long term maintenance of plugins is frustrating so I'd rather just use KDE where I configure it once every 6 years versus once every 6 months. Android isn't that bad, but manufacturers and carriers dropping the ball with updates so apps quit working is also a very frustrating experience.

                Biyearly updates without a thought for long term stability sucks. Doesn't matter what it is. That same update strategy is even happening on Windows, too, and it hasn't been very nice for everyone.
                thankfully most system updates can be updated via your app store now (though I only know google store, this can be implemented for custom roms via fdroid). with A13/A14 there won't really be much need to update so often, a lot of security things are playstore, codecs are playstore etc.​ even with A10 which im still on, I don't really see a major need to get a new device until I need av1 hwdecoding or better gaming perf (emulators on the go) outside of security, but in confident enough that the apps I install via fdroid (which are pretty much the only apps I have barring discord) are secure enough.

                Comment


                • #28
                  Originally posted by eagleoneraptor View Post
                  I've read the Factorio blog, I see there is an incompetence of the SDL devs of no providing that transparency themselves.
                  Well, I don't know if the fault was SDL or Factorio devs, because SDL already use libdecor.

                  Comment


                  • #29
                    Originally posted by Daktyl198 View Post

                    I generally agree with you, except that due to one reason or another Gnome has somehow ended up as the default UI for most Linux distros, especially "new user experience" distros like Ubuntu. This leads to a lot of issues with new users not only having to learn a new OS, but also an entirely new desktop paradigm at the same time. Even though I think Gnome is a perfectly okay DE as a whole, I do not think it should be the default experience for any "user friendly" distro that intends to draw new users into the ecosystem.

                    In this way, I think Manjaro had it right by choosing XFCE as their default way back when. More stable than KDE was at the time, with compatibility with Gnome apps, and all while being a traditional desktop interface. I wouldn't really go with XFCE these days, but I still wouldn't go with Gnome either.
                    I don't understand your point, don't get me wrong: they have to learn a new OS and DE like they have to learn another OS and desktop paradigm when switching from Windows to macOS, for example.

                    In fact, most of the keyboard shortcuts work in a similar way than other DEs and Windows, but not of macOS.

                    Command? Option? Global menu? Apps that keep running even after clicking the close button of the window? Dock that doesn't work a as the taskbar? Why snap doesn't work? Why apps go fullscreen when i try to maximize them?
                    ​​​​
                    In general, GNOME doesn't pretend to be macOS and doesn't pretend to be Windows.

                    So yes, it requires effort to learn Linux, requires effort to learn GNOME, requires effort to learn another-thing-thats-not-the-OS-or-DE-you-come-from.

                    So whatever the default DE is in most distros, people should expect that things would be different than they're used to.

                    Goddamn, people nowadays even get confused by switching from Windows 10 to 11, it's just Windows 10 with makeup!

                    Comment


                    • #30
                      Originally posted by Daktyl198 View Post
                      I looked it up and you are correct. That being said, while technically Windows and macOS both render as client side decorations, they both have a single unified toolkit that provides a default window decoration out of the box for anybody using said toolkit to draw any window at all.
                      Take what you wrote and turn it into two questions.
                      Does Wayland have a unified standard toolkit for applications and toolkits? The answer is in fact yes for everything bar rust applications. This would be libwayland-client​.

                      Does unified standard toolkit libwayland-client provide a default CSD the answer is no as this is the problem.

                      Lets say libwayland-client was coded to apply https://gitlab.freedesktop.org/libdecor/libdecor libdecor to the window under gnome or any other compositor that does not provide SSD when application said it wanted SSD decorations there would be no problem.

                      Yes if you want to done like MS windows and MacOS is alter libwayland-client and this is not a gnome project.

                      libwayland-client comes out of this gitlab.

                      Yes libwayland-client and libwayland-server would fall under standard toolkit for Wayland desktop and they both come out that gitlab at freedesktop.

                      Originally posted by Daktyl198 View Post
                      Overall, I'm not sure exactly what the issue is with a compositor providing decorations, while allowing an application to ask to draw their own as an option.
                      Its number of buffers compositor has to handle. This is why macos and Windows are CSD as well. So if it CSD you have 1 buffer at the compositor. If it SSD at compositor you have 2 buffer 1 buffer without the decorations and 1 buffer where the compositor has added the decorations.

                      It also possible that the application side can be using a single buffer with understanding that X area in buffer is already taken by the CSD decorations. So you can reduce the number of buffers to manage going CSD.

                      Yes people have been saying over and over that gnome should do it like Wndows and MacOS with window decorations the reality is Gnome is implement there stuff like Windows and MacOS but in fact being let down by libwayland-client that part of the Wayland universal toolkit they don't control.

                      Exactly who has been pointing the finger at libwayland-client and asking why does this not have way to plug in a default CSD for for SSD applications running on Wayland compositor that CSD only so they work right. Yes there should be no requirement to alter SSD application code just have libwayland-client do the lifting when required.

                      Comment

                      Working...
                      X