Adrian Kubala writes:
If I put the dock on the second Xinerama screen, dockapps which start on the first screen don't get put into it.
I can't test Xinerama features, and have no experience of it so I can't test anything, but.. The 'auto' dock feature causes the dock to absorb dockapps started on the same screen as the dock. If there is no dock on the first screen then the dockapps don't get absorbed anywhere.
You might be able to get around this by setting winprop{target="dock"} for any dockapps you start on the first screen. Alternatively, if someone can tell me exactly how the situation should be handled (e.g. auto docks should absorb all dockapps, whatever their screen) then I'll implement it.
Worse, if dockapps are present before the dock starts (as happens if I start dockapps in my .xsession), the dock also won't suck them up (though probably this is the same problem).
When the dock starts it doesn't try to manage any existing dockapps. I doubt that such a behaviour would be desirable anyway: I can see it leading to all sorts of problems.
The kludge here is probably to delay startup of your dockapps in your .xsession. Something like:
#!/bin/sh
( sleep 5 && wmclock ) &
exec ion
should work, but I haven't tested it.
Regards,
Tom
