Subject: FVWM: Window `outlines' on placement and resize

From: Baba Z Buehler <[email-masked]>
Date: Tue, 28 Jan 1997 22:33:01 -0600

I just upgraded from 2.0.43 to 2.0.45 and I've got a small problem.  I can no
longer see the `outlines' of the windows that come up during placement and
while resizing.

Is there something I may have set wrong in the .rc file?

Thanks,
--
# Baba Z Buehler - 'Hackito Ergo Sum'
# Beckman Institute Systems Services, Urbana Illinois
#
#  "My mind is my own church." -- Thomas Paine
#
# PGP public key on WWW homepage and key servers (key id: C13D8EE1)
# WWW: http://www.beckman.uiuc.edu/~baba/
--
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: Andrew Veliath <[email-masked]>
Date: Wed, 29 Jan 1997 01:07:18 -0500

>>>>> Baba Z Buehler writes:

    Baba> I just upgraded from 2.0.43 to 2.0.45 and I've got a small
    Baba> problem.  I can no longer see the `outlines' of the windows
    Baba> that come up during placement and while resizing.

    Baba> Is there something I may have set wrong in the .rc file?

See XORValue.  I guess you're running a TrueColor visual?

Andrew

---

From: "Brandon M. Browning" <[email-masked]>
Date: Tue, 28 Jan 1997 21:23:30 -0800

> Is there something I may have set wrong in the .rc file?

No, not necessarily.  I had the same problem (can't remember which
platform I was on at the time, but I think it was BSD/OS) and I solved
it by using "XORvalue 255" in my .fvwm2rc file.  I just looked at my
Linux box (which I'm on now) and it shows the bands, but I don't have
XORvalue set.  Something happened somewhere, but it hasn't affected
everyone or everything, evidently.

I believe it happened in 2.0.44 initially.

-- 
Brandon M. Browning  -Powered by Linux 2 & NetBSD-  Powertie Software

Dementia is similar to creativity but without the expense of art
supplies.
      -- Dogbert, "Dogbert's Top Secret Management Handbook"
--
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: Andrew Veliath <[email-masked]>
Date: Wed, 29 Jan 1997 11:18:36 -0500

>>>>> Brandon M Browning writes:

    >> I just upgraded from 2.0.43 to 2.0.45 and I've got a small
    >> problem.  I can no longer see the `outlines' of the windows
    >> that come up during placement and while resizing.
    >> 

    Brandon> No, not necessarily.  I had the same problem (can't
    Brandon> remember which platform I was on at the time, but I think
    Brandon> it was BSD/OS) and I solved it by using "XORvalue 255" in
    Brandon> my .fvwm2rc file.  I just looked at my Linux box (which
    Brandon> I'm on now) and it shows the bands, but I don't have
    Brandon> XORvalue set.  Something happened somewhere, but it
    Brandon> hasn't affected everyone or everything, evidently.

I believe Chuck changed the default value for XORValue.

The reason why some people have this problem is that it will most
likely give you the correct behavior on PseudoColor visuals, while it
will it will probably give you incorrect results on a TrueColor
visual, since for PseudoColor it works on the colormap entries while
for TrueColor it works on the color bits so you need to give it a
pretty high number (I use XORValue 65535, mostly 1s).

--
Andrew Veliath <[email-masked]>        http://www.rpi.edu/~veliaa
I'm not scared of anything because I'm scared of everything.
Finger for PGP Public Key
Key fingerprint =  51 56 5D 3E 51 43 8B 74  7C B2 E4 B6 84 8E 8B 08
--
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: "Eddy J. Gurney" <[email-masked]>
Date: Wed, 29 Jan 1997 12:59:53 -0500

> pretty high number (I use XORValue 65535, mostly 1s).

If you use M4 preprocessing (and you should! :-) then use this handy macro.
It works for me on our Sun's, some of which have multiple heads, each
at different bits-per-pixel:

# XORValue -- this is the value that bits are XOR'd with when rubberbanding.
# If we have an 8-bit display, use 1, otherwise use 255. The default is '1',
# but it doesn't work well on deeper displays.
m4_ifelse(PLANES,`8',`
XORValue        1',`
XORValue        255')

Since fvwm2 starts a copy of itself for each display (which I think is
terribly wasteful of system resources; other window managers [vtwm, ctwm]
don't do this... and it is not just fvwm which gets spawned twice...
its FvwmAuto, FvwmButtons, FvwmIconMan, etc... yuck.) and parses the
.fvwm2rc for each display, this works great.

Obviously if those XORValues don't work for you (or you don't like them) you
can change them.

While I'm writing:

I *CANNOT* get the Decor-switching pop-up menu to work that lar3ry gensch
submitted (in the "decor_examples" file in fvwm-2.0.45, in sample.fvwmrc).
I tried it yesterday, and if I include a line like

Style "*"	UseDecor Mwm

It works fine. But if I try to use the "decor switching" routines, fvwm
2.0.45 gets totally confused, placing the left, bottom and right handles
all in the upper left hand corner of the border, and completely locking
up the machine if you window shade a window in that state. Doesn't make
me feel to good.

Finally, am I missing something, or is adding buttons to the title bar 
much more difficult in 2.0.45? I used to be able to add a line like
this:

ButtonStyle 6 12 50x10@1 25x35@1 40x35@1 40x60@1 25x60@1 50x85@1 75x60@0 60x60@0 60x35@0 75x35@0 50x10@0 50x10@1

to my .fvwm2rc file and it would appear in the title bar. But now, it is
happily ignored. I've tried resetting the button style, reset button 1 2
and 4, defining buttons 1 2 and 4, adding the 'vector' keyword, adding
'Style "*" Button 6', etc. all to no avail. How do you add a button to the
title bar if that is all you want to do?

Eddy

P.S. FvwmScript (in the 'extras' directory) blows away the FvwmForm module
     in terms of capability (at the expense of requiring an external 'script'
     file instead of being able to include it in your .fvwm2rc file). I have
     been using FvwmScript for about a week now, and have made about 7 or 8
     changes to the source, including upping the maximum number of widgets 
     from 30 to 100 to accomodate some dialog boxes I am working on. The 
     language is a little tedious, but it works great. I really should send
     the changes in to the author so I can distribute my scripts... also, 
     we should consider having the name changed from FvwmScript to FvwmDialog,
     which in my opinion is a much better name. :-)
