add KLocale method for getting flag by country code?

John Layt johnlayt at
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:

    QPixmap countryFlagAsPixmap();
    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 
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 mailing list