KOffice 2.0, The Vision

KOffice is working on its future, one based on KDE4. KOffice is starting new initiatives with libraries like Flake and Pigment that are going to be used for all KOffice applications. For the users of KOffice those changes are invisible until the 2.0 previews actually start to appear some months from now. Therefore the KOffice crew wants to show you their goals of what KOffice 2 is going to look like. Read more for the whole story.

When I first saw a paper on KOffice back in 1999 it showed the concept of embedded documents which allows me to have a formula or chart in my paper and allow me to update my charts by just altering some cells in my spreadsheet.
The idea that an open source and good looking office suite does that brought me into KOffice.

Now, many years later, we are moving to the next level. KOffice will define so called 'shapes' which can be anything from a simple triangle to a multi-layered image and allow those to be used in all KOffice applications as the building blocks of a document just like they are shapes that the application provides itself. So no more embedded documents which are always square and always start from the top-left corner. This allows for simple things like KWord finally providing simple lines to be drawn, but much more exciting are new features like being able to rotate or skew a KWord text frame. And not only being able to do that in a KWord document, but also in a Krita or a Karbon document.

In KOffice each application will have a specific media that it will specialise in. KWord will obviously specialise in text frames while Karbon will specialise in all sorts of vector graphics. The difference is that the applications will put all that in a Shape and a Tool.

Consider a user who wants to write a paper and have a nice vector graphic in the header of his document. He would be able to load an svg graphic and place it in his KWord document. For tweaking the loaded graphic he can just click on it and at that point KWord will see that the shape is a vector one. KWord will then supply a tool in the toolbox (which is the normal 2-columns toolbar type thing Krita already has) that allows the user to alter the internal vector graphics right inside his KWord document. But without the annoying flickering and replacement of menu and toolbars that happens if the shape was really an external document being edited.

KOffice 2 will still have the most applications there are combined in any single office suite, and on top of that those applications will show an integration that's unparallelled in the industry. Each application really does make the whole more complete by literally making the other applications more powerful.

Every application that uses the Flake library will provide a shape-type that the other applications can use. Want to use that 1 cool Kivio-shape in your Krita painting, go ahead. But the most exciting part is that the shapes come with so called 'tools'. Where each application can use the interaction model for that shape type. And since its determined per shape-type, its the same across all the KOffice applications.

We already see the advantage with a basic interaction-tool that allows moving, rotation etc. of all shape-types. It has features like scaling with the control button down, reserving the aspect ratio of the shape. Unlike in KOffice 1.x that single interaction-tool will be used in all KOffice applications stopping the application from reinventing the wheel, they are literally all running the same code and thus all applications will work consistently towards the user. Definitely a good thing for usability.

Flake in KWord 2

Dot Categories: 


by bob (not verified)

You mean Pikment surely

by em (not verified)

Teh unfunny joke gave me teh cancer.

by blob (not verified)

do you mean bob or blob ??

by ash (not verified)

I've wondered for a while whether there's a K ego, perhaps even a conspiracy to eradicate all things G. But alas, Ockham's razor requires we consider the possibility that it is cute branding, a trademark if you will. :)

That and I'm too lazy to worry about inter-GNU project struggles (just install 'em all, they're free)!

by Anders (not verified)

Bad idea. Pik means dick in Danish.

by Nooopss (not verified)

With the FIFA world cup here, we will stop our work to give a look at those thousand pretty brazilian womens with their usual small skirts.
Sorry folks, KDE 4.0 will be launched next year, probably.

by Iuri Fiedoruk (not verified)

There are some movements here in Brazil to prevent selling this nice-almost-naked-women image. This unhappilly is causing a lot of sexual tourism, mostly in north-east.

Besides, we don't stop because of those women in world cup (fot that carnival exists, hehehe), football is enought to stop the entire country :)
Count that brazilian portuguese translations will be out of pace for a while ;)

by Me or somebody ... (not verified)

Brazilian woman are incredible. They know all the write commands in the right order: top, mount, fsck, flush, sleep;

They are often run threaded with the ability to engage their friends for a little distributed processing and a whole lot of fun. Never visit Brazil or thou shall not leave it.

Ahmmmmmmmm, what were we talking about? Oh, yeah, KDE 4 will win the world cup, I mean, KDE 4 is hot, and Brazililians write good software or something like that.

by Juliana (not verified)

My dear nerd, if you don´t know, world cup will be in GERMANY, so.. how you can give a look at pretty brazillians womens?? Why don´t you go to Rio de Janeiro´s Carnival? It´s pretty good!

