Broken software

Can't type into queries

I can't type into queries! (After upgrading unbuntu.)

This is an Xlib locale support problem. You have to specify the encoding as part of the LANG or LC_CTYPE setting; otherwise Xlib will be confused. That is, you should change

LANG=en_GB

to

LANG=en_GB.UTF-8

or similarly, depending on the actual language and encoding used, etc.

Shell leaks

Ion leaves a redundant shell running for every program it starts.

Your problem is a crappy shell that doesn't automatically exec when there's just a single command to run. Fix it, or change /bin/sh point to bash. Ion will not include workarounds for problems that can easily be fixed elsewhere.

Winprop matching

I've set up winprops with the correct class/role/instance etc., but it seems that Ion isn't matching against them.

Most likely the application is setting up the above-mentioned matching information only after it has mapped the window, i.e. told the window manager to start managing the window. This is obviously too late, but all to common with Gtk crapware.

Modifier releases

Ion doesn't notice that a modifier has been released (in actions that use kpress_wait, such as META+C, or in “grabmenus”).

This is most likely to be an X bug/keyboard misconfiguration, when you have changed the “META” key of Ion to Mod4, or something else that supposedly has one of the Win-keys bound to it. For some reason, Xorg comes with some totally broken stock keyboard layouts that define multiple keycodes for the Super_L and such “keysyms”, one of them spurious. However, various parts of X or Xlib can not handle that, and report the wrong keycode when queried.¹

To check if this is the case, first run xmodmap to check what key is bound to the Mod4 (or perhaps Mod3 depending on the configuration) modifier. You may see a line like this:

mod4        Super_L (0x7f),  Hyper_L (0x80)

The number 0x7f=127 is the keycode, and this is highly likely the wrong keycode. Check with xmodmap -pke|grep Super_L to see what keycodes have Super_L bound to them. If you see something like this, your keymap is misconfigured:

keycode 115 = Super_L
keycode 127 = NoSymbol Super_L

The keycode 115 is the keycode for the real left Win-key, and 127 is spurious. However, the modifier subsystem only seems to see the latter. Putting the following commands in ~/.Xmodmap and runnning xmodmap ~/.Xmodmap should fix the issue. You may also want/need to repeat this for the other Win-keys (and the possibly completely non-existent Hyper_L above).

remove mod4 = Super_L
keycode 127 = 
add mod4 = Super_L

(The remove command is needed for some reason to not confuse X.) Unless your system configuration is totally weird (and I wouldn't put it past systems built to run Gnome), next time you start X, ~/.Xmodmap should be loaded automatically. On a working modifier configuration running xmodmap should display a line like below (0x73 following Super_L being the important part).

mod4        Super_L (0x73)

Font display problems

In an UTF-8 locale, Ion displays some characters incorrectly.

The particular effect you're referring to, is likely not an Ion bug. Ion doesn't display the characters, and does very little mangling too.¹ The effect is more likely an X(lib) bug. For some reason, with some fonts, X(lib) decides to substitute certain characters with multiple characters, that do not even appear to depict the original (e.g. two parentheses are seen often). So, file the bug to X.org, and make them fix their broken code. (They might not bother: the trend seems to be to force everyone to use Xft shite and blurred fonts.)

Tray icons

Tray icons are not showing up in the statusbar.

If you would care to follow the instructions for reporting bugs, you would most likely notice that ditching Gnome solves the problem. Ion does not and will not support the ultra-complicated wheel-reinventing FDO/Gnome tray specification (and in particular the result of illiteracy and a very serious case of NIH syndrome or brain damage: XEmbed). Only the simpler old KDE protocol and the Window Maker dockapp protocol are supported. Other windows can be redirected into the statusbar with winprops, as instructed in the documentation. However, the FDO/Gnome crap completely bypasses the usual window management protocols, and hence Ion is completely unaware of it. If you absolutely want to run Gnome crap, there exist external programs for that.

Font loading

Ion can't find any fonts

This is not an Ion problem. The two most likely culprits are a) gnome-settings-daemon or some other gnome component messing up Xorg, or b) totally broken Ubuntu Edgy Xorg configuration files.

GTK2 focus bug

Focus does not seem to be set correctly when there are multiple Mozilla or Gnomefox (i.e. Firefox) windows in a frame.

