[7599] in SIPB bug reports
Re: xscreensaver conflict with default dotfiles
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Jun 16 13:06:26 2000
Message-Id: <200006161706.NAA07787@small-gods.mit.edu>
To: John Hawkinson <jhawk@MIT.EDU>
Cc: Greg Hudson <ghudson@MIT.EDU>, bug-sipb@MIT.EDU
In-Reply-To: Your message of "Fri, 16 Jun 2000 12:50:28 EDT."
<200006161650.MAA02190@contents-vnder-pressvre.mit.edu>
Date: Fri, 16 Jun 2000 13:06:15 -0400
From: Greg Hudson <ghudson@MIT.EDU>
>> You are the one who pushed fuzzballs to decide to turn the
>> screensaver on by default.
> I encouraged that, yes. I don't see how that is relvent.
It's highly relevant. As I stated before, the form of your message
was, "Your proposal does not solve all problems in this intrinsically
suboptimal situation. I object." Getting pushed on both sides from
the same person is exceedingly annoying, and I will definitely keep
this in mind the next time you ask Athena to do something nontrivial.
> That the case, I am not sure it would not be best to have
> /usr/athena/bin/xscreensaver (or perhaps even
> /usr/athena/gnome-bin/xscreensaver -- a path used only by gnome) in
> addition to /mit/sipb/bin/xscreensaver, even if they are different
> programs.
People who do "add sipb" and later run "xscreensaver" will be
surprised to find that it is not the same program as they used to get.
Since that's likely the most common way the SIPB xscreensaver is run,
this approach would not noticeably reduce transition costs.
> I'm afraid I feel like I'm missing something here. I do not
> understand how "dueling screensavers" would occur
1. User logs in. Default dotfiles run xss, user runs xscreensaver.
2. User activates SIPB xscreensaver
3. Ten minutes later, xss kicks in, yielding stroboscopic effects.
> If it's not that, then how is this problem specific to xscreensaver?
> It seems like you'd encounter the same problem with xlockmore (in
> outland), for instance.
We didn't consider xlockmore. Depending on the number of people who
use it, that may be a bigger problem, since there are mitigating
circumstances surrounding the SIPB xscreensaver (it's been broken on
the SGI for a long time, will probably be broken on Solaris soon, and
there is a name conflict anyway) which don't apply to xlockmore.
> This seems like a clear problem in gnome, if it expects a specific
> screensaver and is not configurable.
jwz xscreensaver is considered part of gnome. You could as easily say
that it's a "clear problem in gnome" that it expects a specific panel
program and is not configurable.
Unlike windowmanagers, screensavers have widely different invocation
models; you can't easily make a slot which they will all fit into.
