is new lib dependency possible for 3.5.2?

[Andriy 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