In this week's edition of the Road to KDE 4, we'll take a look at
the up and coming KWord 2.0 as part of the KOffice project. KWord 1.6.1 is
already a powerful KDE-integrated word processor, but with KDE 4
technologies, KWord 2.0 promises to be among the most powerful free word
processors available. Read on for more details.
KWord is part of the KOffice suite of applications which, with a few exceptions such as Kexi, has been visible thus far as a KDE-only application living under the shadow of the much larger OpenOffice.org suite. But this won't always be so, as the new KDE 4 technologies allow KOffice to exist as a native application on other platforms such as Windows and Mac OSX. Look out for more details on KDE support for these platforms in a future article.
One of the biggest assets of KOffice and KWord is its native support for the OASIS OpenDocument standard, which is shared by many office applications these days (including OpenOffice.org, Google Docs and others). Expect improved ODF document compatibility for KWord in the future as the developers strive for complete specification support.
Lets take a look at some screenshots from the development version of KWord. Notice the nice anti-aliasing of every element of the UI. On my system, it doesn't appear noticeably slower than KOffice 1.6.1. One of the most improved areas in KWord 2 is the text formatting and layouting, which definitely deserves some more exposure. It's not yet complete, but as you can see below, it's definitely much improved from previous versions. You really have to experience it yourself to appreciate how smooth moving, resizing and rotating Flake shapes is in this new version.
All manner of objects are being converted to the new Flake library, for instance KFormula elements, so you can insert nicely rendered math into your documents without any trouble. This support could make KWord as exciting to use for page layouts as KPresenter, as you are no longer restricted to dull, square document shapes. These changes should enable KWord 2 to behave as a respectable basic desktop publishing application.
Also noticeable in this early preview version is the lack of spell checking support, as this is being reworked for the upcoming Sonnet architecture for spelling and grammar corrections. (Which word did I misspell in my screenshot?)
But this is not the only improvement new to KOffice 2. Also in the works is scripting support for applications through the new and extensible scripting framework dubbed Kross. It has received a lot of work and looks to be one of the killer features of KOffice 2.
The following screenshot shows the new scripts menus in KWord:
Also notice how I moved the tear-off toolbars from the previous screenshot. I placed them by drag-and-drop, and they automatically tabbed up. This is all done very smoothly by Qt with no noticeable interface flickering.
Of course, the same scripting and rendering features have made their way into other KOffice apps as well. KSpread and scripting are a perfect fit, and there is a lot of power exposed to the advanced user.
For people interested in more details about Kross, check out this article on the development and usage of Kross in KSpread.
These are just some of the many improvements in the works for KWord and KOffice when the KDE 4 platform rolls out. Of course, these screenshots are of the development versions, which are quite unstable at the moment, but jugding by the level of activity today in the developer channels (like #koffice on irc.freenode.org) there is a large amount of momentum behind this release.
KOffice has a separate release schedule from KDE 4, so they may or may not release concurrently.
indeed; you'd get open office all over again at the cost of a gargantuan development effort.
and - Koffice with the KDElibs is still smaller than OO.o itself...
You could load kdelibs with xfce, so that you won't have the startup delay when launching a kde application.
XFCE uses less memory when you start a clean session. With more apps open, XFCE can use more memory because every application (AbiWord, OpenOffice, Firefix) has it's own set of libraries. At some point KDE wins here. See the following: http://ktown.kde.org/~seli/memory/desktop_benchmark.html
For starting KDE applications outside KDE, also try:
Not depending on the kdelibs would not actually mean less code (in total) or a lower functionality requirement.
So its like saying you want to eat a full meal, but don't want to gain any weight. So lets only eat crackers!.
Well, in both cases all you are doing is move the requirement to another place and you'll just be adding lots of code in KOffice itself. Just like you'll eat a whole lot of crackers to be able to sustenance you.
As another poster in this thread said; sharing the libraries with many other applications will in the end save you space since not every application will load a _different_ set of libraries even though they all need a large total amount of libraries.
So you can see it like you are carpooling libraries. You save in fuel money by sharing the car with your neighbor. That doesn't change the fact that you both need to travel a long distance, it just means it has less of an impact.
Carpooling is the real solution; buying a smaller car of your own doesn't actually help much.
Hope that explains this rather complex mental model a bit better :)
IMHO, a 'track-changes' feature is a must for a serious word proccesor. OOo has it, Word has it and i think even AbiWord has it.
Then, of course, one need to compare two document in a clear visual way...
Definitely. Also cross-referencing and indexing features (at least, these were still missing last time I looked which has been a while). From what I see in the screenshots, there is still too much focus on "fancy layout stuff" (which IMO they could leave to Scribus and vector graphic programs) and not enough on basic text processing and every day tasks. To concentrate on the usual "dull, square documents" seems still the biggest problem for the developers. ;-)
The big work going in is about laying foundations and adding things like proper borders around paragraphs or doing proper lists and counters.
All pretty boring work, so you won't see an article dedicated to it (but be sure to check out my blog where I list some less boring parts more often then its on the dot).
All in all; the 'boring text editing' is certainly a high priority.
...and as someone who actualy even likes those boring stuff I like to add, that there was and still is a lot of great progress on it even if not direct visible like the "fancy layout stuff" :)
Trolltech will release QtScript, successor of QSA, with Qt 4.3. Will this have any effect to Kross?
So QtScript and KJSEmbed will merge?
But from reading over the post, I think it suggests that KjsEmbed and QSA (predecessor of QtScript) should merge?
Well, IM(H)O merging is maybe not the best idea since Kjs+KjsEmbed and QtScript are just different implementations. Merging them is like to suggest to merge Python with Ruby cause you like both and cause they are very similar (OO, dynamic, written in C, scripting languages, etc.). Anyway, that's only my personal point of view and everybody who believes it's possible to merge them (KjsEmbed with QtScript or maybe even Ruby with Python) and likes to start working on it, is free to do so and it wouldn't be the first time that an unique vision becomes reality within the KDE-project :)
You see... kword has not such lots of buttons that the other office suits have (especially MS Office 2007). This will confuse the users- they will think that the kword is not as powerful as they are...
Please remember that Koffice 2 is in development. I'm sure this will change.
let's hope not, one of the good things of Koffice is it's clean interface...
If that is the default font setting for KSpread, please change it.
The numbers in the left column are too big for the row height and the text on the first row has some issues with their kerning.
Otherwise, brilliant visions!
Still there's no news about including the beloved "Freeze Panes" feature. For me, it means KSpread is unusable. How can you work on anything without seeing a header of the spreadsheet?
I think there must be a similar feature I didn't notice. I would appreciate if someone could point it out for me.
See also http://wiki.kde.org/tiki-index.php?page=KSpread+Development .
View -> Split View
Split View is not the same at all. Window freezing will keep one or more rows or columns still while you scroll through the rest of the document. Try it yourself scrolling through 1000 rows of data. Split view shows me two windows and one doesnt have row and column headers so they aren't even aligned.
Will the text flow algorithm be augmented to support enforcing an optional bit of space in between objects? (This could be a property of each object.)
Currently the 'g' in "upcoming" almost touches the flower and the 'f' in "features" is very close to the arrow.
I fixed a bug in that code shortly after the screenshot was taken.
And you can configure the distance for each object individually as well.
When it comes to printing, KWord & Co. fall flat on their faces. Unfortunately. I'd very much like to love KOffice, but can't (since it doesn't love me either).
Because, what do you do with a document you created or modified usually? Yes, maybe send it off by email. Very often you'll convert it to PDF and mail that format ('cause most people out there do not yet know about KWord). And in the end, more than 50% of documents will end up getting send to a printer at least once.
So it is very crucial that some elementary things in respect to printing support are implemented in all document-creating applications: the most important one is font fidelity from screen to paper (otherwise you get unwanted line- or page-breaks), one other is support not just for all standard media sizes for printing but also for any custom format you may define.
In KWord, these very basic features for everyday use are missing. I'm not even talking with the poor (rather: non-existing) WYSIWYG support for fonts (you usually don't get the same page image painted on paper as you get painted on screen).
I'm more concerned about custom page sizes. Which we use a lot. Or envelopes. Can't print on envelopes (addresses, batch printing from database), because KOffice can't even create a correct PostScript print file with the correct settings for PageSize and BoundingBox. Same for custom page size. Internally, KWord boasts that it can create 10x10 or 12x9 or 42x21 inch sized documents. "Great!", you think, and start working on them. You finish it, and want to print it (yes, there are printers that allow for custom media sizes). No joy: KWord gives you an A4 PostScript document, with everything overflowing just cut off. Not even "Print to file (PDF)" does work correctly (I had hoped for being able to use *that* for printing, because our commercial printshop around the corner *can* do 42x21 inch poster printouts).
I'm aware that this is probably Qt's responsibility (it is only capable of PostScript Level 1, and it is rather buggy when it comes to embed fonts into its PostScript export files). But this shifted point of responsibility doesn't help me, the user. I just suffer from this overall system being unusable for my document creation and processing needs.
Anyway... I sure hope KOffice 2.0 will rock with all its playful features that the developers do enjoy so much programming for!
But please, please, please do not forget the everyday bread-and-butter needs we normal users in the offices do have to cover.
Its feels odd that you complain about the level of WYSIWYG of koffice1.x while this article makes clear the text engine has gotten a major revamp.
Anyway; in short. The printing of the pages will go directly to PDF in KWord2. I already have that working and the text looks very good. This includes DTP like features like automatic page-bleed and font embedding.
Cups will use these PDFs to convert it to your printers optimal format.
About custom page size; yes thats indeed a missing feature in Qt; see http://www.trolltech.com/developer/task-tracker/index_html?method=entry&...
Its scheduled to be included in 4.3. Which is what KWord2 will use when it comes out.
In other words; have patience and your dreams will be fullfilled :)
Oh; you don't have to wait until the release to send me pizza's, you can do that right now already ;)
I'm sorry to say it, but "ac" very much expressed feelings that are very close to my own. (On some points, I'd even go farther than he did in his "puring cold water over the hype").
Yes, it feels odd to read such comments underneath an article where the great achievements of KOffice 2.0 development are highlighted. But the very same article also tried to convince me that "KWord 1.6.1 is already a powerful KDE-integrated word processor"...
So I also think a bit of a reality check is in order. Sometimes it helps.
"KWord 1.6.1 is already a powerful KDE-integrated word processor"
That statement is correct :) it's might not be powerful enought for you yet. But it allready covers quiet a lot of use cases (and it's integrated in KDE).
indeed. i know it's far from perfect (but so is anything). but i can use it for most of my writing, i just create the final pdf with OO.o (after fixing the incompatibilities...). OO.o is just a pain in the ass, slow and harder to use. so i use Koffice, even tough it has some flaws... i really look forward to KDE4 and Koffice2, as they are supposed to fix the few problems they still have :D
Glad to hear about the text engine revamp. :-)
I raised the points for those developers who may be interested in acknowledging them. When/where else but here could I raise them?
I don't want to have to raise them again when the new text engine for KWord3 is promote in a Dot article of 2012, you see? :-)
So font fidelity as well as page size setup are now acceptable in KWord2?
IMHO it did serve a good purpose to hint at the current KWord 1.6.x weaknesses -- so you guys don't forget what the real world requirements are for people who aren't busy to design great, elegant and powerful software libraries such as Flake (please: this is by no means meant to sound sarcastic, Thomas!).
Hmmm... maybe I should look at this from even another point of view, and say it differently: "...so you guys are fully aware about the real world requirements of people for whom you are design your great, elegant and powerful software libraries." Yup, I think that's better. :-)
I sure have patience to wait for my dreams to be fullfilled.
But I also have fears.
Fears, that my dreams aren't understood at all by you guys because you simply care about completely different things. You have different priorities. Most of you are doing Free Software for fun, not because you are paid for it. That one factor alone makes for an entirely different set of interests to persue when you are coding at night. And caring for acceptable print results on paper may simply be too boring for you. (That's not an insult, just a statement of facts.)
Yes, despite my fears, I'm *still* really looking forward to see KWord 2.0 come to life with all its great new features. :-)
In any case -- tell me the closest Pizza service (or do you prefer a Restaurant?) to your home address (and if possible, their phone number). I'll see what I can do. Peperoni or Salami? :-)
Or something completely different? :-)
Its funny that some people in this thread have stated I focused on DTP like features too much. And then you state kind of the opposite.
Amusing world this is :)
pop quiz; how many wordprocessors print PDFs using proper bleed? Out of the box without the user setting anything?
so, as you are someone not a stranger to gcc, please take the time to compile koffice2 and see for yourself. AFAIK all the features you want are already there. Assuming you can work with PDF instead of postscript ;)
ps. almost all, see the other post about custom page sizes.
Hahaha... that link to the Troll's bug tracker is a good joke.
As you can see, in their current bug tracker they had at first the version to fix this to '4.1.0', then to '4.2.0' and currently it is '4.3.0'.
But I can counter your joke with an even better one:
As you can see, Philipp Mueller wrote nearly 4 years ago in KDE's bug tracker about "Custom paper layout settings not honoured":
"Trolls say, this is intended to be implemented in QT 3.2, so we need to wait until it is also implemented in KDE 3.2".
Why, oh why do I have a hard time to believe you? Why, oh why do I really wonder how the Trolls run still such a successful business?
May somebody explain to me, why tear-off menus are going to completely disappear in KDE? I believe, the last official app using it, is Konsole.
No idea, but i can't find the tear off menus in konsole?
Haven't seen them since kde 2.x or even earlier..
Ups. right. seems they are finally gone even there. worked until 3.3
Possibly because no-one else uses it and new users don't understand how to use it. That I think is a legitimate reason, even if I don't know if it is correct.
First of all, your series of articles about KDE4 apps is very interesting. A good preview.
But one thing that gathered my atention is that KOffice 2 is slower than current version. Wasn't the move to Qt4 suposed to make aplications faster and lighter? I don't want to see an full featured KOffice as bloat as OpenOffice is now.
By the way, everything in the KDE4 snapshot versions is already runing in top of Qt4? Or at least the base desktop? If so, how is memory consumption and starting time in KDE4, with only the porting and basic changes? I hope it is lighter than current KDE 3.5.x....
First off, everything compiled for KDE 4 has a lot of debugging overhead. This will go away in the final release.
What happens is that with all the debugging info still in the binaries, the filesize gets large (sometimes doubling the app size), which then takes more memory and so forth.
The main problem I have right now for speed is startup speed, and that's due to debugging more than anything else. Qt4 is very very fast, and it's most evident when running a Qt-only application since Qt 4 has been stable for quite a while.
KDE 4 is still in development, and there is legacy KDE 3 stuff that is slowing things down that is slowly being purged. The slowest thing at the moment that I've found is the drawing of kicker tooltips... However, since kicker will never make the full transition to KDE 4, that is probably not going to be fixed... just replaced.
I forgot these things...
I will search for more Qt4-only aplications, and leave KDE4 for when it its ready, or at least release candidate. ;)
> If so, how is memory consumption and starting time in KDE4,
> with only the porting and basic changes?
Short answer: Come back and ask again in a few months time.
It really isn't possible to answer that question accurately with the current build, which is still very much work-in-progress. For example, on my machine the startup splash gets to the "loading the desktop" phase and then sits and does nothing for 10 seconds or so. You can see Konqueror removing all of the toolbars and then placing them back again when switching from one tab to another, and so on.
Leaving aside major architectural issues, optimisation is one of the last phases of development. It is much more important to get the product functioning properly first. This isn't just KDE development either. The first public beta of Windows Vista performs much more slowly than the final release, despite all of the architectural changes which had already been made under the bonnet to improve performance ( and no, I am not implying that KDE 4 will have the memory requirements of Vista )
>>You can see Konqueror removing all of the toolbars and then placing them back again when switching from one tab to another
Well, that's what my konqueror also does in kde 3.5.5 :o)
Then either compile Qt+KDE without debug or double your RAM by buying another 64MB ship ;)
Looks like that kspread 2.0 will finally be compatible and usable for day to day business.
Is the default for KDE4 still going to be icons and text for toolbars as default? These screenshots just illustrate what a bad call that is in my opinion. It is a complete mess. On top of that some of the buttons don't have text at all which defeats the purpose does it not? I fail to see how my usability is enhanced by knowing that the icon of a printer means print, if so much of my screen is eaten up that I can't quickly press a selection of buttons to access lots of regularly used functions.
Just look at how much space is consumed by the print preview button. I know the German language for example is fairly prone to having quite long words, so I dread to think what the screenshot might look like with with translation applied.
How are developers to cope with long translations affecting an aestheticly sane default layout in English that looks horrible translated?
I see no concern here.
The underlying architectures are going through intense development, and when that's finished the devs will probably pay more attention to stuff like default settings. Right now the screenshots are simply demonstrating new text/shape layout technologies, not final release defaults!
I think you're right. And when looking at microsoft word 2003 for example. I think oxygen icons is one thing that could make it look better, the other is just those yellow tooltips (description + shortcut), would make the whole look a little more professional.
It's a little bit like those KDE programs under windows, okay it works, but it somehow doesn't really look equally to a windows program or to firefox for example...
Well we will see, it is still work in progress. A nice theme and some cleanup, could change the whole look and feel.... (I hope....)
The solution for this problem is what Windows calls "Selective text on right". I believe it is used both in Windows and in Gnome applications for frequently used buttons (thus giving a larger click-area).
Almost 3 years ago, a bug on this matter was marked as WONTFIX.
I believe it should be reopened. (as a side-note, I believe this should be the default mode for the icons - Windows has it as default, don't know about Gnome).