Version: (using KDE 4.2.2) OS: Linux Installed from: Compiled From Sources The worldclock plasmoid initializes the font size in a dynamic way, by increasing the size of the font until it's big enough. ( worldclock.cpp: 289-310) The "helvetica" font family is hardcoded and there is no check that ensures it to be installed in the system. If this is not the case the for loops around lines 289-310 will never terminate and plasma freezes. --J
I don't know whether or not it is standard not to have the helvetica font installed, but maybe using the default font could just be a nice solution.
I picked Helvetica because it is aesthetically pleasing to me. I was under the impression that if Qt can't find the correct font it will try to find another font that looks similar, rather than looping infinitely. So if one didn't have Helvetica it would pick e.g. FreeSans or something.
You are perfectly right, the issue is actually something else. In my system Helvetica happens to be a bitmap font (don't ask me why, I really have no idea). So it's probably a misconfiguration of my fonts; however, imo it might be the case to make sure in advance that the font is scalable (passing QFont::ForceOutline as a style strategy seems not to work) for instance by suitably checking QFontInfo in the loop... --J
Reassigning this bug. Did you manage in the meantime to figure out the true cause of this issue?
the "true" cause is again the fact that IF helvetica font is installed as a bitmap font, the loop will cycle forever, since the font will never get big enough as to satisfy the condition to bail out. The code assumes that helvetica, or whatever font replaces it, is an outline font, and that assumption may be wrong
*** Bug 200634 has been marked as a duplicate of this bug. ***
As identified in bug 200634: this bug happens due a Gentoo misconfiguration of fonts.
(In reply to comment #7) > As identified in bug 200634: this bug happens due a Gentoo misconfiguration of > fonts. I believe that, no matter how fonts are configured or misconfigured, plasma should *not* freeze because of such a trivial issue. This is the relevant part of the code (there is a similar piece right before this): worldclock.cpp:307 for ( int curSize = 4; ; ++curSize, ++lastSize ) { QFont font( "Helvetica", curSize, QFont::Bold); QFontMetrics metrics( font ); QRect rect = metrics.boundingRect( timestr ); if ( rect.width() > timeRect.width() || rect.height() > timeRect.height() ) { break; } } I believe that we could already be safe with something like the following: LARGE_SIZE=100; ... QRect oldRect; for ( int curSize = 4; ; ++curSize, ++lastSize ) { QFont font( "Helvetica", curSize, QFont::Bold); QFontMetrics metrics( font ); QRect rect = metrics.boundingRect( timestr ); if ( rect.width() > timeRect.width() || rect.height() > timeRect.height() || (curSize > LARGE_SIZE && oldRect == rect) ) { break; } oldRect = rect; } At this point the font would not scale with the widget, and then it would be ok to blame gentoo for that. Of course there are probably more elegant ways to deal with this problem than the one I propose here, but I think we should at least get started with something concrete. Thanks --J
ping?
as a *WORKAROUND* for us gentooers please check http://christopherowen.id.au/blog/2008/01/22/not-any-helvetica-i-know/
*** Bug 180920 has been marked as a duplicate of this bug. ***
SVN commit 1049582 by nienhueser: Do not assume fonts are arbitrarily scalable. CCBUG: 189633 M +30 -19 worldclock.cpp M +1 -0 worldclock.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1049582
SVN commit 1049584 by nienhueser: Do not assume fonts are arbitrarily scalable. Backport of commit 1049582 BUG: 189633 M +30 -19 worldclock.cpp M +1 -0 worldclock.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1049584