gordonc@aifh.ed.ac.uk (Gordon Cameron (RA DAI)) (05/28/91)
I would greatly appreciate it if somebody could help with this problem, as it has caused much grief ! I have a base application which in turn executes (in turn) a number of Xview applications. Each of these applications uses its own (statically allocated) palette, and it is here that the problem arises... The palettes used by the sub-tools are fairly large, but since no two of the subtools can be in use at the same time - this is OK. However, when I finish using one tool, and wish to move on to the next, I want the server to 'forget' about the colourmap, that it allocated for the tool that I just destroyed, and allocate the NEW colurmap for the NEW tool, as if it were the first application. (What happens just now, is that the first sub-tool to execute, 'steals' the colourmap for itself, and all subsequent tools to run cause the server to swap colours in and out, causing a bad flicker) When the top-level driving application exits, everything reverts to normal... Can anybody help !! - I suspect that the problem occurs becuase the main application registers as ONE client - I'm not sure.. Any help would be gratefully received, Gordon Cameron, Dept. of A.I., University of Edinburgh, Edinburgh, Scotland. e-mail : gordonc@uk.ac.ed.aifh
openlook-request@openlook (05/29/91)
> I have a base application which in turn executes (in turn) a number > of Xview applications. Each of these applications uses its own > (statically allocated) palette, and it is here that the problem > arises... If you're using olwm/olvwm, here's a section from the man page that might help: In color-locked mode, colormaps are not installed based on pointer motion. To enter color-locked mode, press the Color-Lock key over the window whose colormap you wish to install. When you press this key, the colormap of the eli- gible window under the pointer is installed into the hardware. You can move the pointer anywhere on the screen and this colormap will remain installed in the hardware. If you're already in color-locked mode, you can press the Color-Lock key over another window to install that window's colormap. Also... ColorFocusLocked (boolean) Specifies the initial state of the colormap focus pol- icy. If true, the default colormap is locked into the hardware. If false, the colormap of the window under the mouse is kept installed. Default value: false. ColorLockKey (key specification) Specifies the key that is used to lock the colormap focus. See the section on Colormap Installation for more details. Default: control-L2. ColorUnlockKey (key specification) Specifies the key that is used to unlock the colormap focus. See the section on Colormap Installation for more details. Default: control-L4. Hope this helps, Frank G.
doug@crdgw1.ge.com (Doug Becker) (05/30/91)
> I have a base application which in turn executes (in turn) a number > of Xview applications. Each of these applications uses its own > (statically allocated) palette, and it is here that the problem > arises... If you're using olwm/olvwm, here's a section from the man page that might help: I don't think you answered the original poster's question (which I read as, "Why isn't xv_destroy really destroying my application's colormap?"). I also ran into this problem some months ago, but didn't (and don't) have the time to investigate it. (I worked around it by reusing the existing colormap rather than cyclically creating and destroying Cmses.) My app created a 128-entry read-write colormap, destroyed it, then created a new one. XView apparently thought that the old (destroyed) segment was still in use, and forced my second Cms' color cells out of the default colormap on our 8-bit (PseudoColor) displays. Because of several other peculiarities I've observed, I have a hunch that this problem stems from xv_destroy not destroying things properly. I'd be interested in hearing about any acknowledgments of or fixes to this problem. -- Doug Becker doug@nmri.ge.com crdgw1!sane!doug