quasar@krazykat.ctt.bellcore.com (Laurence R. Brothers) (10/04/90)
As far as I can tell, XView panels ignore the Window.Color.Background
resource described in the XView man page. They also ignore the
-Wb and -g command line options.
Setting the background color of the base frame and FRAME_INHERIT_COLORS
using an Xv_singlecolor value has similar nonexistent effect.
The only way I can find to establish a panel color is to install a colormap
segment for the application (via FRAME_INHERIT_COLORS) or for a specific
panel. Unfortunately, this has the (bug) side-effect of mangling any
menus which may pop up for the panel.
All the above methods work fine for foreground colors.
Any suggestions?
And another thing -- isn't it stupid not to be able to make the background
color of a panel item different from the background color of the panel?
Laurence R. Brothers (quasar@bellcore.com)
Bellcore -- Computer Technology Transfer -- Knowledge-Based Systems
"Like dancing oil on a madman's face, reason tends to fly away"cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (10/05/90)
> As far as I can tell, XView panels ignore the Window.Color.Background > resource described in the XView man page. They also ignore the > -Wb and -g command line options. Yes. This is not a bug. XView panels take their background colour from OpenWindows.WindowColor. This is so that they blend in with the window decoration applied by OPEN LOOK window manager. The window decoration and panel backgrounds are lumped together as the "window background" in the OPEN LOOK UI specification (see Chapter 3). Making them different colours would probably make your application non-conforming. Remember that if you want to use XView you are implicitly buying into the OPEN LOOK GUI. > And another thing -- isn't it stupid not to be able to make the background > color of a panel item different from the background color of the panel? Only if you want to do it :-) Although the OPEN LOOK functional spec. says that applications can specify the colours of individual controls (p204) this would cause a few problems in 3D OPEN LOOK implementations: you would actually need three new colours to do this (chosen colour, chosen colour + 10-15% black and chosen colour + 50% black). One possible reading of the functional spec. (but not the most intuitive) is that only the foregrounds of panel items can be changed. If you really want to do this, ask Sun for it; if there is enough demand they will get around to providing it. If you are really desperate for it UTSL. BTW. the OPEN LOOK function spec says that facilities for changing panel item colours should be used sparingly. Chris Flatters.
tomj@snowking.Eng.Sun.COM (Tom Jacobs) (10/05/90)
In article <27508@bellcore.bellcore.com>, quasar@krazykat.ctt.bellcore.com (Laurence R. Brothers) writes: |> As far as I can tell, XView panels ignore the Window.Color.Background |> resource described in the XView man page. They also ignore the |> -Wb and -g command line options. Actually, XView PANEL windows are enforcing the OPEN LOOK 3D color model that says that control areas have the same color as the window borders (resize handles, header, footer, menus, scrollbars, buttons, sliders, etc). You can change the color of other windows though... try: "textedit -bg blue" and you'll see that the textsw changes, but not the control objects. |> Setting the background color of the base frame and FRAME_INHERIT_COLORS |> using an Xv_singlecolor value has similar nonexistent effect. Panels simply ignore this... this is either a blessing (save you from doing something that will break OPEN LOOK compliance) or a bug considering on your views of GUIs, however I think that this type of "help" on the part of the toolkit provide for more consistent applications and environments. |> The only way I can find to establish a panel color is to install a colormap |> segment for the application (via FRAME_INHERIT_COLORS) or for a specific |> panel. Unfortunately, this has the (bug) side-effect of mangling any |> menus which may pop up for the panel. |> |> All the above methods work fine for foreground colors. |> |> Any suggestions? |> |> And another thing -- isn't it stupid not to be able to make the background |> color of a panel item different from the background color of the panel? We've been looking at this issue trying to get clarification from our OPEN LOOK experts... when we get the OK to allow this.. we'll fix it. Personally, I think that changing the background on a button (for example) destroys the consistent model... what you really want to do is change the foreground (outlines) of the button. --Tom Jacobs tomj@Eng.sun.com Sun Microsystems, Inc. ..!sun!tomj
fgreco@donald.GOVt.shearson.COM (Frank Greco) (10/05/90)
> |> And another thing -- isn't it stupid not to be able to make the background > |> color of a panel item different from the background color of the panel? > > We've been looking at this issue trying to get clarification from our > OPEN LOOK experts... when we get the OK to allow this.. we'll fix it. > Personally, I think that changing the background on a button (for example) > destroys the consistent model... what you really want to do is change the > foreground (outlines) of the button. > Invariably when developing an app with XView/devGUIDE, my (human) clients will ask me to change the background color of the button or a panel list so that its different from the panel itself (and of course, every "resource" must be configurable). So I'd like to put my strong vote in to offer this flexibility (different panel item colors) in the OPEN LOOK spec. And, its a given that they also want different fonts for different panel items (e.g., 12 point lucida for buttons, 14 point lucidasanstypewriter for panel lists, 24 point times roman for panel messages). It is really awkward to have separate panels for each...real awkward. I'd like to have a mono-spaced font for the panel list (i.e., to align columns...etc) and proportionally-spaced font for other things for readability. Frank G. BTW, how about TEXTSW's that scroll horizontally?
alan@cogswell.Jpl.Nasa.Gov (Alan S. Mazer) (10/05/90)
In article <9010041702.AA25572@zia.aoc.nrao.edu>, cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) writes: | > As far as I can tell, XView panels ignore the Window.Color.Background | > resource described in the XView man page. They also ignore the | > -Wb and -g command line options. | | Yes. This is not a bug. XView panels take their background colour from | OpenWindows.WindowColor. This is so that they blend in with the window ^^^^^^^^^^^ | decoration applied by OPEN LOOK window manager. Why OpenWindows.WindowColor? What does OpenWindows have to do with anything? Not all XView code is run under OpenWindows, right? -- -- Alan # My aptitude test in high school suggested that ..!ames!elroy!alan # I should become a forest ranger. Take my alan@elroy.jpl.nasa.gov # opinions on computers with a grain of salt.