Developers and getting them to improve their code.

[Maks Orlovich]

> Yes, but often the KDE class reimpliments the entire thing rather then
> extend the Qt version.  This is often for history reasons (the kde version
> came first).  KConfig, KProcess, and KSocket come to mind right off the
> bat. Intigrating the additions into the Qt class, removing them or making
> the api's as similar as possible.  This is something that must be discussed
> with the TrollTech guys also of course sense they are half of the problem. 
> Beyond the bloat from a developer standpoint it is just confusing.

Of course, for instance replacing KConfig with QSettings would be just horrid 
performance-wise, so this isn't all that trivial. 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 much of a code 
size improvement if you replace something with a weaker class, anyway. 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 disable some of the base 
class processing (Particularly made worse by the vtable 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