is new lib dependency possible for 3.5.2?

Lubos Lunak l.lunak at
Tue Jan 31 10:07:46 GMT 2006

On Friday 27 January 2006 14:49, Andriy Rysin wrote:
> My rough estimation is by adding libxklavier and some code cleanups we
> could fix at least dozen of bugs in kxkb before 3.5.2.
> And Stephan noted right - my idea was to introduce a cascade system with
> new code:
> 1) if there's API from libxklavier - use it as it'll provide best
> (possible cross-X and cross-version) way to interact
> 2) if there's no libxklavier try to use existing X API that provide full
> and correct info - as it'll provide up to date correct data about xkb
> 3) otherwise fall back to old manual config file parsing...

 There's one more thing I'd like to ask. While libxklavier seems to be rather 
small, it depends on libxml2. If I'm getting kxkb right, there are basically 
two parts there, one that handles all the configuration and prepares the 
keymaps in the form of the xkm file and second one that just displays the 
icon and switches the keymap (and that used to just call setxkbmap in the old 
days). Would it be possible/difficult to separate these parts completely for 

 So that the configuration part would be just used when the user wants to 
change something or when the system changes and would prepare and cache the 
keymaps somewhere and only the second part would be normally needed (which 
could then additionally be changed to kicker applet or kded module or 
whatever)? Needing 2M of memory wouldn't make kxkb exactly the most 
lightweight keyboard switcher.

Lubos Lunak
KDE developer
SuSE CR, s.r.o.  e-mail: l.lunak at , l.lunak at
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic

More information about the kde-core-devel mailing list