[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kikbd
From:       tibirna () kde ! org
Date:       2000-05-02 12:24:04
[Download RAW message or body]

On Tue, 2 May 2000, Matthias Elter wrote:

> Hi
> 
> Ok I had a look into makeing kikbd compile but don't get whats going on.
> Basically everything relies on kikbdconfig.* which have been removed. I can't
> find any information on why this has been done in the cvs log ... input anybody?

Hello

Kikbd was a very nice program in KDE-1, but I believe it was also the
program with the most nummerous flaws. This *is no fault* of author, *was
responsability* of the maintainer and *had reasons* derived from technical
complexity.

Hence I drawn a functional diagram and started to rework it, combing line
by line.

The whole shebang had quite a clean structure previously. There was
though, one point which screwed all. The config mechanism had a 3 times
curled loop across 3-4 classes, which intended to allow, in one huge lap,
intelligent implementations for configurable startup, initial/safe
first-start, correct user config detection.

The other thing that bothered me a lot is that kikbd and kcmikbd (its
config thing) tended to use the same code base, and especially make use of
the "Visitor" design pattern, but in some screwy mode I didn't completely
understand. The result was that kikbd requested 1.5 MB of memory at run -
mostly uselessly - because the config classes had also GUI creation
methods, which were loaded both in kikbd and kcmikbd, but kikbd didn't
need them.

The other big issues were related to the X event handling, which attempts
to acquire quite complex tasks (sequential multi key press detection) and
fails too easily in some special situations.


Hence, I started by implementing UniqueApplication features plus DCOP
communication between kikbd and kcmikbd.

The second thing is that I take out kikbdconf and use plain KConfig
calls. Yes, less elegant than a design pattern, but much safer than before
and lighter too. I have to finish this.

The third thing (that I didn't start, but it's not complicated to do) is
testproof the X event loop treatment, simplify it and make it handle
better the special situation.

The main problem isn't the program or the technology, the main problem is
me, which fail miserably to find time for conding since many months.

Friendly yours,

-- 
Cristian Tibirna 

[prev in list] [next in list] [prev in thread] [next in thread]