First, is this the right forum to be talking about all this?

I have made some progress in my efforts to port kdvi to Windows and now
have an app that runs without using the KParts factory stuff to create the
EmptyMultiPage and KDviMultiPage widgets. I can continue down this path,
stripping out the KDE-specific stuff, but first I thought I should offer
some (potential) patches back. Some are really trivial. Some might need
some discussion.

Please indicate which, if any, of these you're interested in:

1. Whitespace. There's a heap of trailing whitespace in
kdegraphics/{kviewshell,kdvi}. s/ *$//

2. private static data in header files. It's just polluting the header
file. I propose to move it out of the classes and into the .cpp files
only. =

documentWidget.h: static QPixmap waitIcon, URShadow, BRShadow, BLShadow;
marklist.h: static QPixmap waitIcon;

3. I had a lot of problems getting things up and running because these
static QPixmaps above are plain evil. If their translation unit (here
documentWidget.cpp, marklist.cpp) is instantiated before that containing
QApplication then there's a run time failure:
QPaintDevice: Must construct a QApplication before a QPaintDevice
I've used singletons in the .cpp file instead:
QPixmap & URShadow()
{
static QPixmap * pixmap =3D createPixmap();
return *pixmap;
}
A real solution should address multi-threading concerns, but you need
*something*. Alexandrescu's "Double-Checked Locking Pattern" springs to
mind here. (Modern C++ Design, section 6.9.1)

4. There are many raw pointers that just smack of resource leaks. A quick
read of the QGuardedPtr docs suggests that it's a little heavy but would
clearly do the job. Is there a KDE policy against Boost? Why aren't you
using boost::scoped_ptr<> everywhere?

5. Memory allocation/fragmentation. "new" is expensive, right? For example,
kdegraphics/kviewshell/searchWidget.h has:
SearchWidget* searchWidget;
QPushButton* stopButton;
QLabel* searchLabel;
KLineEdit* searchText;
QPushButton* findNextButton;
QPushButton* findPrevButton;
QCheckBox* caseSensitiveCheckBox;
QHBoxLayout* layout;
why aren't you using the Pimpl idiom in such cases? Only one "new" as
opposed to 8...

6. Is there a KDE policy against anonymous namespaces? There appears to be
a stack of "static Foo foo;" stuff in .cpp files that I would expect to
see as "namespace { Foo foo; }".

7. Why does kdegraphics/kviewshell/units.h use a class and static function
when I'd expect:
namespace distance {
float convertToMM(...);
}

8. This one is perhaps a real bug. Why are you passing copies of
TextSelection around? Why not "TextSelection const &"?

class DocumentPageCache: public QObject {
public:
void selectText(TextSelection selection);
};

class DocumentWidget: public QWidget {
public slots:
void select(TextSelection);
protected:
void updateSelection(TextSelection newTextSelection);
};

class KMultiPage {
protected slots:
void gotoPage(TextSelection);
};

class RenderedDocumentPage {
public:
QRegion selectedRegion(TextSelection selection);
};

9. Is there a KDE policy on order of inclusion of header files? At LyX we
use the "most specific first" policy. Ie, the "..." headers come before
the <...> ones. That way, the contents of the <...> headers don't polute
our own stuff. You *appear* to do things the other way round. Is this a
conscious policy or is that just "how it happened". Would you like a
patch?

10. Goes with (9) really. You #include a bunch of stuff that you don't need
or use. I have a little script that removes each header file in turn,
tries to compile and if it fails puts the header back. The result is
invariably "leaner and meaner".

Just trying to get a feel for all things KDE ;-) If you're interested in
receiving patches to any of these, just holler.
Angus



=

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=

e <<