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

List:       koffice-devel
Subject:    The QRichText port (Re: kdebase/kant/qt3stuff)
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-03-06 15:30:14
[Download RAW message or body]

On Monday 05 March 2001 16:53, Daniel Molkentin wrote:
> On Monday 05 March 2001 17:49, CVS by cullmann wrote:
> > kdebase/kant/qt3stuff - New directory
> > Author: cullmann
> > Mon Mar  5 16:49:58 UTC 2001
> > In directory cvs.kde.org:/var/tmp/cvs-serv26222/qt3stuff
> >
> > Log Message:
> > Directory /home/kde/kdebase/kant/qt3stuff added to the repository
> 
> Wouldn't that belong to kdelibs now rather than creating yet another fork?

This is obviously what many (included me) thought at first.
BUT after discussing with Christoph Cullmann and Simon on IRC, it turns
out that the answer is no.

Both Kant and KWord want to use private stuff from the richtext engine,
i.e. the classes defined in qrichtext_p.h. I don't mean private in terms of
the C++ keyword, but in terms of "public API". Apparently the classes
in qrichtext_p.h will not be part of the public Qt API, so using them
out of Qt is... well, forbidden :) That is a very good reason for having
our own copy of those files in KWord (and Kant's) sources, so that if
a minor release of Qt changes the binary compatibility of those classes,
it doesn't break KWord and Kant.
This also means we shouldn't install qrichtext_p.h from kdelibs, since
we do not want other apps to be based on it - for the same reasons.

The reason why those apps need the "low-level" classes from qrichtext_p.h 
is that they need to implement document / view separation,
and in the case of KWord, to extend the properties of a paragraph, to extend
the "flow" capabilities (for page breaking), etc.

On the other hand, if anyone wants to develop an application using
the richtext engine the "normal" way, with a simple widget that encapsulates
it all, then he/she can use QTextEdit or QTextView directly, and in that
case there is no need for using stuff from qrichtext_p.h
If such apps pop up before Qt 3.0 is out, then we _might_ put that stuff
in kdelibs, but this time changing the headers name to avoid the problems
we had with qk (old header found in $KDEDIR/include, breaking compilation).

Note that it's a completely different issue - KWord and Kant can't use 
QTextEdit, but need access to the internals of the QRT engine.

What I'll do in koffice before release: removing the qtextedit and qtextview
ports, not needed, moving qrichtext* to koffice/kword. And when we switch
to Qt 3, then we can also get rid of qt3stuff.h and qcomplextext.* - and 
finally have bidi support.

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today
_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

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