mikey@eukanuba.wpd.sgi.com (Mike Yang) (06/27/90)
In article <JYM.90Jun25204254@eris.berkeley.edu>, jym@eris.berkeley.edu (Jym Dyer) writes: |> |T|here's a different problem, which may not be related, but |> `-' again, it happens only with DECW$WINMGR, not with HPWM. |> I compiled xsetroot and the Xmu stuff. Then I ran xsetroot |> to put a bitmap in my background. Under HPWM it shows up |> right away; but under DECW$WINMGR it only shows up after I |> lift a window off of the background. Does *that* one sound |> familiar to anyone? The problem is that the DEC window manager places a full-screen, pseudo-root window over the real root window. This pseudo-root window has background set to ParentRelative, but it doesn't automatically change when xsetroot changes the real root window's background. The solution is to use xrefresh after using xsetroot. ---------------------------------------------------------------------- Mike Yang Silicon Graphics, Inc. mikey@wpd.sgi.com 415/335-1786 decwrl!sgi!wpd!mikey
west@gsrc.dec.com (Jim West (Stealth Contractor)) (06/27/90)
In article <9518@odin.corp.sgi.com>, mikey@eukanuba.wpd.sgi.com (Mike Yang) writes... -The problem is that the DEC window manager places a full-screen, -pseudo-root window over the real root window. This pseudo-root window -has background set to ParentRelative, but it doesn't automatically -change when xsetroot changes the real root window's background. - -The solution is to use xrefresh after using xsetroot. - There is another solution. You could check for the existence of the DEC window manager psuedo-root and then use it in your programs. What follows is an Ada procedure that will 'look' for this window. function get_wm_root ( display : in x.display_type) return x.window_id_type is screen : x.screen_id_type; root : x.window_id_type; wm_root : x.window_id_type; rootatt : x.window_attributes_type; childatt : x.window_attributes_type; children_addr : address; children : child_array_type; num_children : integer; begin x.default_screen ( result => screen, display => display); x.root_window ( result => root, display => display, screen_number => screen); x.get_window_attributes ( status => status, display => display, window_id => root, window_attributes_return => rootatt); x.query_tree ( status => status, display => display, window_id => root, children_return => children_addr, num_children_return => num_children); if num_children > 0 then children := addr_to_array (a => children_addr); x.free (buff_ptr => children_addr); for i in 0 .. num_children - 1 loop x.get_window_attributes ( status => status, display => display, window_id => children(i), window_attributes_return => childatt); if rootatt.wdat_width = childatt.wdat_width and rootatt.wdat_height = childatt.wdat_height then x.query_tree ( status => status, display => display, window_id => children(i), children_return => children_addr, num_children_return => num_children); if num_children > 0 then -- It had better be !! children := addr_to_array (a => children_addr); x.free (buff_ptr => children_addr); return children(0); end if; end if; end loop; return zero; -- No window manager (DEC's) end if; end get_wm_root; ---------------------------------------------------------------------- Jim West | The Schainker Converse west@gsrc.dec.com | to Hoare's Law : | These are my opinions. | Inside every small problem Digital has no idea | is a larger problem struggling what I'm saying. | to get out. ----------------------------------------------------------------------
toml@ninja.Solbourne.COM (Tom LaStrange) (06/28/90)
|> -The problem is that the DEC window manager places a full-screen, |> -pseudo-root window over the real root window. This pseudo-root window |> -has background set to ParentRelative, but it doesn't automatically |> -change when xsetroot changes the real root window's background. |> |> There is another solution. You could check for the existence of the DEC |> window manager psuedo-root and then use it in your programs. What follows |> is an Ada procedure that will 'look' for this window. |> This problem also exists for swm users when the Virtual Desktop is enabled. With our next release (very soon now), you will find a C fragment in /usr/lib/X11/swm/vdt.c that will return the actual root window or the Virtual Desktop window if swm is running and the vdt is enabled. For you swm users out there now, I'm including that code fragment here. It's easy to just plug this into xphoon, xsetroot, or any other root window display program and have it do the right thing. -- Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml Longmont, CO 80501 --------------------- vdt.c --------------------------- /*********************************************************************** * * Solbourne Computer, Inc. * Copyright (c) 1990, Solbourne Computer, Inc. USA * All rights reserved. * * vdt.c * * Find the Virtual Desktop window * * 08-Feb-90 Thomas E. LaStrange File created * ***********************************************************************/ #include <X11/Xlib.h> #include <X11/Xutil.h> #include <X11/Xatom.h> /*********************************************************************** * * Procedure: * FindVirtualDesktop * * Arguments: * dpy - Display pointer * * Returns: * Window - the Virtual Desktop window or the actual root window * * Function: * This routine will look for the swm Virtual Desktop window. If * it is not there, the actual root window is returned. * *********************************************************************** */ #ifndef NULL #define NULL 0 #endif Window FindVirtualDesktop(dpy) Display *dpy; { Window root; /* the returned root window */ Window rootReturn; Window parentReturn; Window *children; unsigned int numChildren; int i; Atom __SWM_VROOT; /* get the default root window */ root = RootWindow(dpy, DefaultScreen(dpy)); /* go look for a virtual desktop */ __SWM_VROOT = XInternAtom(dpy, "__SWM_VROOT", False); children = NULL; XQueryTree(dpy, root, &rootReturn, &parentReturn, &children, &numChildren); for (i = 0; i < numChildren; i++) { Atom actual_type; int actual_format; long nitems, bytesafter; Window *newRoot = NULL; if (XGetWindowProperty (dpy, children[i], __SWM_VROOT,0,1, False, XA_WINDOW, &actual_type, &actual_format, &nitems, &bytesafter, (unsigned char **) &newRoot) == Success && newRoot) { root = *newRoot; break; } } if (children) XFree(children); return (root); }
terence@hkov04.dec.com (Terence Lee @HKO, Digital Equipment Corporation) (06/28/90)
In article <1376@shodha.dec.com>, west@gsrc.dec.com (Jim West (Stealth Contractor)) writes... # #In article <9518@odin.corp.sgi.com>, mikey@eukanuba.wpd.sgi.com (Mike Yang) writes... # # There is another solution. You could check for the existence of the DEC #window manager psuedo-root and then use it in your programs. What follows #is an Ada procedure that will 'look' for this window. # How about a VAXC routine? Window find_root(pwin) Window pwin; { XWindowAttributes pxwa,cxwa; Window root,parent,*child; int i,nchild; if (!XGetWindowAttributes(dpy,pwin,&pxwa)) pfail("find_root: fail to get window attributes\n"); if (XQueryTree(dpy,pwin,&root,&parent,&child,&nchild)) { for (i = 0; i < nchild; i++) { if (!XGetWindowAttributes(dpy,child[i],&cxwa)) pfail("find_root: fail to get window attributes\n"); if (pxwa.width == cxwa.width && pxwa.height == cxwa.height) return(find_root(child[i])); } return(pwin); } else pfail("find_root: fail to get root window\n"); } ================================================================================ Terence Lee terence%hkov04.dec@decwrl.dec.com root%hkvs04.dec@decwrl.dec.com From Middlesex, UWO ================================================================================
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (06/30/90)
>>> The problem is that the DEC window manager places a full-screen, >>> pseudo-root window over the real root window. >> There is another solution. You could check for the existence of the >> DEC window manager psuedo-root and then use it in your programs. > This problem also exists for swm users when the Virtual Desktop is > enabled. With our next release (very soon now), you will find a C > fragment in /usr/lib/X11/swm/vdt.c that will return the actual root > window or the Virtual Desktop window if swm is running and the vdt is > enabled. I think the point is more that the application shouldn't *have* to go through this sort of contortion just to do something with the root window. Sure, it can be written to handle swm and DEC's wm today, but tomorrow some new wm will come out that does things slightly differently and a large number of people will see the application break when really it is not the application that's broken at all. I now find myself curious. A question for those who feel it necessary to use root blanket windows like this: why? What do you get this way that you can't get without breaking programs like xsetroot? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
toml@ninja.Solbourne.COM (Tom LaStrange) (07/02/90)
|> >>> The problem is that the DEC window manager places a full-screen, |> >>> pseudo-root window over the real root window. |> >> There is another solution. You could check for the existence of the |> >> DEC window manager psuedo-root and then use it in your programs. |> > This problem also exists for swm users when the Virtual Desktop is |> > enabled. With our next release (very soon now), you will find a C |> > fragment in /usr/lib/X11/swm/vdt.c that will return the actual root |> > window or the Virtual Desktop window if swm is running and the vdt is |> > enabled. |> |> I think the point is more that the application shouldn't *have* to go |> through this sort of contortion just to do something with the root |> window. Sure, it can be written to handle swm and DEC's wm today, but |> tomorrow some new wm will come out that does things slightly |> differently and a large number of people will see the application break |> when really it is not the application that's broken at all. |> |> I now find myself curious. A question for those who feel it necessary |> to use root blanket windows like this: why? What do you get this way |> that you can't get without breaking programs like xsetroot? |> |> der Mouse You can get a large pannable "root" window. The problem is that the ICCCM doesn't address the problem, it even admits that further work needs to be done. I know work on virtual root window extensions was being done around R3 but I don't know anything about what was good/bad about the implementation. I know it's simplistic, but something that would help is something like a WM_ROOT property placed on client windows that would tell the window who its logical root window is. This type of property would make multiple "rooms" pardigms much easier to implement because each room could then be a seperate X window. Thoughts? -- Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml Longmont, CO 80501
dshr@eng.sun.COM (David Rosenthal) (07/03/90)
> You can get a large pannable "root" window. The problem is that the ICCCM > doesn't address the problem, it even admits that further work needs to be > done. I know work on virtual root window extensions was being done around > R3 but I don't know anything about what was good/bad about the implementation. > > I know it's simplistic, but something that would help is something > like a WM_ROOT property placed on client windows that would tell the > window who its logical root window is. This type of property would make > multiple "rooms" pardigms much easier to implement because each room > could then be a seperate X window. > The work that went on around R3, largely thanks to Audrey Ishizaki at HP, implemented something along the lines of a property that let a client know its logical root. It turned out that this wasn't enough. For all sorts of reasons (I remember problems with events, grabs, etc) we decided that the only way to really do a pseudo-root was to implement a "chroot()" extension, to change the server's idea of a window's root. Having the server and the client disagree about what the logical root of a window is just results in too many problems. The "chroot()" extension isn't hard to spec, but implementing it does affect quite a lot of the server code. David.
thoth@springs.cis.ufl.edu (Gilligan) (07/09/90)
I find it mildly interesting that the original thread of this article was a window manager bug and noone has bothered to change the subject. Anyway, I think that the *PSEUDO-ROOT-WINDOW-ISSUE* (use this for followup subject) was rather successfully addressed in R3 with that psedo-root program I can't remember the name of. It would create a subwindow of the current display and give it a different name like herman:0.7 instead of herman:0.[0-6] like all the other virtual screens. Can anyone close to that project tell me what exactly was wrong with that model? Also, I really, really, really, really, really want a scrollable root window. I'm just the kind of guy who needs a 456" monitor to hold all his windows, know what I mean, Vern? -- ( My name's not really Gilligan, It's Robert Forsman, without an `e' )