This is a bug in GTK2 that was finally fixed on 2005-05-05 (and reported over two years before that date). Get a release of gtk2 after that date, apply the patch from bugzilla, or switch to a better browser and toolkit.

Reporting bugs

How to report bugs and other potential problems?

Problems should be reported on the mailing list, directly to me (tuomov), or on the IRC channel, if you are patient enough to wait for somebody to respond. Always mention the version of Ion you are using, and anything else you consider relevant. To solve certain common problems, and for more specific information needed in some other cases, use the following chart:

1. Are you using the latest version (of Ion3 or Ion2)?

   No. Then do so.

   Yes. You may proceed to the next step.

2. Have you applied unsupported patches from elsewhere? (Such as an Xft patch.)

   Yes. Remove them and come back again.

   No. Next step, please.

3. Does Ion die with a segmentation fault?

   Yes. Obtain a backtrace from gdb and send it along with other relevant detail. You must have compiled Ion with debugging symbols (default in development releases). If you have enabled core dumps, simply run gdb -core the_core_file path_to/bin/ion3 and then run backtrace full in gdb. If you have not enabled coredumps, you have the options of running Ion from within gdb, enabling coredumps (ulimit -c 10000, for example, before starting Ion), or trying to attach gdb to the process before it dumps core, and trying to reproduce the problem.

   No. Go to next step.

4. Is the problem Gnome-related?

   Yes. Goodbye.

   No. Next step.

5. Did you run any Gnome software in your session (especially gdm or gnome-settings-daemon)?

   No. Please report the problem.

   Yes. Remove all Gnome software from your system. Then go to next step.

6. Does the problem persist?

   No. Problem solved.

   Yes. Please report the problem.

Window flashing case 2

A program is not responding to anything after having mapped (made visible) a window under Ion. Either graphics are also not updated on the window or they're flashing rapidly.

The program may be fighting with Ion over window size. The ICCCM says:

The response of the client to being resized should be to accept the size it has been given [by the window manager, if any] and to do its best with it. Clients must not respond to being resized by attempting to resize themselves to a better size. If the size is impossible to work with, clients are free to request to change to the Iconic state.

Thus, if this fight is the source of trouble, the program is not conforming to the ICCCM. It is therefore seriously broken and should be fixed.

See also: Window flashing case 1.

XTerm race condition

My XTerm is 80x24 while the frame is much bigger/Program Y doesn't resize to fit the frame.

This is (most likely) a bug in the program in question. It seems that some programs expect the initial size of their windows to be that requested and ignore early size change events. But this is exactly what Ion does. Inform the authors of the program in question that their software is broken and not complying with the ICCCM. In case of XTerm the problem is due to an internal race condition between two processes. There is a fix to xterm but it seems that every second release of XFree86 is broken again.

Window flashing case 1

When I open a dialog from application A Ion starts quickly switching between this dialog and the main window.

The application is flawed and tries to manage its dialog windows instead of letting the window manager do its job: the dialog doesn't have the transient_for hint set and when Ion displays this window, it unmaps (hides) the main window. The broken application now thinks that the user wants to hide the whole application instead of just the main window and therefore unmaps the dialog. But as the dialog is unmapped Ion switches back to the main window and now the application wants to show the dialog too. We have a loop.

See the configuration manual for details setting up the “acrobatic” winprop to fix this.

See also: Window flashing case 2.

Qt drag and drop

Drag&drop doesn't work under Ion in KDE apps.

This is a bug in Qt prior to release 3.3.5. The problem was that they didn't really check in what window within the WM frame stuff was dropped on, but simply took the topmost-stacked window to be it. (Subwindow lists from X are ordered by stacking). However, most programs (including xprop and xwininfo) equally stupidly take the lowest-stacked window, and Ion arranges for the visible main window to be lowest-stacked. (This is also why xprop and friends don't work on transients.) Anyhow, Qt should have been at least “fixed” to behave brokenly similarly to other apps. Or maybe it's been properly fixed to actually find the target window on the list, I don't know.

Transient problems

Dialogs appear in the wrong frame or alone as a new main window instead of at the bottom of another window that the dialog is supposed to have sprung from.

Again, blame the program in question for not setting the transient_for hint correctly. You should ask the authors of the program in question to fix it, but in the meanwhile, you could experiment with the transient_mode winprop. (Note that Ion does not and will not support the “Extended WM hints” brain-damaged in-violation-of-ICCCM multi-parent transient notion.)