by cm (not verified)

I'm not the original poster, but just one word: Fans! :)

I've even seen a few of them yesterday in Königstein where the Brazilian team is housed.

by noooppsss (not verified)

Yes, brazilian women will be at Germany, there is a top model team there, sponsored by a TV chanel. Rio de Janeiro will lose it´s postcard, the bikini tanned round *#@% of pretty brazilians.

All this *#@% will be at Germany, but, unfurtunately, well covered, due the cold wheather.

What´s "*#@%"??
I´m a brazillian women and I would like to know...

by bb (not verified)

This may mean "bumbum", I think....

>All this *#@% will be at Germany, but, unfurtunately, well covered, due the cold wheather.<<
No - it's not cold here - it's hot. Beautiful sunshine and temperatures in the 30ies. And KDE/Koffice *will* be ready in time because we are used to see gorgeous chicks - actually we have beautiful ladies from all over the world here (and many from Latin America too :-) as well as some of our own tribe - all the year long.)

So have fun - keep on developping great software :-)
(Berlin/Hamburg Germany)

by me (not verified)

Instead of reinventing the wheel, why don't they just try to fix the compatibility issues with ODF? You can't write ODF formulas (they're lost when you save them) and so you can't have any formulas at all in KWord's defauolt format.
The spreadsheet is a joke, Kword is fast, but lacks so many things... Only Krita seems to get proper attention.
So, why not make it usable after all and then start implementing innovations?

by Henrique Marks (not verified)

Good idea. I suggest we fork the project and implement what is missing. Contact me by email to do this, if you are really interested.

Why developers dont do this ? Because they do not want, and thats the point of open-source development: do it for fun, in the first place. i just hope all this work will bring a better koffice for all.

And i dont think kword is so bad, in the first place. i use it sometimes, and if any problem occurs and i dont like it anymore i can switch to openoffice anytime i want, thanks to the work of koffice developers who changed the file format.

I just don't have the skills :-)
The Koffice crew seem to be quite talented, it's just that it just isn't as good as OpenOffice yet, in my opinion. I can't really use it for real work (I've tried before), but I'd like to because it's promising and cool.

by Boudewijn Rempt (not verified)

Well, before I started on Krita I hadn't got the skills either. I had never written more than a dozen lines of C++, but it's an easy thing to learn on the job. It's just a matter of getting started and after that some perseverance.

by somekool (not verified)

lets make things straight. OpenOffice is slow as hell and unsable. their pretending compatibility with microsoft product is a joke. and only Microsoft Office really works with those documents. also OpenOffice only copy what Microsoft did and really does not improove anywhere.

KOffice however is lighting fast and has great stuff that no other suite has. it does miss few important features and still have bugs. but its a charm to use. I do use it for production use as well as many other KDE user I'm sure. ideas in this suit are way ahead and koffice is the only Office suite that actually considered what computer life will be from 2007

also remember there is not many koffice developers. and what they did since 1.0 is amazing. clap clap clap

keep going guys. you're doing an awesome job. dont listen to flamers and gives us the best office suite for KDE 4

gambatte kudasai

by Thomas Zander (not verified)

I support you implementing whats missing, very good idea! You don't even need to fork you can do it right into the KOffice svn repository, all you need to do is send in the patches.

by josel (not verified)

Great. Someone raises valid concern/criticism and you just tell him to code it himself. Regardless it its developed for fun maybe the developers would like to have and use the critique positively.
He's just wront about krita.

by Ariya (not verified)

What kind of concern/criticism? Let me quote: "The spreadsheet is a joke" does not tell the developers anything.

Not everyone has a crystal ball. At least, I don't.

by Juergen (not verified)

Even OOo Calc lacks some important features in the graphical representation of numbers. The scaling of x/y isn't up to snuff. Then the embedded programming language isn't really usable either for serious work. I use OOo Writer and sometimes KOffice (rarely) but Excel unfortunatelty is still way ahead and the only winDOS program of use (but big one).


by PGK1 (not verified)

OOCalc is a very good spreadsheet as I find it much more stable than MS Excel when working on the same large data sets. I tried to open up the same ODS sheets in KSpread but it crashed (perhaps 25 columns of 10,000-12,500 data points is too much?) but I do have a few things that OOCalc should have:

