Re: gnome-screensaver

[Shaun McCance <shaunm gnome org>]

On Wed, 2006-02-15 at 12:54 +0800, Davyd Madeley wrote:
> Quoting David Zeuthen <david fubar dk>:
> 
> >> > This was moved to gnome-power-manager by Jon, as monitor DPMS control
> >> > was considered more of a "power" thing than "screensaver" thing. You can
> >> > configure monitor power down settings using gnome-power-preferences.
> >>
> >> I feel it should be available in both dialogs (sending the setting to
> >> g-p-m if it is alive on the D-BUS).
> 
> > I think this should be achieved with a button that opens
> > gnome-power-preferences much like the Keyboard capplet got a "->
> > Accessibility..." button.
> 
> Perhaps. That is certainly an option. Except that it doesn't deal with 
> the case
> where we don't ship g-p-m.
> 
> >> Think of the case where g-p-m is not
> >> available (as will happen in GNOME 2.14 vanilla), how are people going
> >> to put their monitors to sleep?
> >
> > Please tell me, how are people going to put their computer to sleep with
> > GNOME 2.14? Also since xscreensaver wasn't really part of GNOME anyway,
> > I hardly feel this is a regression. However, from a realistic point of
> > view all distributions that care about GNOME will most likely ship both
> > g-s and g-p-m anyway. So I don't really see your point.
> 
> My point is that you're forcing the vendors hand. We are telling 
> vendors to now
> use our screensaver module, but in order to get the features of the old
> screensaver module you have to use a component that we actually 
> deceided not to
> bless, because we weren't sure about it yet... wha?
> 
> I'm not sure why you're bringing sleep into this. Monitor power down is a
> feature used on many computers, sleep is not as common (ie. workstations).
> 
> > Another thing is that g-p-m will most likely be part of GNOME 2.16 and
> > then we want to change to the link button (because it makes sense) as
> > that will confuse 2.14 users.
> 
> Or perhaps we will not. We are however facing a serious regression now 
> in which
> if a vendor decides to ship THE MODULES WE HAVE SAID "HERE, USE THESE", they
> are going to be lacking the feature where the user can't specify the monitor
> off timeout: SOMETHING THAT USED TO WORK PRETTY GOOD BEFORE I UPGRADED.
> 
> I see two solutions to this:
> (1) solve the regression; or
> (2) punt gnome-screensaver until gnome-power-manager can also be included
> 
> I personally think that (1) is the correct solution here, mostly 
> because I think
> that monitor sleep time should be in the same dialog as screensaver settings.

And this decision needs to be made sooner, rather than later.
Our schedule lists January 18th as the freeze for new modules.
Quote: "new modules and functionality are chosen now."

If this were some random stand-alone application, I probably
wouldn't make such a fuss.  But this is something we have to
document in the User Guide.  We have exactly one month before
we ship 2.14.0, and we need to get our documentation done.

Joachim has been working very hard on the User Guide.  It's
looking better than it has in years.  But he's in a position
where he doesn't know what to document with respect to the
screensaver and monitor power settings.

The GDP documents vanilla Gnome.  Shipping gnome-screensaver
without gnome-power-manager means feature regressions.  So
distros will do one of three things:

1) Drop gnome-screensaver and ship xscreensaver anyway: The
   User Guide wrong for their platform.
2) Ship exactly what we specify: They have feature regression.
3) Ship both gnome-screensaver and gnome-power-manager: Part
   of the desktop (as perceived by the user) is undocumented,
   or is documented in a peculiar place.

There's no good outcome here.  Now, to be fair, xscreensaver
was never officially in Gnome.  But we documented it anyway
in the User Guide.  Since all the distros used it, it didn't
create any real problems.  On the other hand, distros may now
use gnome-screensaver and gnome-power-manager regardless of
our official blessing.  In the end, we have bad documentation
no matter what we do.

I know I've railed against a lot of new modules this time
around, but the fact is that we screwed up.  We should have
made these decisions a month ago and sent a clear message
to the distros.

--
Shaun