Closed run4flat closed 10 years ago
that's a bug somewhere else, setting font inside paint is guaranteed not to propagate anything
thanks for the catch!
it would work without $::application, but worse - it won't recognize GUI font semantics, so without GUI a font request f.ex. "MS Shell Dlg" 10x20 will result in f.ex. "Helvetica" 12x20, where as with GUI it wil be more likely transformed to "Helvetica" 20x20.
In the process of figuring out a gui font ratio (
_get_gui_font_ratio
), line 1288 ofPrima::PS::Drawable
sets the application font to the requested font. Unfortunately, changing the global font kicks off a series of events which can lead to an infinite loop. The infinite loop occurs, rather unsuspectingly, inPrima::FileDialog::Directory_FontChanged
, which tries to pear down the string with fewer and fewer...
abbreviations to accommodate the desired font size. For very large fonts, it's simply not possible to pear down the string to something short enough to fit.Given that this happens during postscript creation, I highly doubt that changes to the FileDialog were ever expected to happen. :-)
I have two ideas. One, I wonder if there is a better way to query font information other than changing
$::application
's font. I would guess this works with$::application
because it can trust that$::application
always exists; would it be possible to create a global, always hidden widget for this purpose instead? Also, would that work if I am trying to build a postscript file without actually invoking the GUI? Two, as a hack, it might be possible to set some sort of$::application::ignore_font_change
global, which could be queried by later functions (such asDirectory_Fontchanged
) so that they ignore the presumably temporary change.