is new lib dependency possible for 3.5.2?
Lubos Lunak
l.lunak at suse.cz
Tue Jan 31 10:07:46 GMT 2006
On Friday 27 January 2006 14:49, Andriy Rysin wrote:
> My rough estimation is by adding libxklavier and some code cleanups we
> could fix at least dozen of bugs in kxkb before 3.5.2.
>
> And Stephan noted right - my idea was to introduce a cascade system with
> new code:
> 1) if there's API from libxklavier - use it as it'll provide best
> (possible cross-X and cross-version) way to interact
> 2) if there's no libxklavier try to use existing X API that provide full
> and correct info - as it'll provide up to date correct data about xkb
> 3) otherwise fall back to old manual config file parsing...
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.
--
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
More information about the kde-core-devel
mailing list