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 , which is currently not in KWord's DTD) - Avoid tags that can represent many things at the same time. (Why is an anchor a 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! 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! 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