Re: xscreensaver capplet.

[Jamie Zawinski <jwz jwz org>]

I note with sadness that Gnome folks keep coming at this from the point
of view of "how do we make the existing GNOME Control Center capplet not
suck", or "we must again rewrite the capplet!"

First let me make clear where I am coming from on this issue: 

xscreensaver already has a configuration UI.  It comes with
xscreensaver, and is called xscreensaver-demo.  It works standalone
or as a capplet.

For some reason, some GNOME folks don't like mine, and rather than
making improvements to it and submitting them back to me, or even
making *suggestions* to me of how they think I should change it,
they felt the need to write their own from scratch.

Further, that NIH GNOME capplet spent the better part of *two years*
being so buggy and unusable, that I was constantly besieged by bug
reports from users who thought that xscreensaver was malfunctioning,
when really it was chronic braindamage in the GNOME capplet.  

I've been fielding your bug reports for a long time now, in a program
that shouldn't have been written in the first place.  So I'm more than a
little irritated about the whole thing.

--------------------------

Moving right along.  Here's what's wrong with the GNOME capplet that
comes with GNOME 1.2.

(I understand you've rewritten this yet again for GNOME 1.4.  I haven't
seen it.  I'd love to try out your new capplet, if you can point me at
RPMs that will run on my Red-Carpet-updated Red Hat 7.0 system.)

   1: When one upgrades xscreensaver, the crapplet does not reflect
      the addition of new modes.  That's because you felt the need to
      keep a separate list of the hacks, rather than just parsing them
      out of the ~/.xscreensaver file at run-time.  That's ridiculous.

      I occasionally hear people suggest things like "yeah, we should
      generate our config files from the xscreensaver files each time
      a new xscreensaver is released."  NO!  That's an amazingly dumb
      idea.  What you should do is read the *user's* .xscreensaver file
      instead of storing your own thing off to the side.  Storing two
      copies of anything is just crazy.

   2: If GNOME was installed from RPM, and xscreensaver was installed
      from source, then GNOME claims that there are *no* display modes.

   3: If you've ever run the GNOME crapplet and allowed it to launch
      xscreensaver, then from that point on, neither xscreensaver-demo
      nor xscreensaver-command work right: the crapplet launches the
      daemon in a stupid way that makes it impossible to ever run a
      hack other than the crapplet-selected one.  Click on any other
      hack, and the same (wrong) one runs.

   4: The crapplet still tries to control DPMS, but for about six months
      now, xscreensaver has been controlling DPMS, so that doesn't work.
      The xscreensaver daemon wins, and the crapplet settings appear to
      be a no-op.  Again, this is because the crapplet is doing stuff
      behind the daemon's back instead of just writing data to the
      ~/.xscreensaver file and letting the daemon do things on its own.

   5: The run-a-small-version-of-the-hack-in-an-embedded-window
      misfeature sucks in the following ways:

      5.A:  Most hacks look TERRIBLE when running in a tiny window.
            The small-window behavior is not at all indiciative of
            of the full-screen behavior, because most of the behaviors
            are pixel-based.  For example, try these:

                attraction -geom =80x80
                attraction -geom =1000x1000

            If I saw the former, I would think, "wow, what a boring
            screensaver, it just spastically blits colored circles
            around."  When really, the behavior in a large window is
            slow and organic.  This is true of almost ALL of the hacks:
            they just look awful when scaled down.

      5.B:  Many of the hacks can't possibly work at all when running
            on an embedded window, for example, all of the hacks that
            grab an image of the desktop to operate on.  The last time
            I checked, demoing these hacks caused the crapplet to start
            to malfunction in various bad ways.

      5.C:  On some systems, launching certain hacks in a small window
            make the system almost totally unresponsive.  For example,
            on some kiosk machines I have (200mhz PCs with
            non-accelerated video) running the GL hacks in a subwindow
            makes the mouse all but stop moving: it's a minute-long
            chore to get up to the close box!  Whereas, when demoing
            in full-screen mode, it's not a problem, since a single
            click anywhere exits the time-consuming part.

      5.D:  When run in tiny windows, a number of the display modes will
            dump core.  That's because they were never intended to run
            on "screens" that small, and they were never tested that
            way.  If you look in the GNOME bug database, you'll see
            a ton of useless bug-buddy bug reports sent in by people who
            noticed core files in their home directory from, e.g., qix,
            and dutifully sent them in.  All of those cores are from
            the crapplet trying to run them in tiny windows.

            This is why I removed the -window-id option: because I was
            tired of seeing bug reports about core files that were only
            generated when the crapplet tried to do something dumb.
            The -window-id option was a bad idea, and never worked
            right.  So I fixed the crashes by removing the buggy option.

      In my opinion, there are only two workable ways to have a small-
      window demo of the hacks: the first is to simply have a static
      PNG image of the hack.  For example, the images on 
      "http://www.jwz.org/xscreensaver/screenshots.html";.  Those images
      are representative of the hacks because I did NOT run the hacks
      at a small size to make them: I ran the hacks full screen, took
      a snapshot, and then scaled the images down.

      The other way would be to have embedded AnimGIFs of them, if you
      really want the motion.  One could probably automate the
      generation and saving of such GIFs, if one were so motivated.

      However, I still believe that the only PROPER way to demo these
      display modes is to give them the full screen.  That's the way
      they were designed, and that's the way they will normally be seen.

      I contend that the only reason you want this small-window demo is
      that "Microsoft does it that way" and your tail-light-chasing
      won't let you see that the Microsoft way is fundamentally flawed.

   6: The crapplet's design forces you to select one and only one
      display mode, and run that.  That goes completely against the 
      design and intent of xscreensaver, which is to present a
      constantly-changing *variety* of eye candy.  Sure, some weirdo
      might actually only like *one* of the hundreds of included hacks;
      but more likely, they like some and not others.  That's why 
      xscreensaver-demo gives you easy checkboxes to enable the ones
      you like and disable the ones you don't.

   7: It is Just Plain Wrong that the configurator for xscreensaver
      does not come *with* xscreensaver.  There should be one and only
      one configurator, and it should be included in the xscreensaver
      package.

