Re: FVWM: Creating and using private colour maps

From: John Beyer <beyer_at_ct.picker.com>
Date: Fri, 3 Apr 1998 06:26:35 -0500

> Date: Fri, 03 Apr 1998 08:27:00 +0000
> From: Nick Yates 3513 <nick.yates_at_baesema.co.uk>
> Subject: FVWM: Creating and using private colour maps
> To: fvwm_at_hpc.uh.edu
>
> 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.

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?
beyer_at_ct.picker.com |
--
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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Fri Apr 03 1998 - 05:30:52 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:38:01 BST