Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!newstop!exodus!wind.Eng.Sun.COM
From: naughton@wind.Eng.Sun.COM (Patrick Naughton)
Newsgroups: comp.windows.open-look
Subject: Re: Hosed xnews menus under Open Windows
Message-ID: <1990Nov12.104756@wind.Eng.Sun.COM>
Date: 12 Nov 90 18:47:56 GMT
References: <8lcz7lv@openlook.Unify.Com>
Sender: news@exodus.Eng.Sun.COM
Reply-To: naughton@wind.Eng.Sun.COM (Patrick Naughton)
Organization: Sun Microsystems, Inc. - Mountain View, CA
Lines: 61

>>I wrote:
>
>   Other followups to this message were referring to unrelated
>   problems...  It sounds like you are on a GX and you have run some other
>   program which directly accessed the framebuffer.  X11/NeWS is confused
>   about the state of the GX hardware registers since it assumes that it
>   will be the only one to leave state in the hardware.

This was the problem the original poster was seeing.

|>>smith%mito@endor.harvard.edu (Steven Smith) writes:
|>
|> I have seen this problem as well.  It is not dependent on GX equipped
|> machines, but does seem to be a problem with COLOR!  I have an application
|> which uses a CMS Canvas, and when the CMS is set, scrollbar menus
|> demonstrate this problem.  However, when I use a monochrome canvas,
|> all is well.  The problem also arises in the drawing of the scrollbars, as
|> they do not use the proper "background" color so that they blend in with the
|> frame.  If color is disabled, the problem does not occur.  If  setting the
|> depth of the canvas is delayed until after the scrollbars are created
|> (a no-no) all is well until a split view is performed, at which time the NEW
|> scrollbar, and scrollbar menu have the display problem.  Eventually, the
|> menu problem causes the program to crash (at least my program) after a few
|> splits, and joins.
|> 
|> I have a piece of code which demonstrates the problem, and I would be happy
|> to give it to anyone (from SUN?) who is interested.

This is an entirely different problem.  The menu always paints
correctly, it just has the wrong colors in its colormap, that is
because the canvas which owns the menu did not have its
CMS_CONTROL_COLORS set up properly.

|>>crl@sanctum.East.Sun.COM (Charles LaBrec) writes:
|> On 4.0.3, I've not seen many problems like this on a GX.  However, I
|> see it all the time on a bwtwo.  I believe it happens most often after
|> running a SunView application.  Often, the pane border (the thin black
|> line surrounding the tty subwindow) in shell/cmdtools disappears and
|> refuses to come back even with after a redisplay or close/open of the
|> window.  I don't believe that the GFX software changes this behavior,
|> but I'm not sure about this since some systems at my customer site
|> have it installed, and some don't.

This also is an entirely different problem.  X11 borders do not get
repainted on retained windows since there is no explicit way for the
client to paint in the border area.  It is up to the server to paint
the borders.  What happens here is the SunView application paints
garbage into the border area and that garbage gets copied into the
retained raster for the window and restored each time you say "Refresh
All".  The only way to tell the server to "really paint the border" is
to resize the window.

I hope this clears up *some* of the confusion...

-Patrick

--
    ______________________________________________________________________
    Patrick J. Naughton				    ARPA: naughton@sun.com
    Windows and Graphics Group			    UUCP: ...!sun!naughton
    Sun Microsystems, Inc.			    AT&T: (415) 336 - 1080