I've been trying to reach a resolution on this for roughly the last two
years.  So far, I've had lots of discussions about it with lots of
people, and none of them have ever been able to tell me who ACTUALLY has
the power to make any decisions about this!  So it's great that
so-and-so has some suggestions for how to improve xscreensaver-demo, but
what I REALLY want to know is, what changes do I have to make to
xscreensaver-demo to get someone in *authority* to be happy enough with
it that I can kill off the crapplet once and for all.

So far, these are the complaints I've heard from GNOMErs about the
xscreensaver-demo program/crapplet:

  - "The UI sucks."  Usually the criticism ends there.  Well, that
    doesn't help me much.  I don't think the UI sucks; I actually 
    think it's pretty straightforward.  If you think there's something
    wrong with it, please make a suggestion for how it could be better.

  - "I'm used to seeing a tiny-window demo."  I've already covered why
    I think that's a bad idea.  HOWEVER, if adding a tiny-window demo
    to xscreensaver-demo is the only thing left that is preventing you
    from shipping xscreensaver-demo instead of your crapplet, I will
    GLADLY concede this point, and add a tiny-window kludge to 
    xscreensaver-demo.  I think it's a *bad* idea, and I'd really
    rather not, but I also *really* want there to be only one version
    of the configuration UI, so if this is what it takes, I'll bow to
    the pressure.

  - "Command lines are evil, that command-line editor shouldn't be
    there."  Frankly, I never use it.  If it would smooth ruffled
    feathers, I'll take it out, or move it to an "expert users" tab
    or something.

  - "That `Visual' list is confusing."  Sorry, it needs to be there.
    Systems that have multiple visuals can't be made to work right 
    without it.  It's a misfeature of X that users have to know about
    such things, but the sad fact is that they do.  But again, if this
    is a sticking point, I'll hide it elsewhere.

  - "The documentation button runs man in xterm!  Eeew!"   Wrong.
    It only does that on systems that don't have gnome-help-browser
    installed.  Normally, it displays documentation the same way other
    GNOME programs do.

  - "There should be a configuration dialog for each hack, that lets
    you set all of the options that can be controlled through command-
    line switches."

    This would be a nice thing.  It's true that the crapplet has such
    a thing.  However, the last time I looked, it was pretty useless,
    since it only had hack-specific knowledge of a small number of
    them; for most, it only let you set "delay" and simple things like
    that.

    Another point I would make here is that it's probably more useful
    for more people to add a number of interesting presets, than to
    make them diddle sliders.  For example, the default .xscreensaver
    file contains things like "Ripples (Oily)" and "Ripples (Stir)"
    that encapsulate different settings for a single program.  Most
    users will find that easier and more useful.

    That said, I *would* like xscreensaver-demo to have a per-hack
    configuration UI.  It would have been great if someone from the 
    GNOME side of things had put some time into contributing such a
    thing to xscreensaver-demo, rather than spending that time 
    rewriting the already-existing parts of xscreensaver-demo from
    scratch.

If you have any other criticisms of the xscreensaver-demo UI, I would
love to hear them.  But please be specific.  And please make sure you
have looked at the latest version first (3.33 or later) since I've been
improving it regularly.

The bottom line is, I want to find out what I need to do to make there
be only one xscreensaver configuration UI, and to make that UI be
included with the xscreensaver package, instead of elsewhere.

It will be a hard sell for you to convince me that the one-and-only UI
should be based on another code base than xscreensaver-demo; however, if
you have an argument in favor of that, you're welcome to try and
convince me.

I want to reach concensus on what features/changes xscreensaver-demo
must have before you will ship it with GNOME instead of the crapplet.
I'm willing to do a lot of hacking to make this happen, but I'm not
willing to keep chasing a moving target like I have been so far.  
I want to know specifically what I need to do to reach the goal, or
I'm not going to waste my time working on it.  That means I need to
hear from someone with decision-making authority: I need them to say
to me, "if you make these changes, then I will consider
xscreensaver-demo to be superior to the existing crapplet, and will
ship it with the next release."

So please, tell me who that person is.  And then get that person to
negotiate that list with me, so that we can stop fighting about this
once and for all.

My expectation is that this thread will fizzle after a few messages
picking on tangential side points and little details, and we'll be back
where we were before: with GNOME shipping their own thing because they
not-invented-here-itis runs too deep.  I hope that this time, my
expectation is wrong.  But there are years of precedent to support it.

Frankly, my life would be easier and more pleasant if GNOME had never
shipped xscreensaver at all.

-- 
Jamie Zawinski
jwz jwz org             http://www.jwz.org/
jwz dnalounge com       http://www.dnalounge.com/