Announcement

Collapse
No announcement yet.

Power Management To See Changes In GNOME 3.8

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

  • #16
    Originally posted by schmalzler View Post
    Ah, so you really know about all that? Don't think so...
    Running gnom3-session does NOT start mutter. Why? gnome-shell links against libmutter and uses functionality exposed in the lib for managing windows + compositing.
    BUT: all in one fucking process! Make the shell (I mean desktop) hang and you won't be able to manage windows anymore. Same goes for the compositor (though it makes sense to have compositing functionality in the window manager).
    And now gnome-shell will BE (not just start...) the screensaver. Making one procees responsible for so many different tasks is no good design :/
    Indeed, some people miss it, but Mutter is a separate package from Gnome Shell, and having Gnome Shell doesn't mean Mutter is on your system at all(it usually isn't actually, except if you put it yourself). Only libmutter is used.
    And I totally agree, a single process doing everything isn't that good .. I don't get why they did that. There's certainly no reason it would cut down on dependencies or something. Probably it makes debugging more difficult too.(Every crash will be the Gnome Shell process)

    Comment


    • #17
      Originally posted by Rigaldo View Post
      Indeed, some people miss it, but Mutter is a separate package from Gnome Shell, and having Gnome Shell doesn't mean Mutter is on your system at all(it usually isn't actually, except if you put it yourself). Only libmutter is used.
      And I totally agree, a single process doing everything isn't that good .. I don't get why they did that. There's certainly no reason it would cut down on dependencies or something. Probably it makes debugging more difficult too.(Every crash will be the Gnome Shell process)
      yeah unity actually seems much better in this respect for example. every unity service/lens/indicator etc... are different processes.

      Comment


      • #18
        Originally posted by Rigaldo View Post
        Indeed, some people miss it, but Mutter is a separate package from Gnome Shell, and having Gnome Shell doesn't mean Mutter is on your system at all(it usually isn't actually, except if you put it yourself). Only libmutter is used.
        And I totally agree, a single process doing everything isn't that good .. I don't get why they did that. There's certainly no reason it would cut down on dependencies or something. Probably it makes debugging more difficult too.(Every crash will be the Gnome Shell process)


        Really this is just one more questionable design decision on their part in a long list of questionable design decisions, including the aforementioned registry (which even Microsoft admits was a bad idea because .NET uses XML configs not the registry). The only question is when they're going to wake up and realize the mess they're in, I would hope that it's before they come to a screeching halt not really being able to develop further because of it.

        Comment


        • #19
          That design aspect of Gnome Shell has always puzzled me too. I've always found it quite easy to crash because if you trip it up in one area, the whole thing can go down before you can blink.

          I hope they consider a minor technical re-design at some point.

          Comment


          • #20
            Originally posted by bwat47 View Post
            yeah unity actually seems much better in this respect for example. every unity service/lens/indicator etc... are different processes.
            I have never really tried Unity but I thought Unity (the desktopshell) was loaded as a plugin in the compiz process?

            Comment


            • #21
              Originally posted by schmalzler View Post
              Woho, so from 3.8, gnome has one executable, that serves as desktop, window manager, compositor (all these already in <=3.6) and (new) screensaver. Long live modularity!
              And the "inhibition" thing drove me crazy when using vlc in kde. All those damn answers from vlc-devs "it's kde's fault, not our", when kde supported the most recent inhibition draft. And now finally gnome will support it - and magically it will work on kde :/
              Ah, so since the Qt app, which should work so well across all platforms, has problems on the Qt based desktop, CLEARLY Gnome is to blame.
              When are we going to learn? Gnome needs to go. Forget the two state solution. The problem is the two desktop state of affairs.

              Comment


              • #22
                Originally posted by Rigaldo View Post
                And I totally agree, a single process doing everything isn't that good .. I don't get why they did that. There's certainly no reason it would cut down on dependencies or something.
                It'll make it easier to eventually integrate gnome with systemd.

                Comment


                • #23
                  Originally posted by liam View Post
                  Ah, so since the Qt app, which should work so well across all platforms, has problems on the Qt based desktop, CLEARLY Gnome is to blame.
                  When are we going to learn? Gnome needs to go. Forget the two state solution. The problem is the two desktop state of affairs.
                  * there was a powermanagement inhibition draft for a long time - not done by gnome
                  * gnome did not use it, instead they sticked with xdg-screensaver
                  * gnome devs say "xdg-screensaver sucks, buggy as hell - use gnome-session-inhibit"
                  * vlc-dev "than go and report the issues"
                  * gnome: "yeah we did that, but no response"
                  * finally - months later
                  * "come on, why could't we just implement the draft"
                  * -> instant fix from vlc (they could have fixed this for kde long time ago, but did not want...)

                  the whole story:
                  http://trac.videolan.org/vlc/ticket/4739
                  just watch how often it got closed and reopened

                  And no - I won't blame GNOME for buggy vlc, but for not adopting existing WORKING solutions (NIH...)

                  Comment


                  • #24
                    Originally posted by schmalzler View Post
                    Woho, so from 3.8, gnome has one executable, that serves as desktop, window manager, compositor (all these already in <=3.6) and (new) screensaver. Long live modularity!
                    And the "inhibition" thing drove me crazy when using vlc in kde. All those damn answers from vlc-devs "it's kde's fault, not our", when kde supported the most recent inhibition draft. And now finally gnome will support it - and magically it will work on kde :/
                    Nope. GNOME doesn't offer a "screensaver" anymore, rather that feature is presented as Lock Screen. The Lock Screen offers several functionality that is present in gnome-shell, like the message tray, top panel and more. As such reimplementing it in a separate module or process would be a waste of resources and poor coding practice.

                    Of course there's the concern that the Lock Screen process should never crash and reveal your contents but there's a specific helper process dedicated to just that.

                    Finally, if you're *that* concerned about GNOME being late to implement a *draft* of a fdo spec maybe you should have contribute that code yourself. That's how things get done in software, somebody has to write the code.

                    Comment


                    • #25
                      Originally posted by Massa View Post
                      Nope. GNOME doesn't offer a "screensaver" anymore, rather that feature is presented as Lock Screen. The Lock Screen offers several functionality that is present in gnome-shell, like the message tray, top panel and more. As such reimplementing it in a separate module or process would be a waste of resources and poor coding practice.

                      Of course there's the concern that the Lock Screen process should never crash and reveal your contents but there's a specific helper process dedicated to just that.

                      Finally, if you're *that* concerned about GNOME being late to implement a *draft* of a fdo spec maybe you should have contribute that code yourself. That's how things get done in software, somebody has to write the code.
                      The problem is that previous to this gnome kept changing the method to inhibit the screensaver/lock in gnome. every release they would silently change to a different method of doing it, constantly breaking media players, it was ridiculous. Supporting this draft is a very good move and I really hope they stick with it.

                      Comment


                      • #26
                        Originally posted by quenlinlom View Post
                        >Screensaver now part of the Gnome Shell executable

                        Why on Earth would you do that?

                        So now all *box and Unity users would need to use the fugly XScreensaver?
                        Just because Phoronix writes an article doesn't make it true :P It seems the article has been updated already because I don't see that quote.

                        In any case, gnome-screensaver has not been used for a while. It was something for fallback mode. It still can be used by Unity, MATE, etc.

                        Comment


                        • #27
                          Originally posted by quenlinlom View Post
                          >Screensaver now part of the Gnome Shell executable

                          Why on Earth would you do that?
                          Security would be the obvious. The old approach for screensavers/locking was to draw an "always on top" window over the desktop, which occasionally had issues with other programs fighting over "always on top" status, and if the process managing that window was killed/crashed, the desktop was no longer locked, no security. Having integration between the compositor and screen lock ensures that a) nothing can possibly be rendered to the screen while it's locked, and b) the security can't easily be bypassed.

                          Comment


                          • #28
                            Kwin did the same thing when they integrated the screen lock in kwin some times ago. I think phoronix had a article about it?

                            Comment


                            • #29
                              Originally posted by Akka View Post
                              Kwin did the same thing when they integrated the screen lock in kwin some times ago. I think phoronix had a article about it?
                              I think the locker is still a separate process in KDE, but it is managed by the kwin compositor in a special way to make sure nothing can get in front of it. So no, it solves the same problem but uses a completely different approach.

                              Comment

                              Working...
                              X