Developers and getting them to improve their code.

[Benjamin Meyer]

On Wednesday 08 January 2003 4:13 pm, Maks Orlovich wrote:
> > Yes, but often the KDE class reimpliments the entire thing rather the=
n
> > extend the Qt version.  This is often for history reasons (the kde
> > version came first).  KConfig, KProcess, and KSocket come to mind rig=
ht
> > off the bat. Intigrating the additions into the Qt class, removing th=
em
> > or making the api's as similar as possible.  This is something that m=
ust
> > be discussed with the TrollTech guys also of course sense they are ha=
lf
> > of the problem. Beyond the bloat from a developer standpoint it is ju=
st
> > confusing.
>
> Of course, for instance replacing KConfig with QSettings would be just
> horrid performance-wise, so this isn't all that trivial.

I agree.  There is little reason to toss out what is good.  This is much =
more=20
of a colaberation with TrollTech type item and to decide upon a per class=
=20
case what to do.

> Confusion may be a
> valid argument for simplification; but I don't think code size is (for =
KDE
> that is -- it obviously matters a whole lot on Opie) - you don't get mu=
ch
> of a code size improvement if you replace something with a weaker class=
,
> anyway.=20

When I first started to code using the KDE libraries I was concently conf=
used=20
about the duplication.  I was never really sure what one to use or why.  =
Even=20
worse was the fact that the api for the class for similar functionality w=
as=20
different so when i transitioned from Qfoo to Kfoo I had to change a lot =
of=20
calls.

> I seriously doubt it's also a time performance problem -- which is
> IMHO what should be solved most. I think if you looked at it carefully,
> you'd find that the most cycle waste occurs when KDE classes extend Qt =
ones
> with inheritance, because there might not just be enough hooks to disab=
le
> some of the base class processing (Particularly made worse by the vtabl=
e
> construction order fun - KIconView has some nice example of this, made =
far
> less significant by the metrics width cache in Qt 3.1, though).
>
> Oh, and as to specific hints, I only can think of 2:
>
> 1. using QString manipulation in hot code paths is much slower than one
> expects
>
> 2. Without profile guidance, it's guessing and not optimization
>
> -Maks

If  we only had one class everyone could work on improving that class rat=
her=20
then improving two classes.

-Benjamin Meyer