is new lib dependency possible for 3.5.2?

[Andy Rysin]

Thiago Macieira wrote:
> Stephan Kulow wrote:
>>> If the feature is really necessary, then maybe you could just copy
>>> over the relevant sections?
>> Where did you read feature in what Andriy wrote? It's about replacing an
>> own parser with a lib that does exactly that - and does it better as
>> it's maintained by the same guy maintaining the xorg rule files these
>> days.
>
> "Feature" maybe wasn't the right word. What I meant is if this new parser 
> is really necessary in the form of an external library, or at all.

Well, Stephan got the point, the current parser in kxkb is quite ugly due to constant small code changes to keep up with xkb configuration changes that were made in X 4.3.x series and implementation of new feature requests. API calls in libxkbfile pretty much useless (except for top-level objects) for current situation with kxkb. So parsing a lot of X config files manually breaks more and more as new versions of X released and distros make changes in xkb file structure on their own (SuSE case BUG: 117468).
Potentially we could rewrite the parser the way it is in libxklavier but:
1) I don't see why do double work if library already exists and proved to be reliable
2) as Stephan noted right the lib is written by guys who maintain xkb rule files in xorg so that means it'll stay up to date
3) it's extremely hard to keep compatibility with old and new versions of X in parsing xkb rules the way it is now, and library is suppose to do that for us, besides libxklavier is used in GNOME so we got much bigger testing bed for rules parsing... (well I don't think I have to explain why using common lib is better then do it on your own)
4) rewriting and testing new parser on my own would not make it for 3.5.2, and it'll take a lot of time of KDE4 development which could be spent implementing features
5) besides fixing parsing problems this lib may give additional features (like provide Ctrl+Shift switching which a lot of users miss in KDE) but for 3.5.2 my primary concern is fixing problems.

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...

Andriy