pwh@bradley.bradley.edu (Pete Hartman) (01/19/91)
Well, I just got accustomed to the idea that my monochrome SLC just won't do that nifty 3d-look that I like so much, and started working on how to get the background to be set to a bitmap pattern. Under normal X (previously compiled X11R4), I just had a line in my .xinitrc: "xsetroot -bitmap $PATH/bitmapname". Real Easy. Under Sun's OpenWindows V2.0, I put this ANYWHERE (.xinitrc, .openwin-init) and sure enough, the bitmap comes up, only to be replaced moments later by this nondescript grey background. If I type the command by hand in one of my xterm windows everything is fine, but I want this to come up automatically. Of course, the documentation doesn't mention any kind of resources for the "Workspace" except "WorkspaceColor" which (as I understand it) is useless. Is there something that I'm just too blind to see, or is this thing really designed so bass-ackwards that you can't customize your background automatically (unless of course you like solid "colors")? -- ----- Pete Hartman pwh@bradley.bradley.edu Haazavaa?
holtz@netcord.Eng.Sun.COM (Brian Holtz) (01/20/91)
In article <1991Jan19.005427.24901@bradley.bradley.edu> you write: >the documentation doesn't mention any kind of resources for the "Workspace" >except "WorkspaceColor" which (as I understand it) is useless. If you put the absolute path of an X bitmap file as this resource's value, that bitmap will be your background. My only problem with this is that olwm then assigns a random color as the background of my icons. So in my .xinitrc I do (sleep 60; xsetroot -bitmap ${HOME}/bitmaps/arecibo.half.xbm) & -- Brian Holtz
grp@magpie.unify.com (Greg Pasquariello) (01/22/91)
> >Well, I just got accustomed to the idea that my monochrome SLC just >won't do that nifty 3d-look that I like so much, and started working >on how to get the background to be set to a bitmap pattern. Under >normal X (previously compiled X11R4), I just had a line in my .xinitrc: >"xsetroot -bitmap $PATH/bitmapname". Real Easy. Under Sun's OpenWindows >V2.0, I put this ANYWHERE (.xinitrc, .openwin-init) and sure enough, >the bitmap comes up, only to be replaced moments later by this nondescript >grey background. If I type the command by hand in one of my xterm windows >everything is fine, but I want this to come up automatically. Of course, >the documentation doesn't mention any kind of resources for the "Workspace" >except "WorkspaceColor" which (as I understand it) is useless. > >Is there something that I'm just too blind to see, or is this thing really >designed so bass-ackwards that you can't customize your background >automatically (unless of course you like solid "colors")? Whats happening is a race condition between the olwm and the xsetroot. I am unaware of any resources that will allow you to do this kind of thing, but I've had success by starting olwm first, then, as the very last thing, sleep for a few seconds and do the xsetroot. This will allow time for olwm to do it's background, at which point the xsetroot can run and replace it. >-- >----- >Pete Hartman pwh@bradley.bradley.edu Haazavaa? >
jeff@Unify.Com (Jeff Mischkinsky) (01/22/91)
In article <4w5wjtp@openlook.Unify.Com> grp@magpie.unify.com (Greg Pasquariello) writes: >> >>Well, I just got accustomed to the idea that my monochrome SLC just >>won't do that nifty 3d-look that I like so much, and started working >>on how to get the background to be set to a bitmap pattern. Under >>normal X (previously compiled X11R4), I just had a line in my .xinitrc: >>"xsetroot -bitmap $PATH/bitmapname". Real Easy. Under Sun's OpenWindows >>V2.0, I put this ANYWHERE (.xinitrc, .openwin-init) and sure enough, >>the bitmap comes up, only to be replaced moments later by this nondescript >>grey background. If I type the command by hand in one of my xterm windows >>everything is fine, but I want this to come up automatically. Of course, >>the documentation doesn't mention any kind of resources for the "Workspace" >>except "WorkspaceColor" which (as I understand it) is useless. >> >>Is there something that I'm just too blind to see, or is this thing really >>designed so bass-ackwards that you can't customize your background >>automatically (unless of course you like solid "colors")? > >Whats happening is a race condition between the olwm and >the xsetroot. I am unaware of any resources that will allow you >to do this kind of thing, but I've had success by starting >olwm first, then, as the very last thing, sleep for a few seconds >and do the xsetroot. This will allow time for olwm to do it's background, >at which point the xsetroot can run and replace it. >>Pete Hartman pwh@bradley.bradley.edu Haazavaa? In addition, you may run into problems with olwm if you try to start up "too many" processes and put up too many windows too quickly. This can occur if you start up olwm in your .openwin-init (or .xinitrc) and then immediately fire up a bunch of processess in the background. The "safe" thing to do is to sleep for a few seconds after starting up olwm and then sleep for a few seconds between groups of 4 or 5 startup processes. Thus my .openwin-init file looks like: cmd&; cmd&; cmd&; cmd&; cmd&; sleep 5; cmd&; ... -- Jeff Mischkinsky internet: jeff@unify.com Unify Corporation ...!{pyramid,csusac}!unify!jeff 3870 Rosin Court voice: (916) 920-9092 fax: (916) 921-5340 Sacramento, CA 95834 ICBMS: 38 38 40 N / 120 28 10 W
miken@Corp.Sun.COM (Michael Neff) (01/22/91)
>Well, I just got accustomed to the idea that my monochrome SLC just >won't do that nifty 3d-look that I like so much, and started working >on how to get the background to be set to a bitmap pattern. Under >normal X (previously compiled X11R4), I just had a line in my .xinitrc: >"xsetroot -bitmap $PATH/bitmapname". Real Easy. Under Sun's OpenWindows >V2.0, I put this ANYWHERE (.xinitrc, .openwin-init) and sure enough, >the bitmap comes up, only to be replaced moments later by this nondescript >grey background. If I type the command by hand in one of my xterm windows >everything is fine, but I want this to come up automatically. Of course, >the documentation doesn't mention any kind of resources for the "Workspace" >except "WorkspaceColor" which (as I understand it) is useless. It's not documented very well, but you can add a resource to your .Xdefaults file to keep olwm from drawing a background color. Add the following line: olwm.WorkspaceColor: Please note that you should have the line exactly as above with no value ( null ). Also note that this isn't the same resource as Openwindows.WorkspaceColor, which is the resource which the main Properties sheet sets. By using the above resource as shown, olwm will start behaving like twm and other window managers and leave the root background alone. I think this is what you want. Mike Neff miken@corp.sun.com >Is there something that I'm just too blind to see, or is this thing really >designed so bass-ackwards that you can't customize your background >automatically (unless of course you like solid "colors")? >-- >----- >Pete Hartman pwh@bradley.bradley.edu Haazavaa? >
paccini@uni2a.unige.ch (01/22/91)
In article <4w5wjtp@openlook.Unify.Com>, grp@magpie.unify.com (Greg Pasquariello) writes: [...] >> >>Is there something that I'm just too blind to see, or is this thing really >>designed so bass-ackwards that you can't customize your background >>automatically (unless of course you like solid "colors")? [...] > > Whats happening is a race condition between the olwm and > the xsetroot. I am unaware of any resources that will allow you > to do this kind of thing, If you look at the "olwm" man page, you can see an interesting ressource whose name is "Workspacecolor": WorkspaceColor (color specification) Specify the color for the workspace (root window). This may be a color name, an RGB specification (pre- ceded by a `#'), an absolute pathname specifying an X bitmap file, or a null value. If any non-null value is specified, olwm will set the root window to that color or pattern on startup and restore the system default on >>> shutdown. If a null value is specified, olwm will not >>> change the root background at all. This is useful if >>> you prefer to use programs that set the root back- >>> ground, such as xsetroot(1). Default value: #40a0c0. I use it, and it works fine. ------------------------------------------------------------------------------- Jean-Francois Paccini | paccini@cuisun.unige.ch CUI | paccini@cgeuge51.bitnet University of Geneva | mcsun!chx400!cui!paccini Switzerland |
fgreco@govt.shearson.com (Frank Greco) (01/22/91)
> >Is there something that I'm just too blind to see, or is this thing really > >designed so bass-ackwards that you can't customize your background > >automatically (unless of course you like solid "colors")? > > Whats happening is a race condition between the olwm and > the xsetroot. I am unaware of any resources that will allow you > to do this kind of thing, but I've had success by starting > olwm first, then, as the very last thing, sleep for a few seconds > and do the xsetroot. This will allow time for olwm to do it's background, > at which point the xsetroot can run and replace it. Something that's slightly related but may be useful in OpenWindows (X/NeWS with olwm) is that if you use use xloadimage to install a background (xloadimage -onroot...) *and* if you have a .startup.ps file (a NeWS-ish thing) modify stuff in your UserProfile dict (e.g., we needed to modify root menu fonts for NeWS apps), you get a PacMan-like effect where the movement of the windows "eats" the background. Frank G.