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

[Andriy Rysin]

Lubos Lunak wrote:

>On Wednesday 01 February 2006 01:59, Andriy Rysin wrote:
>  
>
>>Lubos Lunak wrote:
>>    
>>
>>> 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 KDE4?
>>>
>>> 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.
>>>      
>>>
>>I think that's very reasonable request, I'll try to make it as modular
>>as possible. The only questions is if we want to split *kxkb.so into two
>>libraries for that, which may take more memory and CPU instead?
>>    
>>
>
> 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.

> All the remaining functionality like 
>configuring, preparing keymaps for kxkb would be done in kcm_keyboard (or 
>wherever you want actually), kxkb would only do some check that the prepared 
>keymaps are ok and if not it'd run this second tool to generate them. The 
>basic idea is that kxkb is as simple as possible and without dependencies on 
>things like libxklavier/libxml2, the rest are details :)
>  
>
too nice to be true, the world still seems to be unperfect :)

Andriy