andrew@erm.oz (Andrew Hunt) (09/06/90)
Dear net I am trying to get a serious image processing application, ER Mapper, running under Openwindows 2.0 (beta) and cannot get the window manager to behave in a sensible way with respect to colormaps. Whenever the cursor is moved over the workspace area, the default colormap is re-installed by the window manager (olwm). This behavior makes it all but impossible to run a serious image processing application under Openwindows. The only time the right colormap is installed is when the cursor is actually over one of the application's windows. What I want the window manager to do is to leave my application's color map installed when the cursor is moved onto the workspace. Motif Window Manager (mwm) seems to do this just fine, but I can't get olwm to behave in this way. The following solutions have been tryed: 1. XSetWindowColormap( dpy, XtWindowOfObject(toplevel), my_map); Results in my_map being installed when the cursor is moved into the toplevel window of my client, the window manager re-installs the default colormap when I move out onto the workspace. 2. XSetWindowColormap( dpy, RootWindowOfScreen(screen), my_map); Does not work with Openwindows 2.0 (beta), used to work with Openwindows 1.0 3. XInstallColormap( dpy, my_map); Pre-X11R3 antisocial behavior, works with olwm, but when cursor is moved over decorations or workspace, default colormap is re-installed by olwm. 4. Modification of olwm source to provide the desired behavior. Has been done successfully. Is not desirable because the version of olwm shipped with Openwindows has some postscript extensions which are not part of the public domain version. The patched version of olwm core dumps on .olwmmenu files with the postscript extensions in them. Also providing a patched version of olwm is a bad solution because it has to be maintained and kept in sync with changes to the Openwindows version. Has anyone got any ideas as to how to solve or work around this problem. Thanks in advance Andrew Hunt -- Earth Resource Mapping, 316 Churchill Avenue, Subiaco, Western Australia 6008 Phone: +61 9 388 2900 Fax: +61 9 388 2901 ACSnet: andrew@erm.oz
smarks@trantor.Eng.Sun.COM (Stuart Marks) (09/07/90)
|> I am trying to get a serious image processing application, ER Mapper, |> running under Openwindows 2.0 (beta) and cannot get the window |> manager to behave in a sensible way with respect to colormaps. The solution is to get the final release of OpenWindows 2.0. The version of olwm in that release has a more flexible colormap installation policy. I believe it will satisfy your needs. You can also get this version of olwm from the contrib area on expo. It's included with the XView 2.0 distribution. s'marks -- Stuart W. Marks ARPA: smarks@eng.sun.com Window Systems Group UUCP: sun!smarks Sun Microsystems, Inc.
cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (09/07/90)
Andrew Hunt writes: >Whenever the cursor is moved over the workspace area, the default colormap >is re-installed by the window manager (olwm). > >This behavior makes it all but impossible to run a serious image processing >application under Openwindows. The only time the right colormap is >installed is when the cursor is actually over one of the application's >windows. > >What I want the window manager to do is to leave my application's color >map installed when the cursor is moved onto the workspace. Motif >Window Manager (mwm) seems to do this just fine, but I can't get olwm >to behave in this way. I run an image processing application under OpenWindows quite a bit of the time and I find it quite reasonable that it behaves in the way it does. I also seem to recall that twm behaves in the same way. The rationale for this is presumably that other windows (and all of the window decoration) may become invisible or indistinct while your image colormap is installed and that you want to be able to see the other windows when you aren't expressing an interest in your image (by placing your cursor there). If you really want the colormap to stay installed as you leave the window, I think that you should be able to get the required behaviour by setting the input area to click select in the workspace properties menu.
golding@saturn.ucsc.edu (Richard A. Golding) (09/11/90)
In article <9009062103.AA03202@zia.aoc.nrao.edu> cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) writes: > >Andrew Hunt writes: > >>Whenever the cursor is moved over the workspace area, the default colormap >>is re-installed by the window manager (olwm). >> >>This behavior makes it all but impossible to run a serious image processing >>application under Openwindows. The only time the right colormap is >>installed is when the cursor is actually over one of the application's >>windows. >> >>What I want the window manager to do is to leave my application's color >>map installed when the cursor is moved onto the workspace. Motif >>Window Manager (mwm) seems to do this just fine, but I can't get olwm >>to behave in this way. > >If you really want the colormap to stay installed as you leave the window, >I think that you should be able to get the required behaviour by setting >the input area to click select in the workspace properties menu. The way to lock the colormap for a particular window using OLWM is to press the colormap lock key with the pointer over the window whose colormap you want to use. The default key sequence for this is Control+L2 (for those with Sun keyboards). The window will retain the "color focus" for as long as it exists, or until you lock in another window's colormap, or you unlock the colormap by pressing the color unlock key (Control+L4 by default.) The resources used to control colormaps are: OpenWindows.ColorLockKey (default "Control L2") is the key sequence to lock in a window's colormap. OpenWindows.ColorUnlockKey (default "Control L4") is the key sequence to unlock the colormap. OpenWindows.ColorFocusLocked (default "False") allows you to set OLWM to run in an mwm-like way. I don't use this option, so I don't recall exactly what it does. -richard -- ----------- Richard A. Golding, HP Labs (internship), golding@cello.hpl.hp.com UC Santa Cruz CIS Board (grad student), golding@cis.ucsc.edu and on leave from Crucible (work) {uunet|ucscc}!cruc!golding