In old versions of AfterStep, an icon to be used in Wharf must contain at least one transparent pixel; otherwise the symptoms you've mentioned will turn up. Simply add a transparent pixel and everything should work flawlessly.
Newer versions of AfterStep fix this problem, allowing you to use icons without transparent pixels in the Wharf. You should really upgrade to the latest version.
Yes, I (Andrew) know that "colour" is spelled incorrectly here. I can't help it that those who set up X and Linux spell incorrectly.
Odds are you are using a 256 color (8bit) display. A quick explanation is that you can only have 256 colors on the screen at the same time, and the more colors you use in Wharf (the button bar), the fewer you can use for other applications and icons. I would suggest upgrading your video hardware or using more conservative (less colorful) icons. For netscape, an option is to run it with the 'netscape -install' command. This will ensure that netscape gets a good deal of the color that it wants. It will, however, also result in the colors flashing whenever you move the mouse in or out the Netscape window. You decide whether you can live with that.
One trick, it seems, is to run AfterStep without a Wharf. That reduces the number of colors used at any one time.
You might want to use low-color icons, as well; you can find a good collection of low-color icons (all of them together use only 21 colors) at http://the-labs.com/AfterStep/.
If you are using asclock, you can configure it to use fewer colors. See below.
After version 1.4, AfterStep uses config. files ending with "8bpp" for 8 bit displays, and low-color icons from icon/8bpp. You can modify these files to use fewer colors.
So far, no solution has surfaced to this problem. It appears that AfterStep
is not handing over control of the display. There seem to be other related
problems of this nature, mostly on Suns. Any additional information would be
appreciated: Gerhard den Hollander ([email protected]) is working on this
problem.
You are most likely running out of colors. Either upgrade your hardware, switch to a higher color depth (i.e. 16 bpp or higher), or use icons that contain fewer colors.
You don't really need to do this any more: the preferred method here is to upgrade your AS version. Still, if you don't want to download, you can fix your problem easily. An xpm is a simple text file. Therefore, the only image manipulation software you will need is vi (or some other text editor). If you edit your xpm, you will become aware of its beauty and simplicity. At the bottom you will notice a character representation of your image. At the top there is a color listing corresponding to each pixel of the character representation.
You have two options to create a transparent pixel:
c None
If you're the slightest bit unsure, take a look at one of the xpm files in the AfterStep distribution's icons directory.
The `correct' size for a Wharf icon is 48x48 pixels. However, if you use bigger icons, they will display correctly, up to 64x64, which is the default size for the Wharf buttons.
See the previous question. Or, if you're trying to convert a compressed file to an xpm, try using an image-manipulation tool like xv or the GIMP.
There are dozens of sites scattered around the Internet which will provide you with useful graphics. Some good links to start with can be found on the official AfterStep home page.
Several 8bpp programs don't work on displays without a PseudoColor visual available. Several PC X servers don't support PseudoColor visuals on displays running in TrueColor mode. You should buy an SGI. Or run two simultaneous X servers, if you're on Linux.
Note for SGI users willing to play with their bpp :
One has to tweak the arguments to X in /usr/lib/X11/xdm/Xservers.
The following worked for Tim Buller ([email protected])
:0 secure /usr/bin/X11/X -bs -c -nobitscale -visid 0x34
Where Visual ID 0x34 (reported by xdpyinfo) is:
visual: visual id: 0x34
class: TrueColor
depth: 24 planes
available colormap entries: 256 per subfield
red, green, blue masks: 0xff, 0xff00, 0xff0000
significant bits in color specification: 8 bits
xv doesn't cope well with 16bpp in three ways. First, it can't grab pieces of the screen. Second, if you grab pieces of the screen with xwd and try to display them with xv, it doesn't work well. xwud works. Third, if you display a 24bpp picture, it doesn't bother to dither it down to 16bpp, resulting in bad pictures. You might want to consider using the GIMP, or xli.
Sorry, but icon names change since AfterStep 1.1. Upgrade.
You need to define an icon for your program in your database file. It's a good idea to define a default icon for all "unknown" programs. In the latest versions of AfterStep, you do this in the database file:
Style "*" Icon Unknown.xpm
In earlier versions of AfterStep, background loading was handled at start-up by invoking another program in the .steprc. While version 1.4 allowed the use of XPMs only, 1.4.4 restored the ability to load jpegs (or whatever) with another program. The catch is that the auxiliary program is defined in configure.h at compile time. Edit the configuration to reflect the accurate path to your favourite image viewing program, and then re-compile AfterStep.
The default program to use is xli. Many people don't have this on their system, and prefer to use xv instead. This choice is still a compile-time option. Moreover, the Pager code is broken in some distributions, so that the jpeg handling doesn't always work.
The loading of backgrounds is handled by the Pager module. If you're not using the Pager, then the backgrounds won't get loaded. In that case, you can make the call to the background-loading program in your autoexec file.
As of this writing, the Pager module is being re-coded to include (native) support for background jpegs. This new pager is included in a patch to version 1.5 beta 4. Version 1.5 will include native support for jpegs.
Note that jpegs don't take any less memory while loaded; they only take less disk space!