--
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: Andrew Veliath <[email-masked]>
Date: Wed, 29 Jan 1997 13:44:49 -0500

>>>>> Eddy J Gurney writes:

    Eddy> While I'm writing:

    Eddy> I *CANNOT* get the Decor-switching pop-up menu to work that
    Eddy> lar3ry gensch submitted (in the "decor_examples" file in
    Eddy> fvwm-2.0.45, in sample.fvwmrc).  I tried it yesterday, and
    Eddy> if I include a line like

    Eddy> Style "*" UseDecor Mwm

    Eddy> It works fine. But if I try to use the "decor switching"
    Eddy> routines, fvwm 2.0.45 gets totally confused, placing the
    Eddy> left, bottom and right handles all in the upper left hand
    Eddy> corner of the border, and completely locking up the machine
    Eddy> if you window shade a window in that state. Doesn't make me
    Eddy> feel to good.

I just tried this and have the same problem switching, although
shading the window just destroys the window instead.  It doesn't seem
to be related to the decor code (I think; decors just specify what is
drawn around the window, not where to draw them or having anything to
do with events).  My own decors I use work fine; but I must say this
particular example should probably be changed or removed.

---

From: Andrew Veliath <[email-masked]>
Date: Wed, 29 Jan 1997 13:51:08 -0500

>>>>> Eddy J Gurney writes:

    Eddy> title bar much more difficult in 2.0.45? I used to be able
    Eddy> to add a line like this:

    Eddy> ButtonStyle 6 12 50x10@1 25x35@1 40x35@1 40x60@1 25x60@1
    Eddy> 50x85@1 75x60@0 60x60@0 60x35@0 75x35@0 50x10@0 50x10@1

I don't think I've ever been able to add a button like this.  I always
had to define a mouse binding to get the button to appear (at least in
my experience).

---

From: Baba Z Buehler <[email-masked]>
Date: Wed, 29 Jan 1997 13:52:27 -0600

> See XORValue.  I guess you're running a TrueColor visual?

Yes... TrueColor... setting XORValue worked.  Makes sense now that I know what
its doing.

Thanks,
#  "He who can take no great interest in what is small
#   will take false interest in what is great." -- John Ruskin

---

From: [email-masked]
Date: Wed, 29 Jan 1997 16:02:01 -0500

> From: "Eddy J. Gurney" <[email-masked]>
> Date: Wed, 29 Jan 1997 12:59:53 -0500
> References: <[email-masked]>
> Sender: [email-masked]
> 

I have found that XOR must be larger than 255 for my 16 plane display.

# Value to be XORed when creating a rubber band.  This is set by trial
# and error.  Apparently 1 is now the default and 255 was previously.
# 1 is horrible on this machine and 255 is almost as bad.
# 2**16-1 was OK, but intermediate powers of two were better.
XORValue 8191

---

From: Stig <[email-masked]>
Date: Wed, 29 Jan 1997 21:04:25 -0800

> > See XORValue.  I guess you're running a TrueColor visual?

Since a bunch of people got zapped by this change, perhaps the defaults
ought to be more DWIM?

    Stig