Subject: FVWM: Creating and using private colour maps

From: Nick Yates 3513 <[email-masked]>
Date: Fri, 03 Apr 1998 08:27:00 +0000

We are writing an X-based application where we create and use our own private 
colour map.  I have read and understood about the reasons why we will get colour  
flashing on a machine that does not have hardware support for a number of colour 
maps, and we have taken measures to reduce this flashing.

However, I do not understand why we get colour map flashing when changing focus 
between windows in our own application.  Note that our application exclusively 
uses the private colour map and does not reference the default colour map at 
all.  The reason seems to be that when the window manager reparents our windows 
( on a map ) the window manager window references the default colourmap.  
Therefore, when we change focus the window manager installs the default colour 
map to draw its windows, and then installs the private colour map to draw our 
windows.  This leads to the colours flashing when changing focus.  Is there an 
underlying reason why the window manager does not use the colour map of the 
window it is reparenting, or is there some sort of resource we can set so that 
it does ?

Yours faithfully,

Nick Yates.

--
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: [email-masked] (John Beyer)
Date: Fri, 3 Apr 1998 06:26:35 -0500

> Date: Fri, 03 Apr 1998 08:27:00 +0000
> From: Nick Yates 3513 <[email-masked]>
> Subject: FVWM: Creating and using private colour maps
> To: [email-masked]
> 

This problem description sounds like a similar we encountered here 
at Picker a month or two ago.  We don't run our product apps under 
FVWM (only a few enlighted souls have seen the light so far :-), but 
if Nick's situation is indeed the same as ours, the root cause lies 
in X, not FVWM.

A couple of my co-workers investigated this for a few days.  The 
explanatory mail distributed by one of them has a few paragraphs 
which summarize the issues fairly well.  The excerpt:

    <product-specific background omitted>

    ... Xt's support for non-default visuals is not completely transparent.  
    Shell widgets, which determine which visual it and its child widgets come 
    up in, don't seem to intelligently inherit all four of the visual-related 
    resources (visual, depth, colormap, and borderPixmap) from ancestor widgets.  
    Too bad too, because we could then just set this up on the unrealized app 
    shell, and be done with it.  

    X FAQs confirm this odd behavior, and also confirm that to be safe, one
    should explicity set the visual-related resources on all child shells if
    running on a non-default visual is to be supported.

Nick, I hope this is the info for which you're looking.  If not, the "delete" 
option is only a flick of the wrist away.  (C'est la vie.)

Regards,

John Beyer           |  If a schizophrenic threatens to kill himself, is 
                     |  this considered a hostage situation?
[email-masked]  |  
--
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].