Page 3 of 3 FirstFirst 123
Results 21 to 29 of 29

Thread: Power Management To See Changes In GNOME 3.8

  1. #21
    Join Date
    Jan 2009
    Posts
    1,301

    Default

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

  2. #22
    Join Date
    Oct 2009
    Location
    .ca
    Posts
    398

    Default

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

  3. #23
    Join Date
    Sep 2011
    Posts
    135

    Default

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

  4. #24
    Join Date
    Sep 2011
    Posts
    27

    Default

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

  5. #25
    Join Date
    May 2010
    Posts
    684

    Default

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

  6. #26
    Join Date
    Jul 2012
    Posts
    286

    Default

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

  7. #27
    Join Date
    Apr 2010
    Posts
    704

    Default

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

  8. #28
    Join Date
    Jul 2011
    Posts
    342

    Default

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

  9. #29
    Join Date
    Feb 2011
    Posts
    1,066

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •