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

[Nicolas Goutte]

On Thursday 09 February 2006 05:10, Andriy Rysin wrote:
> 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.

I suppose that on long term, for KDE4, you should ask to have an appropriate 
API in libxklavier to do what is needed. (Is KDE really the only one doing 
such manipulations?)

For KDE 3.5.2, well, I am not sure. If you choose to force $LC_ALL to C when 
calling libxklavier, then there is no problem. The drawback is that 
third-parties' extensions will never be tranlated and that KDE 3.5.2 ha to 
extract the messages from the XML file. (But I suppose that for KDE 3.5.2, 
especially in the remaining months or so, we have little choice but to make 
compromises if libxklavier should be used.)


>
> > 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 :)

So you mean that it is kcm_keyboard that need untranslated values, so that 
kxkbcan work,don't you?

>
> too nice to be true, the world still seems to be unperfect :)
>
> Andriy

Have a nice day!