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

List:       kde-core-devel
Subject:    Re: kikbd
From:       m_elter () t-online ! de (Matthias Elter)
Date:       2000-05-02 15:37:10
[Download RAW message or body]

On Tue, 02 May 2000, tibirna@kde.org wrote:
> 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,

Good to know that you are still working on it. But you really don't have to
apologize for having little time for KDE hacking, this is after all a free
software project and you can't donate more free time than you actually have.

Greetings,
Matthias

-- 
Matthias Elter
elter@kde.org
me@caldera.de

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