Bug 124782 - xscreensaver-demo turns on just this application which one is trying turn off
Summary: xscreensaver-demo turns on just this application which one is trying turn off
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xscreensaver   
(Show other bugs)
Version: 2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-05-29 23:17 UTC by Michal Jaegermann
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-08 21:06:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Michal Jaegermann 2004-05-29 23:17:33 UTC
Description of problem:

Assume that some xscreensaver application it creating problems
and that one tries to turn it off either via preference settings
or calling xscreensaver-demo directly; which boils down to the
same.  Even just touching a check button to turn that off brings
up that troublesome program in question and if this locks up
a machine (which just happened to me due, turned out, to test
of some development kernels) then one is stuck in an "interesting"
chicken-or-egg problem.  If moreover "Only One Screen Saver" with
a "wrong" entry was put there then just attempting to open
a configuration is locking up the whole thing.

One can get out from that vicious cirle by directly editing
~/.xscreensaver file but this is not entirely obvious that one
should look just there and not in some gconf entries.  It would
be nice to have _at least_ some delay to allow to change some
settings without triggering troubles.

Version-Release number of selected component (if applicable):
xscreensaver-4.14-5

Comment 1 Ray Strode [halfline] 2004-11-08 21:06:00 UTC
Hi Michal,

Adding artificial delays to get around lock up problems is probably
not the best approach.  A better approach would be to fix the lock up
problems.  Any lock up problems should be fixed on a case-by-case
basis   in separate bug reports, of course.


Note You need to log in before you can comment on or make changes to this bug.