Status of multi-monitor support

[Aaron J. Seigo]

On Friday 10 October 2008, Guillaume Pothier wrote:
> I need help with the containments' coordinate system. Adjusting view
> sizes don't work as expected. Here is a commented log of plasma when I
> resize a screen from 1920x1200 to 1280x800 and then back to 1920x1200:

ok, so here's how it works:

the View has an associated Containment.

when the Containment is first associated with the View, we connect 
Containment::geometryChanged to View::updateSceneRect.

when that is triggered (because the Containment changes size), the View aligns 
its sceneRect to match the new geometry of the Containment and emits two 
signals: sceneRectAboutToChange and then sceneRectChanged.

it is then up to the View implementation to figure out how it wishes to react. 
a PanelView, for instance, never wants to grow bigger than the screen, even if 
the Containment it is showing does, but otherwise wants to adjust itself. a 
DesktopView, however, always wants to be the size of the physical screen no 
matter what.

so how this *should* work is when a screen changes size, PlasmaApp should 
change the size of the Containment which is associated with that screen to 
match the new size.

the DesktopView also needs to change it's size when the screen changes size, 
but should not touch (or even reference) the Containment at all.

without looking at your patch, it's hard to say what's going wrong =) can you 
post it somewhere i can look at it?

> plasma(18904)/libplasma Plasma::ViewPrivate::updateSceneRect:
> !!!!!!!!!!!!!!!!! setting the scene rect to QRectF(1926,0 1280x800)
> associated screen is 0
> // This starts being weird. Where is that 1926 coming from? That's the
> containment's sceneBoundingRect(), but why 1926? Note that at least
> the size is correct.

6 is the margin between Containments on the canvas. the reason this is 
necessary is that antialiasing can cause painting ops to go beyond the actual 
boundary of the item. which means that if there a zero pixel border between 
them, updating one Containment will trigger a repaint in the one(s) next to it 
(and domino on down) ... not good, for obvious performance reasons ;)

the 6 is actually stored in a constant in libplasma called 
INTER_CONTAINMENT_MARGIN

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20081010/084ccb45/attachment.sig