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*
5 comments:
Wouln't it be possible to open two Xnest windows that are combined with xinerama? That way you wouldn't need the physical monitors ;-)
Something like that might work..
Xnest -ac -geometry 640x480 -scrns 2 +xinerama :1
I haven't compiled in xinerama...
Sincerely
Camel
Hello Aseigo.
I'm currently running kubuntu, even if I compile kicker again, i can't help you?
I used gentoo for more than a year before, with xinerama. If you find nobody else, you can mail me and I can set up a gentoo install to help you debug and test.
If you have several machines, you can try DMX. Its built into X.org these days, though I don't know if your distribution has it. I have successfully run KDE under it. However I found it far too slow to use. (Running KDE over a network connection works fine, just DMX needs major optimization before it is useful for the desktop).
For your use though, you
can set it up, using any old machine/monitor has the second head, and only use it when you have bugs to fix. Might be worth a shot.
I just sent you an email with the debug output you asked for and reproduced the bug here. Let me know if there is any more testing you need doing.
Hi Aaron,
I run a xinerama desktop on a gentoo-box with 3.5 at work. If you need further testing just contact me via IRC, applying patches shouldn't be a problem, rebuilding kicker or anything else from svn nonetheless.
david@#plasma
Post a Comment