FrameSvg corruption [a bit urgent]

[Aaron J. Seigo]

On Friday 16 January 2009, Ivan Čukić wrote:
> We first store the size into s, and then do a q->resize(). Why?

store the size it currently is set at.
reset to the document's natural size to calculate the borders.
reset back to the size it was.

the assumption here, which works with other svgs, is that the borders are a 
fixed size.

so what happens when borders aren't fixed size but are meant to be scalable is 
that when the svg is resized to its natural size, the borders resize to some 
"random" size relative to the actual content they border.

i'm going to guess your borders are scalable elements?

i was concerned when making this change that we'd eventually need a hint to 
differentiate between the two approaches. here's the change in any case:

	http://websvn.kde.org/?view=rev&revision=905645

if you revert that change and switch from, say, oxygen to aya then back to 
oxygen with a folderview on your desktop you'll see the problem pretty 
clearly.

> When those two lines switch places, so that s is the newest size,
> everything is ok. (I'll keep testing whether it is just accident)

yes, it's incorrect. it means the svg would take the natural size the 
document, not the size it had been set to.

-- 
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/20090116/8aac07f4/attachment.sig