de5@ornl.gov (Dave Sill) (11/08/90)
Has anyone seen xnews/openwin under SunOS 4.1 get into a funky state wherein menus are no longer drawn correctly? Clicking on the triangle-in-a-square menu do-hicky has no visible effect until the mouse is moved down, then only the rounded menu labels are drawn as the pointer reaches them. Regular openlook windows continue to work normally. Any help would be appreciated. -- Dave Sill (de5@ornl.gov) Martin Marietta Energy Systems Workstation Support
clh@tfic.bc.ca (Chris Hermansen) (11/09/90)
In article <1990Nov8.123120.20324@cs.utk.edu> Dave Sill <de5@ornl.gov> writes: >Has anyone seen xnews/openwin under SunOS 4.1 get into >a funky state wherein menus are no longer drawn correctly? No, but I have two other funky states: window borders or decoration ('scuze me if my terminology sucks) get damaged in a session of FRONT/BACK and little parts go missing; sometimes when I click/drag on an icon/window, another icon/window moves as well (damn! if only I could get Twil*t Z*ne music in here) [stuff deleted] > >Regular openlook windows continue to work normally. ditto > >Any help would be appreciated. ditto Regards, Chris Hermansen Timberline Forest Inventory Consultants Voice: 1 604 733 0731 302 - 958 West 8th Avenue FAX: 1 604 733 0634 Vancouver B.C. CANADA clh@tfic.bc.ca V5Z 1E5 C'est ma facon de parler.
hsu@eng.umd.edu (Dave "bd" Hsu) (11/09/90)
In article <1990Nov9.024505.19308@tfic.bc.ca> clh@tacitus.UUCP (Chris Hermansen) writes: > sometimes when I click/drag on an icon/window, another icon/window > moves as well (damn! if only I could get Twil*t Z*ne music in here) Sounds to me like you're using click-to-type input focus and have just discovered that the middle-button is used to group windows. This is a feature. Left-button is select. -dave -- Dave Hsu Systems Research Center, Building 115 (301) 405 6594 hsu@eng.umd.edu The Maryversity of Uniland, College Park, MD 20742-3311 "Wris woo chin dow fip ak," said one teaching assistant [who could not be reached for comment]. - UW-Madison Badger Herald
toone@Corp.Sun.COM (Nolan C. Toone) (11/09/90)
> sometimes when I click/drag on an icon/window, another icon/window > moves as well (damn! if only I could get Twil*t Z*ne music in here) This is actually a nice but seldom needed feature. If you select once on an icon/window the border highlights. if you then move to another icon/window and click the middle button that border ALSO highlights, you can then move the icons/windows together. if you click the middle button again it is then deselected and they move independly again. (It took me sometime to figure this one out too. and I even use it once in a while :-) ) Regards, /\ \\ \ Nolan C. Toone, Catalyst Tech Support \ \\ / Sun Microsystems / \/ / / MailStop PAL1-316 / / \//\ 2550 Garcia Avenue \//\ / / Mountain View, California 94043 / / /\ / / \\ \ Phone: 415-336-0391 \ \\ EMail: toone@Corp.Sun.Com \/
naughton@wind.Eng.Sun.COM (Patrick Naughton) (11/10/90)
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 can happen by running SunView 1 applications when you do not have the 4.1-GFX patch installed in your kernel. It is this patch which keeps the multiple hardware contexts of the xnews process and the SunView/XGL/pixrect processes coherent. Without this patch it is easy to get the GX confused. (This is fixed in 4.1.1). If you are not using a GX with a non-4.1-GFX kernel... then my advice is misguided. -Patrick In article <1990Nov8.123120.20324@cs.utk.edu>, de5@ornl.gov (Dave Sill) writes: |> Has anyone seen xnews/openwin under SunOS 4.1 get into |> a funky state wherein menus are no longer drawn correctly? |> |> Clicking on the triangle-in-a-square menu do-hicky has no |> visible effect until the mouse is moved down, then only |> the rounded menu labels are drawn as the pointer reaches |> them. |> |> Regular openlook windows continue to work normally. |> |> Any help would be appreciated. |> |> -- |> Dave Sill (de5@ornl.gov) |> Martin Marietta Energy Systems |> Workstation Support -- ______________________________________________________________________ Patrick J. Naughton ARPA: naughton@sun.com Windows and Graphics Group UUCP: ...!sun!naughton Sun Microsystems, Inc. AT&T: (415) 336 - 1080
smith%mito@endor.harvard.edu (Steven Smith) (11/11/90)
In article <1990Nov9.172649@wind.Eng.Sun.COM>, naughton@wind.eng.sun.com (Patrick Naughton) writes: >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. ... >In article <1990Nov8.123120.20324@cs.utk.edu>, de5@ornl.gov (Dave Sill) writes: >|> Has anyone seen xnews/openwin under SunOS 4.1 get into >|> a funky state wherein menus are no longer drawn correctly? >|> >|> Clicking on the triangle-in-a-square menu do-hicky has no >|> visible effect until the mouse is moved down, then only >|> the rounded menu labels are drawn as the pointer reaches >|> them. 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. Steve Smith Harvard Genome Lab smith@nucleus.harvard.edu
chrise@atc.boeing.com (11/12/90)
This thread originally started in the OpenLook mailing list, but since it is relevant to Epoch, I thought I would cross-mail it. Someone in that list wrote in that when he selected one window via a left-mouse and then middle-moused on another window, both windows would move when he tried to move either: >>sometimes when I click/drag on an icon/window, another icon/window >>moves as well (damn! if only I could get Twil*t Z*ne music in here) And Nolan Toone from Sun wrote back: >This is actually a nice but seldom needed feature. I agree it is a nice feature, but I would use it more if grouping windows allowed you to do more than move them. For example, I would dearly love to be able to group windows (the Epoch minibuffer and an Epoch screen, for example) and then open and close them as a single unit, rather than individually. Is there any way to do this? Thanks, Chris Esposito (chrise@atc.boeing.com)
crl@sanctum.East.Sun.COM (Charles LaBrec) (11/12/90)
In article <1990Nov9.172649@wind.Eng.Sun.COM> naughton@wind.Eng.Sun.COM (Patrick Naughton) writes: > > 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. 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. -- Charles LaBrec Sun Professional Services Albany, NY
naughton@wind.Eng.Sun.COM (Patrick Naughton) (11/13/90)
>>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