1. The ability to put the equation of the best-fit line ON the graph.
2. The ability to plot multiple data sets on an XY graph and have them be independent data sets as in MS Excel.
3. To not have to completely recalculate the graph if I move it on a page but do not resize.
4. To be able to scale the X-axis in a regular line graph instead of putting a marker for each X value down there.

by Anonymous Coward (not verified)

The spreadsheet _is_ a joke (or at least was last time I checked).

gnumeric is the only good spreadsheet I've found for any platform.


The charting-functionality seems to be pretty bad. When I use spreadsheets what I mostly do is dump in some numbers from somewhere, then graph them. With gnumeric it's a breeze .. with kSpread .. I don't find the graph in the image that is generated!


by Bilbophile (not verified)

I am not sure these are bugs, they may be a lack of features/immaturity of the concept. I do think that the metaphors used by KOffice make more sense than the ones of MS Office - cloned by OpenOffice.org - and I would very much like to learn it and use it for work and play.

Unfortunately, I translate doc and pps documents written by people who would not learn MS Office properly, let alone learn how to use another suite on a different OS altogether; or worse, I sometimes work on documents developed by several people - often embedding more different source data - with less experienced people ignoring and mangling the careful settings of the more experienced ones because of the dumb, opaque interface.

With KOffice I resent the lack of adecquate language tools and more importantly the lack of good compatibility with the MS Office file formats. Those are the reasons I am not learning how to use KOffice and why I use it only to edit/change the format of PDFs I occasionally have to translate.

on a different OS altogether;

Ermem, KDE 4 ==> Windows port. Can't wait to use a fully functional Koffice 2.0 in Windows.

by bug buster (not verified)

> you can't have any formulas at all in KWord's defauolt format

Fixed. Thanks for the support.

by Tim Beaulen (not verified)

Maybe you don't know this, but KOffice is being developed in three branches at the moment.

- A 1.5.x branch for bug fixes
- A 1.6 branch
- A 2.0 branch (which is trunk)

So, there still get many bugs fixed in the 1.5 and 1.6 branches, while all the innovations get added in trunk.

You're always more than welcome to help with any aspect of KOffice, there's more to do than only coding.

by Cyrille Berger (not verified)

Because some problems (like font kerning) can't be fixed without those innovation. And flake will bring some innovations, but it is first about code sharing between apps, which means that in the future instead of fixing a bug in kword, and in kpresenter, and in karbon and in kivio and in etc, you will fix in flake and fix for all. That's the innovative part of code sharing ;)

by Cyrille Berger (not verified)

Because some problems (like font kerning) can't be fixed without those innovation. And flake will bring some innovations, but it is first about code sharing between apps, which means that in the future instead of fixing a bug in kword, and in kpresenter, and in karbon and in kivio and in etc, you will fix in flake and fix for all. That's the innovative part of code sharing ;)

by Carsten Niehaus (not verified)

>The spreadsheet is a joke

What is wrong with KSpread? It is actually quite good and fast. .ods-import works well for me, only the diagrams keep me from using it (I am using the sloooow OOCalc2).

by James Richard Tyrer (not verified)

While it is my general position that more effort should be put into fixing bugs and I would always error on the side of caution when implementing new technologies, we have to consider that with version 2.0 KOffice will be based on Qt-4.

Therefore, this is the time to break binary compatibility and some wheels are going to have be reinvented for some of the bugs (that can only be fixed by going to Qt-4) to be fixed. The main example that we are all familiar with is the text formating issues which cannot be fixed with Qt-3's PostScript driver.

In some cases, it might be better to wait till after the 2.0 release to implement new technologies. But, there is always a trade off since it would not be possible to, then, replace existing APIs (that would break binary compatibility) but rather to only add additional APIs (all APIs in 2.0 would have to remain till 3.0). In this case, since KOffice is not really yet a mature application, I see nothing wrong with doing some things over if the current implementions are not working very well.

Bug fixes can continue with the KOffice version 1.x branches and can be front ported to the version 2 trunk.

by Nobody (not verified)

So is going to be possible to have multiple koffice apps running side-by-side and edit shared items between docs live, so that I could edit a kspread table that would be updated on kword doc, kivio diagram on kpresenter, or whatever combination sharing objects _live_ so I could instantly how the end result would look like?

As it kinda sucks to need to save/reload whatever object when doing docs.

by theorz (not verified)

That would be hot.

I spend so much time going back and forth between photoshop and powerpoint getting things just right.

by Corbin (not verified)

Already supported. Thats actually what the screenshot at the end of the article is showing.

by Stefan Nikolaus (not verified)

