"Harold L Hunt II" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Cary Jamison wrote: > > > I've noticed this too, but haven't complained about it. I didn't > > realize the problem was specific to the -multiwindow window manager. > > This isn't a problem. It is "the way it works". > > > If this is true, than -multiwindow is not behaving as expected nor as > > other window managers behave wrt default cursors. The xsetroot is a > > work-around, but it seems to me this should be regarded as a bug in the > > window manager. The 'X' should be the default cursor when over the root > > window but an arrow when over an application window. Since -multiwindow > > doesn't really have a visible root window, it seems like permanently > > changing the default cursor to a pointer would be a good/quick solution. > > Fine. Run 'twm' as your window manager. Doesn't it do the same exact
> thing? That is the way that I have been reading the emails... if that > is not the case, then could somebody please describe this better.? No, it behaves as I described earlier. Let me try again. There is an 'X' over the root window, but when over an application window the X changes to an arrow. I realize that an application may define its own pointers, but when it doesn't -multiwindows goes back to an 'X' and twm goes to a black arrow. For example : XWin& twm& xclock& When the pointer is over the clock, it is a black arrow. When over the background it is an 'X'. XWin -multiwindow& xclock& When the pointer is over the clock it is an 'X'. There is no background window. I notice this in other apps as well. For example, on the scroll-bar of a gnome-terminal window displayed from my Linux box. This is where it gets annoying, because you have to point with the center of the X instead of the tip of an arrow. So, in essence most window managers have two default pointers - one when over an app and one when over the background. (Perhaps the window manager only has one default pointer and uses the X server's default pointer when not over a managed window?) >From the history of XWin it is easy to see that there was originally only a need for one default pointer. When the internal window manager got added, it still only has one pointer. However, since there is no background root window having one pointer is sufficient since it can be the app default pointer (an arrow) instead of the background default pointer (an X). > The solution you propose is not trivial. That is why this is "the way > it works" and not a bug. I'm sure that upon further inspection you > would figure out that trying to change this policy would result in the > creation of a mouse-cursor over-riding policy that is a lot more > complicated than what you think it would be. I'm pretty sure that it > would be complicated enough that it isn't worth looking into. Of > course, feel free to code me into submission. You may be right, since I haven't looked at the code yet. The default should be changeable through resource files, etc., so to do it right may not be as simple as adding a line of code in the internal window manager to change it. Does the internal window manager handle any resources at all, yet? There probably hasn't been a need to define any. The workaround of setting it in the startup file isn't bad, but it would be nice to get it changed right for the newbies, etc. Maybe as a minimum the xsetroot command could be added with appropriate comments to the startup file. Here's even a psuedo-diff for you :-) <append to startxwin.bat> + REM Set default cursor - normally only useful with -multiwindow window manager + run xsetroot -cursor_name left_ptr -fg white -bg black I'm not making any promises, but my work-load should lighten up in a couple weeks and I may be able to have a look at this then. > Harold Cary