refactoring kxkb (Was: is new lib dependency possible for 3.5.2?)

Lubos Lunak l.lunak at
Fri Feb 10 12:25:59 GMT 2006

On Thursday 09 February 2006 14:16, Andriy Rysin wrote:
> Lubos Lunak wrote:
> > Is that xorg.xml a specific file (or a limited number of specific files)?
> > In that case you could cache the values and also timestamps of the files
> > and regenerate them only if some of those files have changed.
> There are two problems with this approach:
> 1) on start of kxkb I would also have to check that translation I have
> in config is the same as current set up by user (unless we want to cache
> all language strings which is just same as having local copy of
> xorg.xml), if language has changed I'd have to load 'rules' library,
> parse it and then unload 'rules' library; same actually and if xorg.xml
> timestamp differs - need loading/unloading the code...

 In 99.9% of cases, there won't be any change at all, because, well, there 
won't be any change at all. Just caching what you need and updating it when 
anything in the global data changes is perfectly fine, it wouldn't be the 
only place in KDE where we do that.

> 2) the idea was to rely fully on mid-tier library to get rules info,
> thus if some day (in a perfect world) we can get this info from X rather
> than from local file we would not be able to use that caching and would
> have to get rules every time kxkb starts, also abstraction from X by
> putting libxklavier in the middle should (potentially) help with
> different versions of X/commercial X servers
> It seems like caching of the local file messages is not elegant solution
> and will not work if we want to be somehow abstracted from local X rules
> file.

 In a perfect world initializing keyboard layout wouldn't pull in 2M more of 
data and wouldn't require an extra process. Or, perhaps, it wouldn't matter. 
But this is not a perfect world and we have many optimizations in KDE that 
are not elegant but do the job for the time being.

 Ok, if you think it's not worth it, fine. Note however that this doesn't 
necessarily save kxkb from ending up in my personal optimization sights one 
day :).

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