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. 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 :).
>
>   
ok, I got a bit confused on how you wanted to split kxkb. Yes, I am 
currently working to split it into at least 4 parts: x11/xkb helpers, 
configuration (kcm), UI for switcher and engine for switcher so that 
it'd be easier to maintain, reuse and have better performance. I've got 
some progress last night and I'd be glad to make switcher as light as 
possible but I am not sure I can completely move out libxklavier to kcm. 
Besides only at first step I was going to use libxklavier for parsing 
configuration, next I'd like to use some of its (may be future) 
switching abilities. Still I hope for 3.5.2 I'll be able to have 
switcher without libxklavier.
I think I'll know better by next week.

Andriy