fuzzy clock?

[Marco Martin]

On Monday 22 December 2008, Aaron J. Seigo wrote:
> hi..
>
> who here feels responsible for the fuzzy clock?
eh, i suppose it's the typical thing whose responsible is everybody-and-nobody 
:/
> right now it starts an infinite loop when put into a panel, recalculating
> it's size over and over.

i changed the minimum needed to avoid the infinite resize loop.
i see it's a recurring problem over and over again to all applets that needs a 
specific ratio in the panel, occurred also to the digital clock several times, 
i.e. a resize() when the thing is in a layout is baaaad, but how we can avoid 
the mistake is repeated again and again? :/
aaanyways, as used in the digital clock i've put setMinimumSize instead of 
resize, it has its dangers too, but kinda the only way right now. now doesn't 
look reeally good, maybe fonts a bit too little in the panel, but at east it 
neither eat cpu or destroy the panel layout.

Cheers,
Marco Martin

> i looked at the code, tried a mildly ugly fix that didn't work and then
> just walked away from it because the code is simply unreadable in its
> current state. calculateSize in particular needs some love. breaking it up
> and having proper indentation might be a nice first step.
>
> but the critical problem is that the constraintsEvent is rather broken. it
> doesn't actually check which constraints are being set:
>
> if ( (m_oldContentSize.toSize() != geometry().size() &&
> m_oldContentSize.toSize() != QSize (0,0)) || m_configUpdated == true ) {
> //The size changed or config was updated
>
> c'mon, that's why we have a Plasma::SizeConstraint! and in the config case,
> it's reseting all the constraints, so that should be covered with a single
> check to see if SizeConstraint is involved!
>
> it then goes on to update the size ... when SizeConstraint is set! it then
> cycles through possible font sizes, bottoms out at the minimum font size
> for any rational size panel and resizes .. which causes another
> SizeConstraint to be fired.. GOTO 10.
>
> this needs to be fixed before 4.2 goes out. i can't bring myself to work on
> that code due to the shape it is in given that it's not exactly a critical
> component and so much else is out there to do.
>
> if it isn't fixed by whomever has been working on fuzzy clock, i'll be
> removing it from the 4.2 release.