Have questions about Window Maker? If so, look no further. Below is our collection of Frequently Asked Questions and their corresponding answers. Many of these have been adapted from the original FAQ by Chris Green. Questions are routinely taken and added in from the mailing lists and IRC forums.
export CVSROOT=":pserver:anoncvs@cvs.windowmaker.org:/cvsroot"
cvs login
There is no password, so simply hit enter when prompted.
Then issue the following command ("wm" is the name of the module):
cvs -z3 checkout -d WindowMaker wmTo update your source tree, cd to the WindowMaker directory and type
cvs -z3 update -dPinside the WindowMaker directory.
For more detailed CVS instructions, please visit http://windowmaker.org/development-cvs.html
Many window managers are capable of turning large windows into smaller `icons' which represent the window yet don't take as much screen real estate. We're all familiar with that model.
Window Maker has two kinds of these icons. One kind is created when an application---technically, a window group---is started. It represents the entire application and is called an `appicon'. Such icons are square tiles containing only the picture which represents the application; they have no titles.
The second kind of icon in Window Maker is created when a particular window (possibly one belonging to an application displaying more than one window) is `miniaturized' (which is the same action as `minimizing' or `iconifying' in other window management models) using the miniaturization button on the window's titlebar. These miniaturized windows are called `miniwindows' and can normally be distinguished from appicons by their small titlebar at the top of the tile.
To put this all into perspective, let's examine the version number "0.65.1". This number signifies that there has not been a major revision release, that its minor revision is newer than the previous one (0.64.x), and that it's on the first patch level after the 0.65.0 release. This still might be confusing, so go away with this in mind: numbers ending in .0 tend to be new feature releases but less stable than .1, .2, .3 patch level releases, the latter of which are used to fix bugs.
It is generally safe to go with the highest numbered patch release.
In general, you will want to ensure the latest version of libtiff is installed (see ftp://www.libtiff.org). Typically on non-Linux systems, libtiff will be located under /usr/local, with includes and libs in those respective sub-directories.
Often, it will be necessary to add /usr/local/lib
to the system's LD_LIBRARY_PATH environment
variable (especially so on Solaris, but see 'man ld'
for details on your platform). Furthermore,
it is possible to supply special flags to the
configure script to help it find where the libraries
are. An example is given below:
./configure --with-libs-from="-L/usr/local/lib" \ --with-incs-from="-I/usr/local/include"
Also, you will want to make sure you're using GNU make (gmake) for the Window Maker compile.
Peter Ilberg gives us this answer:
Install WM wherever you want it, mine is in /opt/WindowMaker-0.16.0 (eg. use ./configure --prefix=/opt/WindowMaker-0.16.0). Run the install script wmaker.inst in your home directory.
Add the following two lines to .dtprofile in your home directory:
SESSIONTYPE=xdm; export SESSIONTYPE PATH=:/usr/contrib/bin/X11:$PATH:.; export PATHThis tells CDE to go looking for an .xinitrc/.xsession instead of using the default environment.
Make your .xsession/.xinitrc executable (VERY IMPORTANT, wmaker.inst did NOT do this automatically for me) using eg.
chmod ugo+x .xsessionYour .xsession/.xinitrc should look something like this:
#!/bin/sh
<some other init stuff that you want/need>
exec wmakerThings to try if it doesn't work: (somewhat fuzzy and random)
This should do it although I did have problems sometimes initially which I fixed by randomly trying absolute pathes for wmaker in .xsession/.xinitrc and/or making the dtprofile/.xinitrc/etc executable. It helps logging in on the console (select from CDE login screen) and start X manually using "X". If it works that way it should work when logging into the CDE environment. Remember to Check your paths!
If it doesn't work, you can also substitute some other window manager for wmaker in the .xinitrc and see if that works. If it does you know at least that .xinitrc is getting called/executed, so your WM path is wrong or not set.
Method 2:
Thomas Hanselman gave this alternative answer (via Peter Ilberg):
Build and install WM wherever you want, as described in Method 1. You can install and run WM just fine from your home directory. That's what I'm doing, since I don't have root access at work :(. Then, in your Xdefaults file in your home directory, add the following line:
Dtsession*wmStartupCommand: <path to WindowMaker executable>Then, log out, and log back in, and, unless I've forgotten a step (or this is a custom Nortel thing), you should be in Window Maker heaven ;).
Difference between the methods: (according to Thomas)
I've been told that the difference between setting the resource and Peter's method is that if you override the window manager with the resouce, you still get the CDE resources read into the resource database (so you still have your color settings & such from CDE), whereas with Peter's, the CDE resource don't get read into the database. I don't know if this is true or not, however. Also, another thing to note with Window Maker and HP-UX 10.20 -- if you select "Exit Session" from the WM root menu, WindowMaker and all of your applications are killed, but you may not be logged out. Again, this might be an artifact from my work environment, or the way I start Window Maker.
Owen Stenseth adds:
When using this method it is possible to exit Window Maker cleanly by using the dtaction command. I use the following in my Window Maker menu:
"Exit Session" EXEC dtaction ExitSession
The only problem I have at the moment is I seem to get multiple copies of asclock running when I log in again.
If this is necessary, it will be listed in the NEWS file included in the source distribution. Since 0.15.x, the domain files have been changed in such a way that re-running wmaker.inst is redundant. The user config files are by default merged in with the global ones normally located in /usr/local/share/WindowMaker/Defaults. So, even if new options are added, they should be automatically added to the environment.
cpp -> /usr/bin/cpp-2.95*Another possibility is your /usr/X11/lib/X11/xinit/xinitrc is a broken symlink. Either create a new symlink, or do something like:
$ cp /usr/X11/lib/X11/xinit/xinitrc.fvwm2 \ /usr/X11/lib/X11/xinit/xinitrc.wmaker
$ ln -sf /usr/X11/lib/X11/xinit/xinitrc.wmaker \ /usr/X11/lib/X11/xinit/xinitrcthen just edit /usr/X11/lib/X11/xinit/xinitrc and replace the exec of 'fvwm2' by '/usr/local/bin/wmaker' (should be somewhere towards the end of the file, most probably the very last line).
Thanks to Tomas Szepe for the second part.
By default, the SGI X Server uses 8-bit Pseudocolor mode. To change it, edit (as root) the file /usr/lib/X11/xdm/Xservers. Change it to read:
:0 secure /usr/bin/X11/X -bs -c -class TrueColor -depth 24
Assuming you installed Window Maker according to the README's that come with the source, all you need to run Window Maker on a Solaris box is an entry in the .xinitrc. This should work for any version. When you run wmaker.inst the first time, allow it to make changes to the .xinitrc file. Mine looks like this:
#!/bin/sh # Window Maker Default .xinitrc exec /usr/local/bin/wmakerBelieve it or not, that's all that it takes. This, in fact, runs Window Maker instead of OpenWindows. In order to choose Window Maker, you simply choose "OpenWindows Desktop" in the "Options - Session" Menus And Choose "CDE Desktop" if you want CDE.
The color schemes and settings for Window Maker are seperate from CDE. I tested on a SPARC 10, but I assume Solaris x86 would work also.
(webmaster note: It works fine on Solaris x86)
Installing Window Maker on a Solaris 2.6 box might require one or two little hints. Here you are (this was on a system running xdm by the way, but similar suggestions apply otherwise):
1) /usr/openwin/lib/X11/xdm/Xservers like this:
:0 local /usr/openwin/bin/X -dev /dev/fb defdepth 24 defclass TrueColor
2) Turn off shm in the WindowMaker configure:
./configure --disable-shm
3) might have to modify your LD_LIBRARY_PATH:, or make "wmaker"
a script that does it for you (mv wmaker wmaker.exe):LD_LIBRARY_PATH=/usr/local/lib:/usr/local/X11/lib:/usr/lib:/usr/openwin/lib export LD_LIBRARY_PATH /usr/local/bin/wmaker.exe $*
The real key is the "--disable-shm".
(webmaster note: Window Maker should work fine with SHM enabled, at least it does under Solaris 8. Try the default first, and then use this if you run into problems with it)
libwraster.so.1: cannot open shared object fileThese are the instructions for Linux.
First, make sure that /usr/local/lib ( or whatever directory you installed Window Maker to) is listed in your /etc/ld.so.conf ). You need to run ldconfig so the new shared libraries will be loaded. After running ldconfig as root, the linker should properly load the libraries. You need to run this every time you update Window Maker.
Thanks to Joseph Czapiga, the BSD procedure for adding shared library directories is
ldconfig -m /usr/local/lib (m means merge)
From Blaine Horrocks:"You can also work around this problem on RedHat5.2 by copying the distributed aclocal.m4 to acinclude.m4 before running configure for the first time. Configure works fine and doing the make succeeds."
Try compiling Window Maker with the newer gcc or recompile your system libraries with the older gcc. It's generally a bad idea to mix and match.
How many of you have seen that darned "lib reports 62 caller expects 61" type of error? Here are some answers that will possibly help you out.
First things first. As always, make sure there are not older copies of libjpeg floating around on your system. ]Some distributions by default come with an old libjpeg.so.1 in the /usr/X11R6/lib/ directory. This can simply be deleted. Or if something complains after you delete it, recompile it if you can to look for the new lib in the right place, or if that fails, as a last resort, you might add a symlink to the new lib like so: ln -s /usr/local/lib/libjpeg.so.6.0.2 libjpeg.so.1
Note that you should use your system's version of ldconfig to properly manage your library cache (or other appropriate mechanism).
On Linux, this would mean having /usr/local/lib in /etc/ld.so.conf and then running ldconfig.
Now on to the error. This is basically caused by your application having been compiled to dynamically use the libjpeg.so shared library. When you install a new lib and then try to run your program again, it expects the lib it was compiled against, in this case the older libjpeg.so.6.0.1 and instead finds libjpeg.so.6.0.2 and reports the error.
The fix is actually rather simple. Along with adding a libjpeg.so.6 symlink like so (just in case): ln -s libjpeg.so.6.0.2 libjpeg.so.6 where you installed your new lib, you simply need to recompile your app to link it against the new library.
Also, make sure to use GNU make for the Window Maker compile.
In order to run wmaker, a user needs to have an ~/.xinitrc file consisting of something similar to
#!/bin/sh exec wmaker
This will vary from system to system, but the existance of an .xinitrc file will generally override the system defaults.
You should also get the newest zlib libs from http://www.gzip.org
Generally, the same rules apply here as with libjpeg. Make sure there are no older versions of the necessary libs floating around on your system, then try to configure and make again.
Also, make sure to use GNU make (gmake) for the Window Maker compile.
Also, make sure to use GNU make (gmake) for the Window Maker compile.
"wrlib: could not allocate shared memory segment: invalid argument"This one is generated by wrlib if Window Maker is compiled with shared-memory usage enabled (which is the default). The explanation is that Solaris by default comes with a shared memory segment size of maximum 1 M. What happends is that if you have a really-really cool(tm) background, it is usually much bigger than that 1 M segment of shared memory. To see your defaults relating the IPC settings check the output of the "sysdef" command (look for IPC Shared Memory). There you should see the maximum allocable size for a shared memory segment. If it is less than 5 M you should really increase it by adding the following line in your /etc/system file:
set shmsys:shminfo_shmmax=20971520
*) Make sure you don't already have this value set. If you do,
simply increase the value. In case you have a much
bigger value, stick to what you have, because you should have
no problems with it.
*) The value allows a maximum segment size of 20 M, which really
should be enough for anyone. If not, try using a smaller background
image!
*) Make sure you spell the line exactly as shown, otherwise
at boot time the kernel will complain of not finding such a module
name and will not set a thing about it!
*) Make sure you don't delete other lines or modify them "beyond
recognition", for evil things may happen at boot time.
After adding this to your /etc/system you need to reboot in order for the new limit to take effect. Also, you may want to check the new limit just to make sure it has been set.
Thanks to Bogdan Iamandei for this answer.
/usr/dt/config/C/Xresources.d/Xresources.* /usr/dt/config/Xsession.*If you look in there, you'll find Xresources.ow and Xsession.ow, respectively. All you need are two files that set up Window Maker (or any other window manager) in a similar fashion, calling them Xresources.wm and Xsession.wm (or whichever extension you prefer).
Here is an example setup:
#
**************************************************************************
#
# Window Maker config file
# Mike Bland <mbland@cmu.edu>
#
# /usr/dt/config/C/Xresources.d/Xresources.wm
#
# used by dtlogin
#
#
**************************************************************************
Dtlogin*altDtsIncrement: True
Dtlogin*altDtName: Window Maker Dtlogin*altDtKey: /usr/local/bin/wmaker Dtlogin*altDtStart: /usr/dt/config/Xsession.wm #Dtlogin*altDtLogo: /usr/local/share/logos/WM_logo.xpm
# Once I get a logo ready, I'll add it to the dtlogin screen by uncommenting # the last line.
And this example script:
#!/bin/ksh
#
**************************************************************************
#
# Window Maker startup script
# Mike Bland <mbland@cmu.edu>
# /usr/dt/config/Xsession.wm
#
# used by dtlogin
#
#
**************************************************************************
. /usr/local/etc/.profile # Sources the file containing necessary
# environment variables (especially
# LD_LIBRARY_PATH=/usr/local/lib:...);
# make sure it's executable.
WINDOW_MANAGER=/usr/local/bin/wmaker
export WINDOW_MANAGER
/usr/local/bin/wmaker
For developers, there is a proplist-compat.h header that provides a mapping between the old and new function names. See the comments in this file for further instructions.
~/GNUstep/WindowMaker/WindowMaker is main config file. This file controls options such as keybindings, fonts, pixmaps, and focus modes.
~/GNUstep/WindowMaker/WMWindowAttributes controls the "attributes" for individual applications and appicons. Options such as what icon to use are set here. For the most part, this is now best accessed via a right click on a title bar of an application and selecting "Attributes"
~/GNUstep/Defaults/WMState is the file that is automatically generated and contains the current dock settings. It is not recommended to edit this file by hand.
~/GNUstep/Defaults/WMRootMenu specifies what file to use as the root menu. In Window Maker 0.19.0 and higher, this file should be replaced by plmenu from ~/GNUstep/Defaults/WindowMaker so that one can use WPrefs.app to edit the menu.
~/GNUstep/Library/WindowMaker/menu is used to change your root menu, if you are using the old menu style.
Scroll Down and choose ``Sloppy'' Focus Mode.
You may also use a text editor on
~/GNUstep/Defaults/WindowMakerand change the following:
FocusMode = sloppy;
Or in
~/GNUstep/Defaults/WindowMakerset
AutoArrangeIcons=YES;and the icons should now auto-arrange.
Or you can use a text editor to make sure that these settings are in your ~/GNUstep/Defaults/WindowMaker file:
CirculateRaise = YES; RaiseDelay = 1;As of 0.61.0, MS Window's Style application tabbing is supported by default.
Select the tile and then choose the edit texture dialog. Then you may choose any of the different tile background options in the The old text editor method is provided below for convience.
You need to change one line in your '~/GNUstep/Defaults/WindowMaker' file.
IconBack = (spixmap, tile.black.xpm, white);The last parameter is the color that fills in any transparent parts of your icon.
This should allow you do dock the program normally.
Dan Pascu adds:
Emulate Appicon does exactly the same as dockit. So if Emulate Appicon does not work, dockit will not work either. For such apps you can do nothing. They are badly coded (they do not set the instance.class hints). For these Attributes are also not available, since attributes apply to an instance and/or class hint.
Note: Dockit was previously distributed with Window Maker and was launched from the top dock icon.
Elliott Potter adds:
There's another way to dock applications that misbehave ... I've only done this with a couple of things (Adobe AcroRead is the only one I remember at the moment).
If Attributes -> Advanced Options -> Emulate Application Icon doesn't work:
Dock another application to the clip, where you want your application to go. I used gv, but anything you can dock will work. Quit WindowMaker Edit ~/GNUstep/Defaults/WMState If you're docking to the clip, scroll down to the Workspaces section. When you find whatever you docked, you'll see:
{
Command = gv;
Name = GV.gv;
AutoLaunch = No;
Forced = No;
BuggyApplication = No;
Position = "6,0"
Omnipresent = No;
DropCommand = "gv %d";
},
Edit it to use the info for your new application:
{
Command = acroread; # use the full pathname if you have to
Name = acroread.acroread;
AutoLaunch = No;
Forced = No;
BuggyApplication = No;
Position = "6,0"
Omnipresent = No;
DropCommand = "acroread %s";
},
Then edit WMWindowAttributes, and add a line for your application's
icon...you can edit the line that was inserted, or make a new one - I
just make a new one:
acroread.acroread = {Icon = pdf.tiff;};
Then re-start WindowMaker, and your icon should be there! You can move it around like any other docked app now, but the Attributes section still won't work.
By Default, to get back to the attributes menu, use the key combination Control-Esc.
wmsetbg now accepts the following options:
usage: wmsetbg [-options] image
options:
-d
dither image
-m
match colors
-t
tile image
-s
scale image (default)
-u
update Window Maker domain database
-D <domain>
update <domain> database
-c <cpc>
colors per channel to use
By default, it will try to guess if dithering is needed or not and proceed accordingly. Using -d or -m will force it to dither or match colors.
Dithering for more than 15bpp is generally not needed, and will only result in a slower processing. Don't use dithering except when needed, because it is slower. Else rely on wmsetbg which will detect if dithering is needed and use it.
-u
will update the WorkspaceBack in the default database domain file in ~/GNUstep/Defaults/WindowMaker, and let Window Maker refresh the screen. Please note that this option only works under Window Maker, and will have no effect under other window managers, since it rely on Window Maker to update the image after it reads the updated defaults database.-D
<domain> is same as above, but will update the domain <domain> instead of the default Window Maker domain.-c
<cpc> will set the color per channel to use. Only needed for PseudoColor visuals. Window Maker will automatically pass the value read from the Window Maker domain database.
The following line is straight from your WindowMaker-0.15.x ~/GNUstep/Library/WindowMaker/menu file and should all be on one line.
"Images" OPEN_MENU BACKGROUNDS_DIR ~/GNUstep/Library/WindowMaker/Backgrounds WITH wmsetbg -u -t
This should give you an idea on how to add other entries for different image directories. See the help info at the top of the ~/GNUstep/Library/WindowMaker/menu file for more information.
If you for some reason would like to set your background image with XV, for instance to use an image format not yet supported by wmsetbg or to use one of XV's special modes, edit the file ~/GNUstep/Library/WindowMaker/autostart and insert the line
xv -root -quit -maxpect ~/background.jpgor
xv -root -quit -max ~/background.jpgyou can also try variations of this to get different tiling and other effects (where X is a number 1-9 I believe): 'xv -root -quit -rmodeX ~/background.jpg'
If you would like xv functionality in your menu, heres a nice little tip from Alfredo:
Add the following line to your ~/GNUstep/Library/WindowMaker/menu file. (all on one line)
"More Backgrounds" OPEN_MENU /home/whoever/backgrounds xv -root -maxpect -quit
Then switch ``Appearance Preferences'' tab and select what widget you would to adjust under the ``Texture'' tab. Click edit. Chose an image texture format and then search for the texture.
You can use a similar procedure for any type of menu editing.
You can use png, gif, ppm, tiff, jpeg and xpm images interchangeably in Window Maker if you have compiled in support for those formats.
If you happen to --enable-openlook at compile time, Netscape (and presumably other apps as well) believe they're running under OLVWM, and minimise with monochrome icons. Once compiled without OpenLook support, Netscape minimizes with the correct icon.
Alternatively, you may add
Superfluous=YES;to your ~/GNUstep/Defaults/Windowmaker file.
Or you can add
NewStyle=NO;to your ~/GNUstep/Defaults/Windowmaker file.
Jim Noble explains another way to do this:
If you've got a two-button mouse under some versions of Solaris x86, there's no way (that I'm aware of) to emulate a 3-button mouse. The right button can be either MB2 or MB3, but chording doesn't work.
ApplicationMenuMouseButton = Left;and
WindowListMouseButton = Right;in ~/GNUstep/Defaults/WindowMaker ought to allow the left button to activate the root menu, and the right button (as MB2) to activate the windows menu.
For old style menus, edit the file
~/GNUstep/Library/WindowMaker/menuand save your changes. Window Maker should detect the change and automatically update. If you are having a problem getting it to reload the menu, try
touch menuto force the modification time into the future.
You should just start it from a terminal by supplying it's FULL path-name, which is usually the following:
/usr/local/GNUstep/Apps/WPrefs.app/WPrefs
At this point, a new appicon should be generated
which can be placed back into the Dock.
Another method is to edit ~/GNUstep/Defaults/WMWindowAttributes by hand and use the AlwaysUserIcon=YES; option for the app. For example:
xmcd = { Icon = "Radio.xpm"; AlwaysUserIcon=Yes; };
By editing
~/GNUstep/Defaults/WindowMakerinsert or modify the key
WorkspaceNameDisplayPosition = none;Other valid options for this include center/top/bottom/topleft/topright/bottomleft/bottomright;
("External Menu", OPEN_MENU, "| bob.sh")
in a proplist style menu. You can tell if you have a proplist style menu if you can
edit it with WPrefs.
You can do this directly in WPrefs by going to the menu editor, adding an "external menu", and then clicking the "ask guru button" and filling in the process name.
First, if you do not want to use the clip or dock at all, you can launch wmaker with with
wmaker --no-clip --no-dockand then in
~/GNUstep/Defaults/WMWindowAttributesadd
"*" = {NoAppIcon=Yes;};
The problem with this method is if you use the dock for dockapps, it renders them
with out an appicon to write to.
An alternative method if you are willing to let the clip be on your desktop is
to right click on the clip > clip options > auto attract.
Double click the clip so that it is grayed and all appicons will be hidden.
Then you can hide the clip behind the dock so that it is out of your way.
This will allow appicons to work.
Set the focus to the window and then use the keystroke assigned to the titlebar menu. If you're not sure what the keystroke is, you can find out using WPrefs: in the keyboard section, select the `Open window commands menu' item in the list of actions. The keystroke assigned to it ought to appear in the `Shortcut' area'.
Typically it is Control-Esc or F10 in older version of WindowMaker.
The result is that [Alt+Button1] (which usually grabs a window to move it around), [Alt+Button2] (which usually grabs a window to move it around without changing the window stacking order), and [Alt+Button3] (which usually resizes a window) all get passed to the application instead of performing their usual action.
For the Clip, either:
(a) Disable the Clip from WPrefs (panel number 7), or
(b) Hide the Clip under the Dock (for example, in the upper righth
and corner of the screen).
[b] is probably more useful on desktops with limited space, since you can still set the Clip to attract app-icons so they don't clutter your desktop.
For the Dock, try the following:
(1) Exit Window Maker.
(2) Log in via a text console or using a different window manager.
(3) Edit ~/GNUstep/Defaults/WMState using your favorite text editor
(for example, vi, emacs, or pico).
(4) Find the `Applications' part of the `Dock' structure. Find the
item with `Position = "0,0";'. Change the `Command' item to the
command you want the top tile to launch. Change the `Name' item
to the "<instance>.<class>" name of the application you just made
the Command item start (for example, if `Command' is `"xedit"',
then `Name' should be `xedit.Xedit').
(5) Save the WMState file.
(6) Start an X session with Window Maker.
(7) Check that the top tile starts the command you told it to. (You
should still also be able to move the Dock up and down using
[LeftDrag] on the top tile.)
(8) You can configure the tile (including autolaunch and the
drop-command) in the regular manner ([RightButtonDown] on the
tile and choose `Settings...' from the resulting menu).
This will work:
(ssh,
("us-gw", EXEC, "Eterm -e ssh us-gw"),
This will not:
(ssh,
(us-gw, EXEC, "Eterm -e ssh us-gw"),
Thanks to Martin Sillence for pointing this out.
Next, right click on the desktop to bring up the menu. Select Workspace -> Save Session to make this permanent.
"Exit will exit wmaker, but can leave other X apps running, provided that it was not the last app launched in the .xinitrc (for instance, if you had exec wmaker, followed by exec xterm, exiting wmaker using 'Exit' will leave the xterm running so you could start another window manager, etc.) This is accomplished because X will not shutdown unless all X apps are closed.
Exit session will exit wmaker, but will also close all running apps, thus the X server will be closed too."
With the release of 0.18.0, this hack is now working and hopefully no one will have to ask this question again.
"Maybe you know: Alt+Left click and drag to move the window.
Try this: Alt+Right click and drag to resize (by moving the nearest window corner)
Another move/resize tip: while you are moving or resizing a window, you can change the move/resize mode by pressing the SHIFT key."
TODO: give complete explanation
~/GNUstep/Defaults/WindowMakerin some option like WorkspaceBack, it will not find the image because Window Maker can't read your mind to figure where you put the image. So, to fix it, you have to either place the full path for the image in the texture specification or put the path for the directory you put your background images in the PixmapPath option. You can also put all your background images in places like
~/GNUstep/Library/WindowMaker/Backgroundsor
/usr/local/share/WindowMaker/BackgroundsDavid Green says that another possibility is that you have two copies of the worker programs: wmsetbg (and possibly setstyle) and the wrong one is in the path first.
First, it is used to select multiple windows on a desktop at a time. When these windows are selected, they can be moved around on your desktop and will retain their relative positions.
Second, once selected, they are persistent through desktop changes. So it is useful for moving large numbers of windows between desktops.
You can also select windows with shift+click.
gimp={Icon="gimp.tiff";};
Window Maker now can assign Icons from within the windowmanager. To do so, right
click on the title bar of an app, click on the droplist->Icon and WorkSpace entry, enter the icon file name (
make sure this is in your pixmap path ), click update, apply, and then save.
You don't need to patch the XEmacs code, just run
./configure --with-session=yes (in addition to any other options you use)in your XEmacs 20.3+ sourcedir and rebuild it. Then XEmacs shows an appicon when running and you can easily dock it.
asclock was written by Beat Christen and used to have its own website, which seems to have disappeared. However, references to it exist all over the place, and can be found by searching Google. Beat Christen wrote this awhile back:
"Please note that the asclock-gtk version 2.0 beta 4 (asclock-gtk-2.0b4.tar.gz) does not have the -d switch yet and that the asclock-xlib-2.1b2.tar.gz does not have the shaped asclock builtin."
A wonderful alternative to asclock is Jim Knoble's wmclock. It duplicates asclock and adds some much needed improvements.
For older versions such as asclock-classic , use a command line similar to
asclock -shape -iconic -12 &For newer versions such as asclock-xlib 2.0 and asclock-gtk use
asclock -shape -iconic -12 -d &Drag it from the top right corner of the clock to the dock. Right click on the icon and select autolaunch.
In order to make asclock launch every time you start Window Maker, right click on the outer edge of the border for asclock until a menu appears. Select the "Settings" item and then select the "Lauch this Program Automatically" option then select the "OK" button.
If you get an error such as sh: /dev/console: Permission denied, login as root, cd to /dev/ and run
./MAKEDEV console
Another large index of dockapp links is available at http://www.bensinclair.com/dockapp . The downside to this is that they're only links, so if someone stops maintaining a dockapp, or their web hosting provider cuts them off, you won't be able to get to it. Still, Ben Sinclair's site was the first big "dockapp warehouse" site, so we give credit where credit is due. :)
John Eikenberry has also created an rpm which is available from ftp://ftp.coe.uga.edu/users/jae/windowmaker
rxvt -name foo -e irc
Then, go to the Attributes menu ( right click on titlebar -> Attributes) / Advanced Options and enable "Don't Bind Keyboard shortcuts". Click Save and Apply and you should be able to run your session without the shortcuts.
rxvt -name foo -title TestingThen Right click on the title bar to bring up the attributes menu, and you will be able to edit the properties for foo.XTerm (ie: assign a unique icon).
The easiest way to accomplish this is to dock XTerm as normal. Then Go to the Attributes menu -> Application Specific and select no application icon for XTerm.
Then right-click on the docked appicon and select settings. Change the Application Path with arguments section to
'/bin/sh -c "exec xterm &"'
user specified location: 136679205, 1074468360
user specified size: 400 by 300
program specified minimum size: 400 by 300
Now, when scilab opens it's window, Window Maker nicely does exactly what it
is told, that is, map the window at position 136679205, 1074468360 which
obviously falls outside the screen no matter how big is your monitor ;)
Meanwhile, the workaround for this is to open the window list menu (click on the root window with the middle mouse button) and click on the ScilabGraphic entry. The window should be brought to your reach. Then, open the window commands menu (right click on window's titlebar) and open the Attributes panel. Go to the "Advanced Options" section, check the "Keep inside screen" option and save.
If you can recompile Scilab, this came from a Scilab developer:
replace
size_hints.flags = USPosition | USSize | PMinSize;with
size_hints.flags = /** USPosition |**/ USSize | PMinSize;in routines/xsci/jpc_SGraph.c
You can find these programs on http://www.freshmeat.net
(1) Make the terminal window start the program you want to run instead of a shell. Both xterm and rxvt (and its descendants) are capable of doing this. For example:
xterm -e mutt
rxvt -e mutt
gnome-terminal -e mutt
(2) Convince Window Maker that the resulting terminal window is not a
regular terminal window, but rather some other program instance.
Both xterm and rxvt are also capable of doing this. Make sure
that -e is the last command option. For example:
xterm -name muttTerm -e mutt
rxvt -name muttTerm -e mutt
gnome-terminal --name=muttTerm -e mutt
This causes the instance of the terminal window that you start to
have an <instance-name>.<class-name> pair of `muttTerm.XTerm'
(usually rxvt's class is also XTerm; don't know about its
descendants, such as wterm and Eterm).
Do not use spaces or periods in the instance name. For example, these are BAD instance names:
xterm -name mutt.term -e mutt
rxvt -name 'mutt term' -e mutt
Window Maker will not like you if you use them.
With a different instance name, you can now do the following:
- Dock the resulting appicon in the dock, or clip it to the Clip.
- Assign a different icon and different window properties to the `special' terminal window running your program (make sure you choose the exact `muttTerm.XTerm' window specification in the Attributes editor).
- Specify different resource settings for muttTerm in your ~/.Xdefaults file (e.g., different default foreground and background colors).
There are a few other non-key things you can do to complete the process:
(3) Tell the terminal window to display a more meaningful or prettier title and icon title than what gets put there due to `-e'. For example:
rxvt -title 'Mail (mutt)' -n 'Mail' -name muttTerm -e mutt
Xterm works the same way.
(4) These are getting to be a lot of command-line options. Make a wrapper script to use so you don't have to remember them all:
mkdir ~/bin
cat >~/bin/muttTerm <<EOF
#!/bin/sh
rxvt -title 'Mail (mutt)' -n 'Mail' -name muttTerm -e mutt
EOF
chmod +x ~/bin/muttTerm
Now you can do the same thing as that really long command in [3]
above using the simple:
~/bin/muttTerm
If you put ~/bin in your PATH, you can use the even simpler:
muttTerm
(5) If you want to be sly, you can change the docked muttTerm to use
your new wrapper script instead of the really long command; then,
when you want to change anything in the really long command
except for the instance name, you can just change the wrapper
script, and it's done. Here's the procedure:
(a) [RightButtonDown] on the muttTerm dock tile
(b) Choose `Settings...'
(c) Replace the text in the `Application path and arguments' field with the following:
muttTerm
(d) Choose `OK'
Note that Window Maker needs to know that ~/bin is on your PATH for this to work; you may need to exit your X session and start it again.
To change the instance name of the terminal window (e.g., from `muttTerm' to `mailTerm' or `blah' or `terminalWindowRunningMutt'), you need to do the following
(e) Change your muttTerm script (f) Undock your old muttTerm
(g) Run your muttTerm script
(h) Dock the resulting terminal window
(i) Do the stuff in [a] through [d] above again.
Good luck.
Thanks to Jim Knoble for this answer.
1) Right click on the title bar
2) Click ``Attributes''
3) Select ``Advanced Options'' from the pull down menu
4) Select ``Emulate Application Icon''
5) Click Save
and older netscapes should now produce an application icon.
If you are using a newer rpm from Redhat Linux, try running
grep irix `which netscape`This seems to have been introduced in their 4.7 update. Comment out irix-session management restart netscape. Alternatively, you may run either
/usr/lib/netscape/netscape-communicatoror
/usr/lib/netscape/netscape-navigatordepending on which rpms you have installed.
without being prompted for the password, you can use ``ssh-agent'' and``ssh-add'' as follows.
With the addition to ~/.xsession of
eval `ssh-agent` ssh-add /dev/nulljust before
exec wmakerThen ssh will no longer prompt for the RSA-key passphrase. The ``/dev/null'' argument to ``ssh-add'' causes it to use the ``ssh-askpass'' graphical dialog.
The following procedure shows how to dock a remote xterm using ``ssh''. This procedure should work well for any well-behaved X11 application, including most Dock applets.
1) From a terminal window, start an ssh session with ``xterm'' as the command:
ssh -a -C -X remote.example.net "xterm -name blah"
(The '-a' switch turns off agent forwarding, for security reasins and
the '-X' switch turns on X11 forwarding, required for the remote xterm
to run. The -C option turns on compression, very
useful for things such as X)
2) When the remote xterm appears, find the appicon. If it's not already in the Clip, drag it there.
3) [RightButtonDown] on the appicon and choose 'Settings...' from the menu. Note that the 'Application path and arguments' field contains only:
xterm -name blah
Change that to:
ssh -a -C -X remote.example.net "xterm -name blah"
The backslashes and double quotes are critical. Change the
contents of 'Command for files dropped with DND' in the same
fashion, putting '%d' inside the double quotes.
If you wish, change the icon so that you can recognize the tile easily. Press 'OK'.
4) [RightButtonDown] on the appicon again and choose 'Keep Icon(s)'.
5) Exit the remote xterm. The new Clip tile should remain, with the three dots at the lower lefthand corner to indicate the app is no longer running.
6) [DoubleClick] on the new Clip tile. You should get the remote xterm again after a short while, depending on the speed of your network and of the remote machine.
7) You may either leave the remote application in the Clip, or drag it to the Dock.
[NOTE: You should be wary of docking something like ``wminet'' or ``wmnet'' in the manner, since you may create a feedback loop by causing additional network traffic, which the program monitors, causing yet more network traffic... ]
To remedy this,
1) Bring up the ``Attributes'' menu. You can do this by [Right Clicking] on the title bar and seletcing ``Attributes''. Alternatively, you may hit 'Control+ESC' at the same time to bring up the title bar menu on apps that do not have a title bar.
2) In the ``Window Attributes'' menu, select ``Skip Window List''
3) Push ``Save'' and then hit the close dialog window icon in the upper right corner of the window frame.
Now the window will not take focus when switching workspaces.
[NOTE: this will also make the window non-focusable via keyboard window
switching. The only way to shift focus to the window is via the mouse. ]
See the theme-HOWTO for an in-depth walk-through on making a Theme archive.
Use your favorite variation of the following:
gzip -dc "Theme.tar.gz" | tar xvf -Note that directory may differ on different systems
You can check this by the following command
ldd `which wmaker`If libjpeg is not listed, you will need to install libjpeg that is available from ftp.windowmaker.org
In this walk-through when I use WindowMaker/, it can refer to the global /usr/local/share/WindowMaker/ directory or the users own ~/GNUstep/Library/WindowMaker/ directory.
To make a Theme.tar.gz, these are the steps I take:
1. Optionally create a README for your theme in WindowMaker/, call it something like "ThemeName.txt"
2. Use the following command to add the Theme files to your .tar file.
tar cvf ThemeName.tar ThemeName.txt Themes/ThemeName
Backgrounds/ThemeNameBG.jpg Backgrounds/ThemeNameTile.xpm
You can add as many more images as you need from the
appropriate directories under WindowMaker/ following that general
idea. You can even optionally add an IconSets/ThemeName.iconset and
it's associated icons to your theme in the same manner. This should
be stated in your README if you decide to include these.
3. Then gzip your .tar file to make your ThemeName.tar.gz file with this command:
gzip -9 ThemeName.tar
4. Now give it to your friends!
#define USER_THEMES_DIR ~/GNUstep/Library/WindowMaker/Themesin your wmmacros file.
First, the Meta+Number combination will switch between desktops. The Workspaces menu will also let you switch workspaces. Lastly, the clip will also scroll one through workspaces. For those that would like to send an application to a specific workspace, either drag it to the edge of the desktop onto the next workspace, or right click on its title bar, select 'Move To', and click the workspace you want it to be moved to.
However, Window Maker does support KDE and GNOME protocols, including their workspace management, so you may use their pager in conjunction with Window Maker in these. Note that in order for this to work, you must enable support when you configure Window Maker (using the --enable-kde and --enable-gnome configure options).
Note also that the Blackbox pager application will work with Window Maker.
getstyle > current.styleTo replace the current style, use the command
setstyle filename.style
libPropList was removed from Window Maker because other programs also use it, such as GNOME. If libPropList is distributed with wmaker, it would cause problems with whatever version of libPropList you already had installed.
Now, there is no more GNOME libproplist and Window Maker libproplist. There is only libPropList which is worked on as a single community effort.
We do not distribute a simple diff with the binary files separately (and variations, like uuencoding the binary files) because a) it is more complicated and error prone to require the user to manually move the files to the correct places b) the current patch package scheme does distribute the binary files and diff files separately. If the user wants to install everything by hand, nobody will object to that and c) sooner or later someone will certainly ask for a script to automate the file moving stuff.
So we hacked a script (mkpatch) that automatically creates a patch package with the normal text diff file, a list of removed files and the binary files that have changed or been added, plus a script that does the patching automatically. If you don't like the script, you can apply the patch and move the files manually. Or download the whole distribution.
Note that you must enable this support at compile time with the proper arguments to configure (--enable-kde and --enable-gnome).
You can use the GNU debugger "gdb" to get exact information about how and where wmaker crashed. Sending this information to the developers is the most convenient way to help in debugging.
The wmaker binary needs to be compiled with debugging turned on ("./configure --with-debug etc.") for this to work.
Exit wmaker and start a failsafe X session with an open xterm.
First type the command "script" to log the following session into a file commonly called "~/typescript". Then enter "gdb wmaker" at the shellprompt:
[shell prompt]~ > script Script started, output file is typescript [shell prompt]~ > gdb wmaker GNU gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-pc-linux-gnu"... (gdb)At the gdb prompt simply type "run" to start the WMaker session:
(gdb) run Starting program: /usr/bin/X11/wmakerTry to reproduce the error which has provoked the crash before and if you succeed the session will simply freeze and you will see something similiar to following prompt:
Program received signal SIGSEGV, Segmentation fault.
0x809ea0c in WMGetFirstInBag (bag=0x0, item=0x811e170) at bag.c:84
84 for (i = 0; i < bag->count; i++) {
(gdb)
Now you just type "bt" for "backtrace" and gdb will show you where the
crash happened:
(gdb) bt #0 0x809ea0c in WMGetFirstInBag (bag=0x0, item=0x811e170) at bag.c:84 #1 0x807c542 in wSessionSaveState (scr=0x80c28e8) at session.c:299 #2 0x807bd88 in wScreenSaveState (scr=0x80c28e8) at screen.c:1089 #3 0x807cf54 in Shutdown (mode=WSExitMode) at shutdown.c:111 #4 0x8078101 in exitCommand (menu=0x80f7230, entry=0x80fdb38) at rootmenu.c:193 #5 0x8078403 in wRootMenuPerformShortcut (event=0xbffff360) at rootmenu.c:401 #6 0x80630f7 in handleKeyPress (event=0xbffff360) at event.c:1492 #7 0x8061c86 in DispatchEvent (event=0xbffff360) at event.c:232 #8 0x8093092 in WMHandleEvent (event=0xbffff360) at wevent.c:585 #9 0x8061dae in EventLoop () at event.c:322 #10 0x806b238 in main (argc=1, argv=0xbffff404) at main.c:594 (gdb)To quit the debugger just type "quit" and say "y":
(gdb) quit The program is running. Exit anyway? (y or n) y [shell prompt]~ >To quit the script session type "exit" again:
[shell prompt]~ > exit exit Script done, output file is typescript [shell prompt]~ >Send the resulting "~/typescript" together with a concise explanation about how to reproduce the bug (please use the included BUGFORM for instruction) to the developers.
"You must define the WM_CLASS (XSetClassHint()) and the CLIENT_LEADER or XWMHints.window_group properties, which are automatically set by most applications that use Xt (Motif, Athena ...), but if you use plain Xlib you must set them by hand.
Also you must make a call to XSetCommand(dpy, leader, argv, argc);
Take a look at WindowMaker-0.12.3/test/test.c that is an example for writing such an app (which also have an app menu).
The main window (normally this is called '.' [dot] in tk) should use the following lines:
wm command . [concat $argv0 $argv] wm group . .All child windows attached to the same app-icon should use:
toplevel .child wm group .child .where .child should be replaced by the actual window path.
Replace '.' with the actual main-window path and 'wm group .child .' should be added for each 'toplevel .child' call.
It is the widget library written for the widgets in Window Maker.
It is currently under heavy development but several people have started writing applications in it. Its goal is to emulate the NeXT(tm)-style widgets.
http://www.ozemail.com.au/~crn/wm/wings.html is the closest thing to an information center about WINGs. You can find out more information in our WINGs development section.
The purpose of this list is to provide a forum for support, ideas, suggestions, bug reports etc. for the WINGs widget set library.
To subscribe to this list, send a message with the word ``subscribe'' in
the _BODY_ of the message to: <wings-request@postilion.org>.