That's already possible: Insert a kspread object into kword. Select it. View->New View. Voila. All changes you'll make in one of the tables are immediately shown in the other representation.

by testerus (not verified)

What is the difference to Dynamic Data Exchange and Object Linking and Embedding in the Windows world? Or OpenDoc on the Mac?

by Tim Beaulen (not verified)

DDE is an interprocess communication control. Like DCop or D-Bus
It's not the same as Flake.

Flake lets you edit objects (created with another program) from inside a single program. So you only run one process.

I guess you can compare it a little with OLE, but it still is not the same.
Editing a spreadsheet from within KWord for example doesn't load the whole KSpread program. Only those tools or shapes that are needed.

by Eric Laffoon (not verified)

DDE was a very cool thing just as DCOP is today. I'm not as familiar with OpenDoc but I believe it is an embedding framework. OLE stood for Object Linking and Embedding, but it ended up meaning "One Long Expletive" when it crashed trying to do anything useful. When I left Windows in the 90s focus had shifted from DDE to OLE because MS preferred bloated embedding protocols to scripting. KDE's KParts and the Koffice libraries are more efficient, but the libraries you mentioned are more general purpose. For instance in Quanta we use KParts to load an application and DCOP to communicate with it. Compared to what Koffice is doing it's very rudimentary. Our interface is fairly rigidly defined to a full panel and we may find the plugin needs additional interfaces. With KOffice there is a lot more intelligent and defined interaction in the libraries inside.

by Madman (not verified)

On the subject of Quanta, is there going to be a KDE 4 port?

... I found that tool infinitely useful.

by James Richard Tyrer (not verified)

I continue to wonder why it is necessary to have separate Word, Spread, & Chart applications rather than having these integrated into one app that uses parts.

IAC, what I would like to see is to have it possible to link a number in a KWord document to a cell in a KSpread document and have it look just exactly like I had typed the number in the KWord document, yet if I change the spreadsheet, the number in the KWord document would change.

by Boudewijn Rempt (not verified)

Because for a certain task, a specialized interface is preferable. We discussed this a lot and came to the conclusion that it is much more userfriendly to have different interfaces for different main tasks. Especially the example of Gobe Productive argued in favour of our decision.

About sharing styles between different flakes -- that's something to consider. I don't know whether OpenDocument supports it, and if it doesn't, it will be hard to do, and getting inline data in a flake from another component will be a nice challenge, but as long as we're talking objects embedded in a text flake, doable. As long as OpenDocument supports it, of course.

by Thomas Zander (not verified)

Why apps?
because the user interface for a text processor still looks and acts more specialized for that type of data. Karbon will continue to have dockers and menus that are specialized for vector data while Krita will have menus with filters for bitmap data.
If all would be in one application we would either have 25 menus or alter our menu structure every time we make a selection. I somehow think that that approach will not be good for usability :)

The feature request for KWord <-> KSpread interaction is a good one, I'll push that out the the developers for consideration.

Thanks James!

by Thomas (not verified)

> we would either have 25 menus or alter our menu structure every time we make a selection.
Like MS Office does now? Funny how MS shoots it's customers in the knees over and over again...

by superstoned (not verified)

Have a look at Officd 12 - they did some great work on that app. It might look unfamiliar, but it works - seriously. The first thing from MS I would call innovation... It might not be totally new, but still its a great thing for Office.

by James Richard Tyrer (not verified)

Actually, I am only suggesting (at least to start) integration of the three major office apps: Word, Spread, & Chart. Embedding is sufficient for adding images.

Yes, the menu issue is one issue that would need to be solved to do this. And, I know that the KDE guidelines state that all operations that appear in toolbars must appear in the menu-bar menu.

I could probably list a handful of other issues, but I would look at these as challenges to be overcome rather than reasons not to try.

The first idea that comes to mind is to have a main menu bar that is always there no matter which part is active and an part menu bar for each part that only appears when that part is in use. I do not offer this as the ultimate solution, I am sure that with thought that we could come up with better ideas and refinements.

by Jonathan Dietrich (not verified)

see http://en.wikipedia.org/wiki/Archy for info about an app-less vision of Jeff Raskin. Very different way of looking at things.

by Jay Pee (not verified)

This has been done several years ago with StarOffice. That's why it takes so long to load, it is one app in different shapes. And as we know everybody complains about it being bloated.

by KDE User (not verified)

Why not name it something more glorious?

Like Koffice 2000, or Koffice 4 (KDE 4). Koffice XP. :-))