Power Management To See Changes In GNOME 3.8

Quote:

---

Originally Posted by schmalzler

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.

Quote:

---

Originally Posted by Rigaldo

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.

Quote:

---

Originally Posted by liam

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...)

Quote:

---

Originally Posted by schmalzler

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.

Quote:

---

Originally Posted by Massa

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.

Quote:

---

Originally Posted by quenlinlom

>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.

Quote:

---

Originally Posted by quenlinlom

>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.

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

Quote:

---

Originally Posted by Akka

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.