Drop-in replacement for QFontComboBox, better previews

[Chusslove Illich]

(After two days in the hills thinking it over.)

> [: Thiago Macieira :]
> There is a colour palette in Qt and, if an entry is missing, we can think
> of adding it.

Ok.

> The preview font size should be relative to what's being displayed in the
> combobox. I don't see how this is a desktop configuration.

I would think that it is important to have a stable reference when looking
at font previews and judging their apparent size, which means always linked
to one baseline size (that of the general desktop). By its function, a font
preview is effectively an image rather than text.

But I'd better forward to usability, with some context: At present, the font
preview in the combobox is linked with the size of the text for the
container widget. This means the preview will be of different point size if
the combobox appears in the dialog, and when it appears in the toolbar
(where we have smaller font by default).

(Usability folk may stop reading rest of the message :)

> Translations are available in Qt.
> [...]
> [Allowing the user to set the sample text] Unnecessary feature in my
> opinion.

Qt's translation may be sufficient, and this feature unnecessary, when
having in mind a random Latin language. Otherwise, here are some issues that
need to be cleared up along the way:

Same as in QFontComboBox, in my current implementation if the font doesn't
report it supports Latin, it's set not to display the language sample text,
but Qt's internal sample (several characters from one of the supported
script). This must change, e.g. if current desktop language is Serbian
(Cyrillic script), then the fonts reporting having Cyrillic but not Latin
should also show the sample text.

Then, while Cyrillic may be similar enough to Latin to say that a Cyrillic
preview is enough, this certainly does not hold for CJK languages. I suspect
that they will want a Latin sample too, and it's a question how exactly to
provide both. I'd have to check this with people on kde-i18n-doc, then
cross-check with usability.

And when such mixture of scripts can be expected, there also comes the need
to possibly manually specify the text, e.g. CJK users may want to look for a
font containing a character frequent enough to be implemented by general CJK
fonts (unsurprisingly, Dotan, who requested the feature, is a Hebrew
speaker... I think :)

Repeating from IRC for completeness, there's also the localization we need
for generic fonts in KFontChooser, so having it at two places (Qt too) is no
good (I put that on hold earlier, until all the font widgets could be
supported).

So, again, I really think Qt cannot be expected to handle this amount of
locale-dependency.

If by any chance you didn't gave up on me by now for insistance on minutae
detail :), I'd like to know more about too much internal links to
QFontComboBox, which could break. I've seen later your message on IRC,
sounded stronger then in the email.

A possibility would also be to backtrack one level, inherit from KComboBox
instead, totally circumventing QFontComboBox. The most complicated handling
_from QFontComboBox is already in KFontComboBox, and the rest (filtering by
font type and script support) is not to much extra code, and not even used
by anything in KDE repo right now. (Hm, KComboBox also has completion
feature...)

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080508/d7a9e689/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-usability mailing list
kde-usability at kde.org
https://mail.kde.org/mailman/listinfo/kde-usability