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

List:       kde-core-devel
Subject:    Re: Heads up: new KAccel classes
From:       Ellis Whitehead <kde () ellisw ! net>
Date:       2001-11-19 3:37:03
[Download RAW message or body]

To all:

As long as I haven't missed any commits, the following modules now compile: 
kdeadmin, kdeartwork, kdemultimedia.
The following modules probably compile now, but I haven't verified it: 
kdepim, kdegames.
If anyone tries kdegraphics and it isn't working due to something accelerator 
related, please let me know.

On Saturday 17 November 2001 11:53 am, Simon Hausmann wrote:
> On Sat, Nov 17, 2001 at 12:24:52PM -0500, Ellis Whitehead wrote:
> > On Saturday 17 November 2001 15:29, Simon Hausmann wrote:
> > > A possibly stupid question, but why does KAccel no more inherit from
> > > QAccel, and why does it aggregate KAccelBase instead of inheriting
> > > from it?
> >
> > 1) to lighten up the includes.
> > 2) to reduce re-compilation requirements.
> >
> > kaccelbase.h is 'heavy', and I'll still be modifying it a lot before 3.0
> > is released.  If KAccel inherited from KAccelBase, then everything which
> > includes kaccel.h (a _lot_) would want to be recompiled for each
> > modification.  That was a major time waster for me in the 2.2 cycle.
>
> [ as long as the change is binary compatible (which it has to be
> after 3.0) it doesn't really matter, does it? -- I mean, it's a bit
> like API oddness versus compilation time ;-) ]

The development process is simply too painful if everything is in kaccel.  
The difference for me is one of waiting 20 minutes for a fully updated 
compile of kdelibs & kdebase, versus 1 hour.  I'll try to reduce the oddness 
to a minimum by creating a few more wrapper functions and writing 
documentation.  If you or anyone else has any input on this, I'd be glad to 
hear it.

> [snip]
> A question about the KAccel-does-not-inherit-from-QAccel-anymore change:
> Is it because the new KAccel works fundamentally different than
> QAccel?
>
> (although it confuses me that the very first thing KAccel internally does
> is creating a new QAccel instance)

The old KAccel/KGlobalAccel classes had dozens and dozens of overloaded 
functions and lots of other code that didn't really belong in them (such as 
key conversion and some menu handling).  One of my goals was to simplify this 
as much as reasonable for the sake of maintainability, especially since the 
code has become conceptually complex and will become more so as the user 
interface to the emacs-style shortcuts is implemented.  Part of the 
maintainability idea is to implement KAccel & KGlobalAccel in similar styles, 
and deriving KAccel from QAccel would throw that off.  Since I haven't seen 
any instances of QAccel being used via a KAccel object, I would be reluctant 
to trade off internal consistency for what could only have either poor or 
obscure and rare application.

> P.S.: sorry for the rants/questions :-} -- independant from what I
>       wrote above I really like the stuff you're doing, especially
>       the emacs-like shortcut support :)
Thanks.  The UI to these shortcuts still needs to be implemented though.

Ciao,
Ellis

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