'RE: KWord status'

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

List:       koffice-devel
Subject:    RE: KWord status
From:       Nicolas GOUTTE <nicog () snafu ! de>
Date:       2001-02-09 21:54:14
[Download RAW message or body]

I do not intend to make anybody angry, to offence anybody or to make 
anybody feel personnaly attacked but I would like to say a few things about 
the current situation of KWord.

It is not good that the application that many people considers the most 
important one (or that they await the most) in the whole KDE project is in 
such a uncertain state.

1. File formats
It would help if the work around KWord's core could still be continued in 
the meantime. When the new KWord will be ready, most of what is needed 
beside it would be there already. So it would save time until a stable 
KWord exists.

To achieve that filters work with the new KWord and that new developers 
feel welcome to KWord's world, I think that a few things are needed in 
particularly on the level of KWord's file format:
- How does the new file format of KWord look likes (I am not naive enough 
to think it would stay the same!)
- Don't design the file format after the application's code! It's the way 
you always get permanent problems! Design a file format, then code for it!
- Stay as much as possible with standardized file formats (or at least 
close to them). It would help (new) developers to understand KWord's file 
format. May be they have even used this file format somewhere else! In case 
of KWord, it means XHTML for the text (not HTML, as it is not XML) and CSS2 
as style sheet (should be enough even to cover the DTP mode!) Not enough? 
Then use a own (XML-)namespace for KWord and add things to XHTML. (Cf. 
http://wwww.w3c.org)
- See what other file formats do. For example, Microsoft Word (native or 
RTF) and AbiWord needs sections, where you can have different number of 
columns in each section. How do you do that in KWord? How do you make a 
forced line break, a forced column break, a forced page break? (I mean in 
the file format, *not* in the application!)
- Document every tag used in KWord. (No surprise as with <HRDBREAK>, which 
is currently not in KWord's DTD)
- Avoid tags that can represent many things at the same time. (Why is an 
anchor a <FORMAT> in KWord?)
- In one word, please think also about filter developers and don't make a 
file format that is just good for (one version of) KWord!

2. External style sheets
Personnaly I dislike to take out the style sheet from the document. I 
understand why HTML/XHTML does it but I do not understand why KWord should 
do so. And if you do, please use CSS2 (http://www.w3.org/TR/REC-CSS2 is the 
latest version). XML is make to mix things together, not to separate 
things!
<OFFTOPIC> In my opinion even the tar stuff in KOffice could be replaced by 
XML namespaces. However gzip is fine! However I think that this is work for 
way later! </OFFTOPIC>

3. KWord in general.
Many (potential) users awaits an application like the old word processing 
application they have used. Care should be taken not to break this too 
much. To give a recent example, forbiding users to have double spaces is a 
bad behaviour for KWord (even if it looks odd!) (And filter developer 
cannot do miracles. For example tabulators do not exists in HTML!)

4. Depreciated Files
Please note in the current CVS which files are depreciated, so every 
programmer knows that he/she should not modify anything in it, but a very 
serious bug!
On the other side, files whitout it can be modified and the programmer 
could be fairly certain that his/her modifications would stay, even after 
the change of KWord's core!
Example: at the top of those files add:
// This file is depreciated

5. The End
Sorry if you think that what I have written is rant!

-----Original Message-----
From:	Thomas Zander [SMTP:zander@planescape.com]
Sent:	Friday, February 09, 2001 9:28 AM
To:	koffice-devel@kde.org
Subject:	KWord status

Ok, just for all to understand, here is the status and short term stuff I 
was
planning for KWord.

First of all I think the architecture of KWord has to be done correctly. 
The old
(HEAD) style of storing and rendering text is really bad, and is going to 
be
replaced by the new QT classes of the QTRichText widgets.

Ok, I've been saying that for 3 months now, so why has this not happened 
yet??
Well, the QTRichText classes are development classes and part of the 
upcoming
QT3. I got the first version of the new widget somewhere in November last 
year,
and we tried to use them, this worked, but the widget was not advanced 
enough
yet for all the text rendering we need for a professional word processor.

After some discussion and stuff with TT (thanx Reggie) the RichText classes
have been extended so in KWord we can extend (as in inheritance) the 
relevant
classes to implement the missing stuff in KWord.  (Which is really nice 
since
now we are not dependent on QT updates for KWord features ;)
The new problem is that the new BIDI and other stuff is created at a basic 
level
in QT (which is good), and there is lots of new stuff is in QPainter and 
friends..

This then boils down to the problem that we need QT3 to use the RichText 
engine.
And since KDE does not compile with the (still alpha) QT3....

So we are at a point of being unable to continue until the whole of 
KDE/koffice can
be compiled with QT3.
The alternative is to backport the classes, but this has to be done a 
number of times
until we reach a release of QT3/KDE.. (Which I am not going to invest time 
in ;)

Ok, I started this story with the statement that it is best to start with 
the basic
structure.. I still believe that, but if that is impossible, lets move on.

Here is a list of things I want to see in KWord in the short term, which do 
not
rely on the text-engine.

- complete redesign of GUI. (most wanted feature ;)
- images stuff needs to be completely redisigned (proposal in kword/TODO, I 
  remember werner or simon having an opinion on this as well)
- Extend the file format to make it possible to have styles in another 
file.
  The styles are embedded into the xml that contains the text, I really 
want to
  be able to seperate that in either a new tar or in a seperate 
styles-template.xml file
  inside the same tar.

And smaller things;
- status bar should have extra things, like a page number..
- DCOP interface (well not that small, but it can be done in small steps)

How to proceed;

I believe that the branch was nice to get this development done, but 
brances only
work for short periods of time (my original estimate was 4 to 6 weeks).
So I think it is best to continue development in HEAD, and just forget the 
branch
ever existed.
Then when QT 3 is operational we just take the RICHTEXT branch as an 
example and
implement RichText (yes, again)...

So, if anyone wants to jump in; do it in head, and try to spend as little 
time as
possible on the text-rendering stuff (I'll try to fix the annoying bugs 
soon, promise!)
And maybe we can continue development of the nice stuff soon!

Thanx for your time, and thanx for reading this far..

KWord has got potential, it needs a lot of work, but it is going to be the 
best
WP ever ;)

--
Thomas Zander 
                                           zander@earthling.net
The only thing worse than failure is the fear of trying something new
_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

_______________________________________________
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] 