your mission, should you accept it, is to go into kdebase/kicker/applets/minipager and apply this patch then do the usual make and make install. from a konsole stop kicker (`dcopquit kicker` works nicely) then start it again.
once it is up and running, maximize a window and then try and use the pager's drag and drop to move the window from one screen to another. when the window is dropped, it won't move (that's the bug!), but you should now see output looking something along these lines in the konsole window:
kicker: desktop is 1024 x 768
kicker: we are: 32x 24
kicker: delta is 256 x 0
kicker: moving to: 369 x 146
then send that to me by email (aseigo at kde dot org). i'll note your name in the commit log when i fix it.
ok, that's the end of the productive part of this blog entry. the rest is best classified as half bitchfest, half brainstorm. ok maybe three quarters bitchfest. ;)
i happened to ask for help on irc as well, but the only people with xinerama i could find were running kde from packages. meh. this is more than a little frustrating for me, to say the least.
in a dream world i'd have a bunch of low-profile machines (i don't have a huge work area here) with different KDE branches, hardware configs and OSes on them. then i could just switch on the "kubuntu with 3.4 branch build" on, reproduce the bug, fix the problem and then switch that machine back off. of course best would be if such a testing lab was physically available to more than just one kde developer, but that wouldn't help me (unless i actually follow through on my long time threat and found a kde hacker kommune)
vmware, NX, etc. probably wouldn't address the problem completely as i need to test things like xinerama. and i'd still need a bunch more disk space to store all the images anyways. i know that OS vendors tend to have tons of test systems laying about, but it seems they don't really test the things i end up having to fix (obviously since these problems persist). as for users doing the testing, well ... they tend to be better at finding problems than they are at fixing them ;) and doing remote testing (like this blog for example) is just so bloody slow. i do appreciate the patience of those who do engage in remote debugging with me, but it feels so inefficient.
in any case, this problem should've been solved in the time it took me to write this. and it would have had i the necessary hardware kicking around. *sigh*