Subject: FVWM: xlock...error or ??

From: [email-masked] (Todd Fries)
Date: Thu, 16 Nov 1995 02:29:48 -0600 (CST)

The situation:

   I run 'xlock -blank' so as to not annoy my rommate when I
   go to bed.  I get a white screen.

The details:

   (relevent portions of files read by .fvwmrc: )

   ColormapFocus FollowsFocus
   Style "*" SloppyFocus

which results in I can have my mouse over, netscape, or xdoom, and move it
away, and the colormap doesn't shift and I don't have to keep the mouse in
the window...

However, when I run xlock, to brin the menu up from the backgorund, momentarily,
the pallette switches from the netscape pallete to the 'normal' "fvwm's" 
colormap, and then back to the netscape colormap as I release the xlock
menuitem, as it should.

However, running 'xlock -install' does not allow 'xlock -install -mode blank'
to show a 'blank, black' screen, instead a palette-shifted blazing white!

Is this the wm or xlock's problem?

-- 
Todd [email-masked]
http://www.cs.umr.edu/~tfries
--
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: <[email-masked]> (Charles Hines)
Date: Thu, 16 Nov 1995 09:51:20 -0500

>>>>> "Todd" == Todd Fries <[email-masked]> writes:

Todd> The situation:
Todd>    I run 'xlock -blank' so as to not annoy my rommate when I
Todd>    go to bed.  I get a white screen.

Todd> The details:

Todd>    (relevent portions of files read by .fvwmrc: )

Todd>    ColormapFocus FollowsFocus
Todd>    Style "*" SloppyFocus

Todd> which results in I can have my mouse over, netscape, or xdoom,
Todd> and move it away, and the colormap doesn't shift and I don't
Todd> have to keep the mouse in the window...

Todd> However, when I run xlock, to brin the menu up from the
Todd> backgorund, momentarily, the pallette switches from the netscape
Todd> pallete to the 'normal' "fvwm's" colormap, and then back to the
Todd> netscape colormap as I release the xlock menuitem, as it should.

Todd> However, running 'xlock -install' does not allow 'xlock -install
Todd> -mode blank' to show a 'blank, black' screen, instead a
Todd> palette-shifted blazing white!

Todd> Is this the wm or xlock's problem?

I believe that it may be a little of both.  For instance, swirl mode
(xlockmore 3.2) installs it's own colormap, which works, but then when
fvwm comes back, The colormap doesn't get restored correctly.  So, I
would assume that passing in -install for blank mode should work this
way as well, but as you see it doesn't.  I'll look into this (adding
it to TO-DO list).

It is getting better though, since swirl mode never really worked w/
fvwm (1.xx) in the past, I believe.

Chuck

---

From: [email-masked] (Robert Nation 885-9815)
Date: Thu, 16 Nov 95 12:41:26 EST

>way as well, but as you see it doesn't.  I'll look into this (adding

my guess is that the screen saver users an override-redirect window.
Somewhere along the line, I added code which made fvwm get sloppy about
colormaps when override-redirect windows were present. This was done
for WABI, which is also override-redirect, and sometimes installs its
own colormap. Most likely, fvwm doesn't notice when the override-redirect
window goes away, so it doesn't restore the colormap correctly (or maybe,
the override-redirect window doesn't go away, it just unmaps or something).

As I recall, the ICCCM doesn't say how to handle colormaps for
override-redirect windows, so I couldn't say what the correct behavior is.

Rob

---

From: <[email-masked]> (Charles Hines)
Date: Thu, 16 Nov 1995 14:38:16 -0500

>>>>> "Rob" == Robert Nation 885-9815 <[email-masked]> writes:

>> way as well, but as you see it doesn't.  I'll look into this (adding

Rob> my guess is that the screen saver users an override-redirect
Rob> window.

Just checked and yes, that's what's happening here.  Makes sense,
since they don't want it to have any borders or titles applied to the
window that obscures the entire display.

Rob> Somewhere along the line, I added code which made fvwm get sloppy
Rob> about colormaps when override-redirect windows were present. This
Rob> was done for WABI, which is also override-redirect, and sometimes
Rob> installs its own colormap.

I remember all that.  I really hate WABI...

Rob> Most likely, fvwm doesn't notice when the override-redirect
Rob> window goes away, so it doesn't restore the colormap correctly
Rob> (or maybe, the override-redirect window doesn't go away, it just
Rob> unmaps or something).

That seems to be the case.

Rob> As I recall, the ICCCM doesn't say how to handle colormaps for
Rob> override-redirect windows, so I couldn't say what the correct
Rob> behavior is.

I just looked real quick at the ICCCM 2.0 and didn't see any
references to override-redirect at all.  I'll take a closer look
later.

Perhaps a global option that means "I'll be using WABI" might be in
order, to account for this, and only do the "sloppyness" if it's set.

Chuck