add KLocale method for getting flag by country code?
johnlayt at googlemail.com
Mon Feb 22 13:12:14 GMT 2010
On Sunday 21 Feb 2010 16:52:46 Andriy Rysin wrote:
> It seems there's at least 3 places in kdebase and 3 places in kdelibs where
> the code gets the flag by country code by "concatenating" locale dir, l10n,
> country code and flag.png
Here's my quick grep of flag.png in KDE:
KTimeZoneWidget : timezone selection list, uses QPixmap/QIcon
KHTML : language display, commented out, uses QPixmap
xkbd : keyboard layout selection list, uses QPixmap
KHelpCenter : language selection combo, uses QPixmap/QIcon (not used?)
KCM Locale : country selection list, uses KIcon
parley : language/country flag selection combo, uses QIcon
kget : country selection combo, uses KIcon
localize : language selection list, uses QIcon
ktorrent : country selection, uses QString / QPixmap in a special DB
You also have KGeography, Marble and KTorrent with their own flag sets.
Anyone know of any more?
Basically, there's two clear use cases for flags:
1) A small flag to be used in combos and lists to help users identify
countries (often also languages and currencies but that's a poor use).
2) A large detailed flag for applications like Marble and KGeography which
needs to look good and work at different sizes.
The flags for 1) are what KLocale should provide. A single set of high-res
flags for 2) are obviously a nice-to-have but shouldn't be in kdelibs or
kdebase-runtime due to file sizes.
Using flags for languages is not a great idea, it gets quite political when
you have multiple languages per country and multiple countries per language,
which do you choose?
> Would that make sense to add a method to KLocale, e.g. QString
> getFlagFileName(const QString& countryCode) (khtml_part is only taking the
> file name to use it in <img> tag) and possibly QIcon getFlagIcon(const>
QString& countryCode) ?
I've thought about it, but put it off as we have other issues around
flags I wanted to think about first before committing to an api.
The actual code is really not too hard, which is why I wasn't too worried
about providing api:
QString fileName = KStandardDirs::locate( "locale",
QString( "l10n/%1/flag.png" ).arg( countryCode ) );
The simplest api would be to just return the file path and let the app decide
if they want it wrap the call with a QIcon() or or QPixmap() or whatever.
However, I'm in two minds if passing around specific file paths with specific
file types is a good thing, apps might depend on them being in that particular
format or location (as they currently do) when we may later want to change
location or format? Perhaps only returning a pixmap or icon is better?
We'd need a static version for any country code, and a convenience no
parameter version that returns the current locale's flag. For example:
static QString countryFlagAsPixmap( const QString& countryCode );
There may even be enough demand there for a standard KCountryCombo widget for
selecting countries, with optional flag display, e.g. kaddressbook has one as
well but doesn't show flags. Or move the KCM Locale CountrySelectorDialog to
OK, so that's the lo-res flags, what about the hi-res ones? Within KDE svn we
currently have 4 sets of flags I know of:
Small lo-res (approx 21x14 pixels) png for each supported locale country, no
subdivisions or other entities. Named "flag.png" rather than including the ISO
country code in the name and tied to the locale directory, which makes
extending support to other entities (EU, UN, etc) or subdivisions (States,
Provinces etc) or sizes harder. These are guaranteed to always be installed
at runtime. About 1Mb in size.
Large resolution png files (approx 300x200 pixels). Named with country name
and not country code. Includes a number of subdivisions. Derived from the
sodipodi and wikipedia svg files. About 10Mb in size.
Svg files derived from wikipedia and openclipart, appears to have an auto-
download script from wikipedia. Named using country code. No subdivisions.
About 5Mb in size.
Small glossy/3D themed png flags (all 18x12). Named with country code. No
subdivisions. About 1.2Mb in size. Source http://www.hahn-hotel.com/flags/
which does have some subdivsions.
As has been discussed in the past, the ideal long-term solution would be to
merge all these into a single resource:
* Based on Marble SVG files, supplemented with subdivision files from
* Possibly new library in kdesupport that apps depend on if needed, not
required by kdelibs or runtime. Or could be an fdo project?
* Master flag file in SVG format
* File names to include ISO country / subdivision codes
* Default set of pre-rendered optimised small scale pngs (as may need details
simplified to look good)
* API to either request flag at a required resolution and format, with on-the-
fly conversion from svg, and/or return the svg for the app to use directly
(It's not possible to specify an exact required size, as flags come in
different ratios, so it would have to be a max size in 1 or 2 dimensions.)
I'm no expert on svg, I'm assuming performance is now good enough for most use
cases for larger scale flags, i.e. showing one or two at a time? Can you
theme the flags (e.g. in Oxygen style, 3D, waving, etc) either by simple pre-
processing or on the fly?
I think we'd still have to install the small pngs in the existing l10n install
directory, I assume it's part of our compatibility guarantee that these will
always be there? Or can we move and rename them to something more logical?
And yes, this all ties into the ISO country subdivision codes and KHolidays
stuff I'm looking at :-)
More information about the kde-core-devel