So it's 2008 and one would think that by now we'd have the whole mult-screen thing figured out in the F/OSS world, right? Hook up a couple of monitors to your machine and go .. right? In a word: meh. In two: you wish.
There are various fundamental issues that include the likes of xrandr failures, driver shortcomings, etc. But there are also some pretty amazingly basic stuff we just haven't gotten to yet.
Just the other week I finally came to fully understand why there are problems with panels on multiple screens: strut reservation is not designed for multiple screens.
Let me back up here a bit and explain what "struts" are: when a panel sits on the edge of a screen it may not want windows to overlap it. So it publishes it's geometry so that the window manager can keep windows out of its way and treat that area of the screen with a bit of extra respect.
Struts used to be very simple: N pixels reserved on the four respective edges of the screen. Now with extended struts we have the ability to note where those reservations begin and end. A panel can, for instance, publish that it wishes to reserve 32 pixels at the bottom of the screen starting 50 pixels from the left and continuing on for 400 pixels.
However, struts are treated as if the desktop space is one big rectangle that includes all screens. That means there is no way to reserve space on the right edge of a screen that sits to the left of another screen. To the strut definition, there is no screen edge there. Sure, the X11 API provides means to know that there is a screen edge there, but the strut mechanism ignores it completely.
I'm about to go fix a bug related to this in plasma, but it will still be hamstrung by this built in limitation.
So we have the old NETWM struts and the newer NETWM extended struts, but still no real multi-screen support. I suppose we need NETWM "complete" struts? =) This seems like a really interesting project to take on, perhaps as part of a Summer of Code project.
Coming up with an extension to the "extended" struts that takes multiscreen systems into consideration and writing a practical implementation of in a window manager (e.g. KWin) would help seal off one more pain point and it would benefit not just KDE but all F/OSS workspace projects (the NET WM stuff is a shared spec hosted at freedesktop.org).