update on kxkb (was: is new lib dependency possible for 3.5.2?)

[Andy Rysin]

Nicolas Goutte wrote:

>On Sunday 29 January 2006 19:03, Andriy Rysin wrote:
>
>>Nicolas Goutte wrote:
>>
>>>On Sunday 29 January 2006 17:02, Andriy Rysin wrote:
>>>...
>>>
>>>>But there's another question here. New xkb config in XML (available
>>>>since 4.3 and which will be used if libxklavier is in) has translations
>>>>for layouts, models etc. Currently all those are translated with
>>>>I18N_NOOP, so the question is whether we want to use old way of
>>>>translating everything via KDE I18N_NOOP or should we try to find native
>>>>xorg translations first?
>>>>        
>>>>
>>>From what I have understood, you mean that libxklavier's source will not
>>>be part of KDE's source code. So the translation is not a KDE matter
>>>either.
>>>      
>>>
>>no - libxklavier is not part of KDE's sources, and yes - translation is
>>the matter of KDE:
>>    
>
>good, tehn I think it was very useful that I have started this discussion 
>about the new user.visible strings.
>
>...

ok, little update on i18n in kxkb, so far without taking to account libxklavier yet I'd need two more visible strings in kxkb for 3.5.2 in regard to new feature to allow user switch same layouts with different variants (this feature was introduced though broken in 3.5.1) so rewritten the code to make it better and a bit more useful for the user:
Column header "Variant" and default variant "<default>" I hope it's ok. We could probably live without both of them but they provide cleaner UI for variants.

Also I'd like to update everyone on the status of kxkb for 3.5.2: 
updated code with bug fixes, optimizations and improvements is almost ready, it's being tested and I'm looking to check it in some time this week.
Taking that the main change was refactoring the code to make it more clear, modular and have propper debugging output to find problems. From this point it'll be easier to:
- make intergration with libxklavier (I am still checking out if it makes sense to do it in 3.5),
- do some (more) optimizations on speed and size
- fixing some more major problems which are not kxkb-only (like problems with hotkeys without latin group in the layout)
- and possibly create kpart to reuse kxkb widget in other places (like kdesktop/lock)

last three most probably won't make it in 3.5 and would have to wait for KDE4

Andriy