> The question is whether a workaround in KDialog::screenRect replacing
> QDesktopWidget::geometry is in order. I think it won't do any harm to use
> QDesktopWidget::screenGeometry(-1) instead - any objections/suggestions?
> 

Without further ado, I'll reply to myself and suggest a patch replacing a call 
to QDesktopWidget::geometry() with QDesktopWidget::screenGeometry(widget).

I'm a little cautious about patching kdelibs but the reasoning is:
The behaviour of geometry() vs. screenGeometry(widget) is equivalent for non-
faulty behaviour of geometry() (faulty as described in the last mail) in case 
of single-screen setup. In the code changed the return-statement is only 
reached in case of single-screen setup - if I'm not mistaken:


if ( desktop->isVirtualDesktop() &&
       cg.readEntry( "XineramaEnabled", true ) &&
       cg.readEntry( "XineramaPlacementEnabled", true ) ) {
[...]
} else
    return desktop->screenGeometry(widget);

(Read the following paragraph with a bold IMHO prepended to each sentence ;) )
Although this works around a bug in Qt (or somewhere else even) I wouldn't 
call this a workaround, it's only more verbatim to call screenGeometry(widget) 
instead of geometry() especially in a function that takes a widget as its 
argument: screenRect(QWidget* widget, int screen). I also don't think this 
needs to be maintained once the bug is fixed since there is no advantage of 
calling QDesktopWidget::geometry() over calling 
QDesktopWidget::screenGeometry(widget).

Objections and criticism are welcome!