Well, it is big because it shows the layout. Most of the dialog is the keyboard drawing widget. The rest is just 2 combos.

It is a nice idea to implement searches. How would you propose to do that? Perhaps some mockup?

I made a quick sketch and posted it on the design wiki:
http://live.gnome.org/Design/SystemSettings/RegionAndLanguage

Thanks! Let's discuss it here, if you don't mind.

First, are you saying that grouping/filtering by country/language should be dropped? I am not sure it is a good idea.

Also, what should be in the list when the search field is empty? All layouts/variants? Or nothing at all?

And, the final question - how should "Search" work? There are following possibilities (multiple choice). Please pick the ones you think we should use in search:
1. Country ISO codes
2. Language ISO codes
3. Substring of full description of the layout/variant (localized)
4. Substring of the country name derived from ISO code (localized)
5. Substring of the language name derived from ISO code (localized)

(In reply to comment #3)
> Thanks! Let's discuss it here, if you don't mind.
> 
> First, are you saying that grouping/filtering by country/language should be
> dropped? I am not sure it is a good idea.

I agree with Jon here that it should be dropped. It's not easy to find the right country, or language here.

> Also, what should be in the list when the search field is empty? All
> layouts/variants? Or nothing at all?

Do all the variants have "main" layouts? If so, it might be better to show just the "top" layouts, and have a separate combo box with the variants (and selecting the normal one by default, graying out if there's no variant).

Otherwise we should add everything to the treeview.

> And, the final question - how should "Search" work? There are following
> possibilities (multiple choice). Please pick the ones you think we should use
> in search:
> 1. Country ISO codes
> 2. Language ISO codes
> 3. Substring of full description of the layout/variant (localized)
> 4. Substring of the country name derived from ISO code (localized)
> 5. Substring of the language name derived from ISO code (localized)

1. and 2. would probably show a lot of false positives (or at least what would look like false positives). 3., 4. and 5. sound right even if we only use the "top" layouts. For example, looking for "dvorak" would show me all the layouts with dvorak variants. Looking for "dvorak english" would show me all the layouts that have dvorak variants with english in their name.

> I agree with Jon here that it should be dropped.
Not sure. But we can try of course.

> Do all the variants have "main" layouts?
Yes. It is really 2-level tree
L1
  V11
  V12
  V13
L2
L3
  V31
  V32
But the thing is that variants can belong to different ISO codes. For example, Russian layout is for Russian language, but there are variants for Tatar and other national languages. So, if I search for "Russia" - should I show all variants (in the combo) or not - just because rules #3 and #4 would match the top-level layout (and #4 would match the variant as well, actually)? If I search for Tatar - should I show Russian layout with all its variants (in the combo)?

#1 and #2. Agree, a lot of false positives. Actually we could implement some "hack" - search by ISO codes if the search string is entirely in uppercase.

#3-#5 Dvorak is a very good example - if user searches dvorak, we should show all top-level layouts containing at least one dvorak variant. Should we populate the combo with all variants - or only the dvorak ones?

As we agreed on IRC, the list view should show all the available layouts and their variants, and language, country and variant names be used for the filtering.

The backend in libxklavier is complete. Now it is a matter of UI.

Search-based layout addition is pushed. Please check from git. You need CVS version of libxklavier for that!

I guess at this stage we can close this one. If there are individual bugs in the new implementation, they can be sorted separately.