kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (04/20/89)
> Normally, one would expect the foreground and background colors to be > reversed. yet this isn't quite that simple. Nope, but it is pretty close. If reverse video is specified by the user the the values of XtDefaultForground and XtDefaultBackground are swapped. Thus anything that uses these as their default colores will effectively have the foreground and background colors swapped. Without reverse video specified: XtDefaultForeground = "white" XtDefaultBackground = "black" With reverse video specified: XtDefaultForeground = "black" XtDefaultBackground = "white" > { XtNforeground, XtCForeground, XtRPixel, sizeof(Pixel), > XtOffset(widget.foreground), XtRString, XtDefaultForeground}, > ... > > I have no idea what the foreground color defaults to... It defaults to "white: when -rv is specified, otherwise to "black". The use can override by specifying something like: test*foreground: blue > if (widget.reverseVideo) > widget.foreground = !widget->core.background_pixel; > This is the only way I'm guaranteed that the two colors will be > different and that it'll work on both color and monochrome (altho the > results will probably be incorrect for color servers). Gaak. This is really gross. Don't do this you will get random colors on a color workstation. > Now, let's complicate things a little... > My app-defaults file says: > > *foreground: green > *background: blue > Yet the user invokes the program with the -rv flag expecting his > foreground to be blue and background to be green. What happens now? you should actually use: *Foreground: green *Background: blue There are programs that set colors that are not named foreground and background but have class Foreground or Background. The color of the hands on xclock is a good example. Anyway in answer to your initial question. The user will get the color green for all resources named foreground and blue for all resources named background. This will happen reguardless of whether reverse video is specified. The attitude that the toolkit has taken is that reverse video is overrided by explict color specifications. So if you specify colors then reverse video ceases to have any meaning. Chris D. Peterson MIT X Consortium
asente@decwrl.dec.com (Paul Asente) (04/20/89)
In article <12671@pasteur.Berkeley.EDU> dheller@cory.Berkeley.EDU (Dan Heller) writes: >The question is: what exactly is supposed to happen when the -rv option >is specified on the command line (or the reverseVideo resource is set to >"on")? In the toolkit, specifying reverse video means that the pixel values for XtDefaultForeground and XtDefaultBackground are swapped. No more, no less. >My app-defaults file says: > >*foreground: green >*background: blue > >Yet the user invokes the program with the -rv flag expecting his >foreground to be blue and background to be green. What happens now? Things aren't quite that simple. While the toolkit knows about backgrounds, it has no notion of foreground (many widgets don't even have a foreground). This may have been a mistake, but we're stuck with it now. A widget may have more than one "foreground" color (say, if it draws both text and graphics) and it may have none. If you've specified foreground and background like you did there, it might make sense to swap them, but what if the colors are different for each widget? I use five different colors in my mail handling window; what does it mean to specify reverse video for it? -rv is supposed to be a simple convenience for people who don't specify colors explicitly. If you want to achieve the kind of effect you specified, you can change the screen's BlackPixel and WhitePixel at server invocation time (and maybe later -- SGN implies on page thirteen that they can be set but provides no method for actually doing it). -paul asente asente@decwrl.dec.com decwrl!asente