Subject: FVWM: Thoughts about default XORValue

From: Martin Trampler <[email-masked]>
Date: Tue, 25 Feb 1997 16:51:19 +0100 (MET)

Hi all,

I've just compiled and installed fvwm-2.0.45 on our Solaris-Server
without any problems. It's getting better with every release !

I experienced the puzzling behaviour that the outlines of windows were
not drawn during resize or move operations on both 16 and 24 bpp
displays. Looking through the mailing list archives I found that the
reason is that the default XORValue for those "rubberbands" was
changed from 255 to 1, giving better results on 8bpp (correct me if
I'm wrong)

I think this is not a good idea: 

The old value was fine (maybe not perfect) for _all_ kinds of
depths. At least it worked. If one of our users found it
insufficiently (nobody ever did) she could have easily set the value
herself. At our site we have the policy to give users a set of
dotfiles with the promise, that they can get their work done if they
leave them as they are. These files are minimal, without bells and
whistles. If users fiddle with them, they're on their own.
With our "minimal" .fvwmrc they can run the WM, if they want to
explore its features they have to RTFM.

I understand that this release is still considered beta, so I can't
rely on backward compatibility. But to change the default for XORValue
means to introduce the necessity to configure another option in
.fvwm(2)rc. My personal point of view is that it should be possible to
provide a _minimal_ "one size fits all"-configuration.

(Btw: Is the system-wide configuration-file still -as the Manpage
says- /.../.fvwmrc ?? I remember a discussion in this group about
changing it to /.../fvwmrc or /.../system.fvwmrc, so it would not be a
hidden file anymore)

Regards

   Martin Trampler

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: alex korobka <[email-masked]>
Date: Thu, 27 Feb 1997 02:06:56 -0500 (EST)

> explore its features they have to RTFM.

  Having experienced a similar problem in Wine we've settled on
  the 

  (WhitePixelOfScreen(screen) ^ BlackPixelOfScreen(screen))

  for GXxor invert. It works as expected in TrueColor and reasonably
  good in PseudoColor. I'd suggest to use this as the default XORValue
  with .fvwmrc entry overriding it if necessary.

Alex