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

[Andriy Rysin]

Lubos Lunak wrote:

>On Thursday 09 February 2006 05:10, Andriy Rysin wrote:
>  
>
>>Lubos Lunak wrote:
>>    
>>
>>>I'm not sure I get what you mean. Currently there's kxkb (which is
>>>actually more binaries because of kdeinit etc. but that's irrelevant) and
>>>there's kcm_keyboard(?) which is for configuring. My idea is that kxkb's
>>>functionality would be limited to just to displaying the indicator and
>>>doing the actual keymap switch, there would be no dependency on
>>>libxklavier as that's not necessary for this.
>>>      
>>>
>>Got bad news on this.
>>I was hoping this is possible, so I was working on separating kxkb from
>>rules stuff but found one thing: kxkb uses rules code to get name for
>>layouts (displayed in menu/tooltips).
>>In the old approach (w/out libxklavier) I could potentially cache the
>>(english) names in the kxkb configuration with the hope that the name
>>(in X11) would not change between user the runs kcmlayout. The
>>translation for the name will be done on the fly (as it's done now).
>>This solution is not very nice but could work.
>>
>>But if we start using translations for layout name from xorg.xml
>>(whether via libklavier or bu parsing manually) there would be no way to
>>make kxkb run without parsing rules or using libxklavier. Becaus all
>>translation will come from X.
>>
>>I hate to load all that rules parsing just to get names for layouts in
>>kxkb but I see no other way. If somebody can point the solution I'd
>>really appreciate it.
>>    
>>
>
> 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...
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.

Andriy