is new lib dependency possible for 3.5.2?
arysin at myrealbox.com
Fri Jan 27 13:59:41 GMT 2006
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
> "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
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...
More information about the kde-core-devel