Kastle 2003: KOffice Developers' Meeting Report

Quite a few KOffice developers took the opportunity to meet during the Kastle event in Nové Hrady, and particularly to discuss the future of
KOffice after the next major release (KOffice 1.3 slated for the end of September 2003). A summary of the topics discussed follows.

Topics discussed
File format
We will switch to the OASIS
(OpenOffice.org) file format for all the major applications. This has many advantages:

  • file format shared with the OpenOffice.org suite, we don't have to
    reinvent the wheel
  • we'll be able to drop our OOo import filters and use the export filters
    as a compatibility layer for older KOffice versions documents
  • we can actively participate in the standard file format creation in the
    the case of Kexi and Kugar which are applications that don't currently
    exist in OOo

This is also a good opportunity to switch the names of our MIME types to the
vnd.kde... naming scheme and to drop our KOffice-specific file
extensions. It's again the users who will benefit from this step, e.g. on
Windows it will be possible to open files created with a KOffice application
using the OpenOffice.org suite.

KOffice libraries
We intend to break the binary compatibility soon after the 1.3 release and take
this opportunity to clean up and refactor kofficecore and
kofficeui libraries.

The next KOffice version will depend on Qt 4.0 which will have a better rich text engine
that we will reuse. Our text library (kotext) will be redesigned as
a thin wrapper around this rich text engine and will provide KOffice-specific
functionality only. (David)

The scripting library (koscript), currently used in
KSpread
only, will be rewritten from scratch to provide a new light-weight formula parser.
(Werner, Ariya Hidayat)

Kexi
It is still unknown whether Kexi
will be released separately later this year. Otherwise it will definitely
be part of the next KOffice version. The problem is that Kexi's core API
isn't stable enough yet so it makes no sense to do a separate Kexi release
which would depend on already obsolete KOffice libraries. (Lucijan)

KChart
Big thanks go to Kalle who finally imported KDAB improvements and fixes into
KOffice CVS.

Scripting, automation
We decided to use kjsembed
engine as a foundation for the new KOffice internal
scripting engine. It will allow users to write their own wizards, interactive
forms or scripts using JavaScript and Qt designer forms. Work is also being
done on KDevelop side which will provide an IDE these tasks. (Zack)

Spellchecking
Current plans are either to rewrite the current API after KOffice 1.3 and KDE
3.2 releases or to reuse the newly born Enchant
backend neutral spell checking engine. This architecture will have 3 layers:
different backends, a core library and dialogs. (Zack, Laurent Montel)

Common canvas library
The plan is to have a common canvas class that KOffice applications could
reuse for their own drawing needs. Currently there exist different
implementations in
Karbon14,
KPresenter and
KSvg.
The goal is to have a common library so that also other applications
can draw various shapes without the overhead of KParts embedding.
(Rob, Lukas, David)

Ongoing work
The KOffice developers are currently busy fixing various issues so that we
can ship a stable release candidate at the end of this month.

  • fix spell checking (Zack, David)
  • checking that language property is being used for different portions of
    text (David)
  • fix the character (font) dialog in KWord and KPresenter (David, Lukas)
  • continue KPresenter bug hunting (Lukas)
  • discussions about future drawing objects and common canvas functionality
    (see above)
  • discussion on table-frameset design (KWord developers)
  • Kexi hacking (Lucijan, Joseph, Holger)

Developers present at the meeting
Lukáš Tinkl (release manager, KPresenter)
David Faure (KWord, libraries)
Werner Trobin (libraries, filters)
Zack Rusin (filters, spell checking)
Lucijan Busch (Kexi)
Joseph Wenninger (Kexi, Kugar)
Alexander Dymo (Kugar)
Andrea Rizzi (KFormula)
Thomas Zander (KWord)
Rob Buis (Karbon14)
Holger Schroeder (Kexi)

Dot Categories: 

Comments

by Richard Moore (not verified)

Nice to see you've decided to use KJSEmbed. Feel free to make feature requests.

Rich.

by rjw (not verified)

Would it be difficult to extend Kjsembed to more than just ECMAscript?
Is the introspection of QT stuff separated from the KJS binding?

IE Can we look forward to python scripts in Koffice? ;-)

Another interesting point would be to expose all these bindings via DCOP for interprocess scripting .. or is this already possible?

by Richard Moore (not verified)

It would certainly be possible to write an equivalent for python, but I have no intention of making kjsembed itself language independent. I think the disadvantages of having a mixture of languages used by different scripts out weighs the pretty minimal gain of supporting more than one. After all, once you support python, why not perl, ruby, scheme etc.

Ian Geiser is working on DCOP support for kjsembed, I'm not 100% sure how much is working right now.

Rich.

by Ian Reinhart Geiser (not verified)

it can now crash the remote app :)

the dcop command is getting through but something is going wrong communicating variant types. lastly i have started on adding the ability to create dcop interfaces in a kjs script but this code needs to be rethought.

by Eric Laffoon (not verified)

I'm very interested in this to see how it may be useful for Kommander, which provides language neutral dialogs with optional scripting. I do my best to follow it, but if you could keep me advised that would be great. As much as I think KJSEmbed is great and a generally good choice for this I think that being able to shell out from an app and run Kommander with DCOP and the option of using any scripting language is worth having too.

Also congrats to Rich on this and all his hard work.

by rjw (not verified)

It seems insane to me to want people to rewrite the scripting language independent parts for any other language they want to use.

The point is, we are going towards a mini-ide being accessible from KOffice. How much of this is js specific?

The other thing is, if we are going toward OOo, and want to import MS office files, why would you want to make it harder to support (shock, horror) VB properly? (Maybe via mono, or something).

by Norbert (not verified)

Yes, python scripts in KOffice are possible. I already have a "Prove-Of-Concept" plugin for KSpread on my hard disc, but it is outdated and doesn't work with 1.3. Maybe I will look into this again, once I get back to develop on KSpread in mid of September.

by panzi (not verified)

If there would be a poll, I would vote for python. :)
JavaScript is nice, but it's OOP features seem a bit hackish.
I like python and python is very commonly used.

by Carlo (not verified)

The planned features sound well, but using JavacSript just sucks.

by Richard Moore (not verified)

Why does it suck?

Rich.

by TomL (not verified)

I think you're just running up against one of the many python advocates. Python seems to be very popular amongst KDE users and as far as many are concerned, if it only had python they'd be pretty happy. Eric Laffoon has had a lot of discussions on the dot about this and his competing vision about scriptability.

Note that I'm a big fan of python too. It's my favorite language, too. But I do appreciate the work you are doing on kjsembed.

by Richard Moore (not verified)

I like python too, but i don't think it's the right language to use here. It is a lot larger than KJS and much more complex. It would be slower to load, add considerable memory overhead etc. (bear in mind that most apps already have kjs in memory through kdeinit). It is also harder to lock python down for security (and no bastion is not good enough for this).

Rich.

by Eric Laffoon (not verified)

> I think you're just running up against one of the many python advocates. Python seems to be very popular amongst KDE users and as far as many are concerned, if it only had python they'd be pretty happy. Eric Laffoon has had a lot of discussions on the dot about this and his competing vision about scriptability.

And please, if you're going to mention me at least through in a few words about what I'm saying. I don't use Python personally. I also don't think my vision competes per se with Rich's. I like to think they are more complementary in application, but I do believe that the greatest level of user support is achieved by a language neutral approach. It will see the widest acceptance and least complaining about languages. It will not however have all the inherent power of KJSEmbed.

The bottom line is that people don't usually want to learn another language to do something when they are proficient in a different one they prefer. This means some people will avoid using these extentions, and not just the zealots. If you think about it, it's not difficult to imagine having to use a handful of scripting languages with a number of applications. Whatever the benefits of a particular language are it is difficult to outweigh user resistance and saturation of frustration.

FWIW I happen to like Javascript, I think KJSEMbed is cool and I salute Rich in his work. ;-) I'm also working on Kommander as a language neutral solution because I believe it has a somewhat different target audience. (Plus we've had it for some time now.) Choice is good.

by Debian User (not verified)

You are the wrong person to address it to. But I wish the KOffice developers would rather pick Python. This will give a more feature rich language with a lot of modules to make use of other programs.

But you can probably tell us if KJSEmbed has an API interface that e.g. KPythonEmbded could also provide.

Yours, Kay

by Carlo (not verified)

I just don't like the language. I admit that I'm not impartial - it's more a personal thing. I just don't see a reason to use it. JavaScript has no advantage to other languages imho.

by Tim Jansen (not verified)

It has the very nice feature of a prototype-based object system, which IMHO is much easier to understand than the class-based object system that is used by all other popular programming languages. It is also the only mainstream scripting-level language which uses a C-like syntax, which is quite nice for many programmers (but unfortunately reduces its mainstream-appeal a little bit).

by Carlo (not verified)

begin
write('prototype-based oo: to be as flexible as a spaghetti?!');
end;

scnr ;-)

by Alex (not verified)

I am totally for using the OO.org format, it has tremendous advantages.

The more applications usinte and use the format the stronger we will bea gainst MS's and it also allows greater compatibiltiy with our own appliations and other platforms.

by AC (not verified)

It fits greatly in the long term world domination scheme, don't it? ;)

by Magnus Johansson (not verified)

I'm not so happy to hear this. As someone who has done his share of import filter implementation, I've learned that the file format reflects the features of a program. If koffice adopts the OO-format, I'm afraid it might set an upper limit to what features will be possible to implement in koffice. koffice will never be able to go beyond what OO provides, featurewise (at least when it comes to features that require support from the file format).

The two main problems with doing import filters are:
1. The importing program lacks features the exporting program has.
2. The features match, but are implemented differently (the file format often reflects the implementation details).

1 can't be solved, unless the missing features are implemented.
2 can often be solved, but it is often trickier than expected.

To those who claim XML solves the problem by being extensible: If the file format is extended to let koffice implement features not present in the original OO-format, both problem 1 and problem 2 above will show up, and you have gained nothing by using the OO-format. (One of the formats I wrote filters for actually was an XML-format, and I had both problems.)

My suggestion: Keep the koffice format, or change it to suit your needs, but don't depend on others. Make sure everything is properly documented, and write the necessary filters.

I'm afraid the whole file format mess will persist. The problem is not that each program has its own format (that's the way it should be IMHO), but rather that users distribute files in formats that were intended to be used when writing the document. They should instead distribute the files in a format that was created for distribution purposes (e.g. pdf, html, rtf). I realise that this is not always possible since there doesn't exist that kind of format for every application domain.

Sorry if I'm ranting ;-)

/Magnus

by Luther John (not verified)

"They should instead distribute the files in a format that was created for distribution purposes (e.g. pdf, html, rtf). I realise that this is not always possible since there doesn't exist that kind of format for every application domain."

Hello Magnus!

The problem is that in the real world, users can't possibly always do this. My entire office has years and years of (perhaps gigabytes) of MS Word proposals, hundreds of PowerPoint presentations, and a great deal of MS Excel spreadsheets. There are also a lot of very old WordPerfect documents, but those are from the earlier 90's.

We have a enormous investment in MS Office, and currently, 100% of the office machines have MS Office loaded in them. When people in our office need to take home, 99% of the time, it's not a problem because they have MS Office at home.

The problem is for the other (growing) 1%, like me. It's a huge barrier to switching to some alternative OS like Linux without having compatability with existing documents, and being able to effectively communicate with others (which means, the ability to export MS Office docs is important too)

In fact, I was pretty much a hobbist with Linux until OpenOffice came along. Since then, I've been able to switch to Linux full time at home. I've also been using Koffice for years, and I love it's interface compared to OO's crappy interface, but I couldn't really use it for anything serious. And I still can't until there is a way to natively open MS documents (wether it be through OpenOffice, I don't care..)

To me, Koffice doesn't really need to have any more features than OpenOffice.. it just needs to provide a better interface than the crappy java OpenOffice interface.

by Magnus Johansson (not verified)

"The problem is for the other (growing) 1%, like me. It's a huge barrier to switching to some alternative OS like Linux without having compatability with existing documents, and being able to effectively communicate with others (which means, the ability to export MS Office docs is important too)"

I agree with pretty much everything you say, but IMHO the solution is not koffice swithing to the OO-format, but rather work on the import/export filters.

I don't think it's wrong if they base the koffice format upon the OO one, but if they restrict themselves from extending and/or modifying it to suit their needs, they're making a mistake IMO.

(Disclaimer: I haven't looked at either file format, but AFAIK they're both based on XML. I have, however, done similar work in another application domain.)

/Magnus

by Peter Simonsson (not verified)

David Faure is a member of the OASIS group that works on the standard, so I'm pretty sure he will cater for koffice's needs. :)

by Nicolas Goutte (not verified)

Nobody has said that there will be no private extensions ot the OO format (OASIS being a public extension compared to OO version 1.0) But I think that we need long before we even get to that border.

As for working on import/export filters, sorry, but when there is not any programmer, you cannot do much. (Volunteers, email to [email protected] please.)

Have a nice day!

by Nicolas Goutte (not verified)

I have some problems to follow.

If we have decided to change our file formats, it is because we do not want to keep the old ones.

So I find that it is better to take a good foundation like the OO format and to build on it, instead of creating again private file formats. Sure private extensions (not necessarily from KOffice) will surely exist, they exist too in RTF. But even in such a document, you can read most of it (instead of nothing.)

As you have written, using XML does not give the solution by itself. Yes, Abiword's file format is not KWord's is not OOWriter's. That is exactly our problem. That is why we try to find a solution.

KOffice just cannot remain an isolated solution, not even (or barely) available on Windows.

Document the file formats? Writing filters. especially for other applications? Nice, but where do you get the manpower? Someone in AbiWord's bugzilla (#1144) asked if a KOffice developer could help with their KWord filters. What can we answer for now? Only: "no, sorry, no people!" (I have not even dared to give this answer yet.)

By the way: if people want to volunteer, please contact: [email protected]

Have a nice day!

by Magnus Johansson (not verified)

"So I find that it is better to take a good foundation like the OO format and to build on it, instead of creating again private file formats. Sure private extensions (not necessarily from KOffice) will surely exist, they exist too in RTF. But even in such a document, you can read most of it (instead of nothing.)"

From the article I got the impression that you wanted to use the OO format as it is, not as a base. If you are not happy with the current format and want to switch anyway, and don't mind adding to the OO format, I agree that you should change.

"By the way: if people want to volunteer, please contact: [email protected]"

I probably will at some point, but it will (likely) not be file format related work I volunteer (I've done enough to know that I don't like it :-). Until I find the time needed to actually contribute, I lurk on the mailinglists and share my thoughts on things I've some experience with and hope that it will be useful to someone.

Regards,
Magnus

by Nicolas Goutte (not verified)

In fact we plan to switch to the OASIS format, which is based on OO. As long as David Faure is part of OASIS, it is better to try to make any extension part of OASIS. That is why I suppose that nobody is talking about private extensions.

Thank you to have thought about contributing! If you know so much about file formats, perhaps you could help use with the filter pages ( http://www.koffice.org/filters .) You would need to know about XHTML 1.0, PHP 4 and perhaps XSLT 1.0. So perhaps you could use your knowledge.

Have a nice day!

by Chris Evans (not verified)

Based on what I've read, OASIS is NOT "the OpenOffice" format. OASIS is an independant organization dedicated to creating an open file standard for commonly used business applications. It just happens that OpenOffice.org adopted it first. But I don't think that necessarily places any restrictions on what KOffice will or will not be able to do with the formats. What it does is levels the playing field and places emphasis on chosing, say, a word processor based on what it will do for the user, rather than having to worry about who will be able to read the file type, an idea I'm totally in favor of. This could be the one thing that helps to break the office suite monopoly that Microsoft has such a strangle-hold on. Just remember that in the audio world, the MP3 file type has been embraced completely; no one complains about limitations, and everyone uses which ever recording or playback application they choose. The result is an audio file that can be played back on just about any kind of software or hardware available. I firmly believe the same will happen with office documents with the adoption of the OASIS standard.

And that will put KOffice in a decided advantage over OpenOffice, which is huge and relies too heavily on Java.

Bravo, KOffice team...keep up the great work.

by Nicolas Goutte (not verified)

Just a little note: the OASIS open office format is based on OO's file format, even if at the end it differs in many details.

Have a nice day!

by Charles de Miramon (not verified)

I'm wondering what is the status of the new import / export MsWord library that Werner Trobin is working on ?
Importing seems to work already quite well but is exporting still a distant dream or can we expect at least basic exporting in a non-too-distant future ?

Cheers,
Charles

PS: switching to Oo formats is a very intelligent move

by Werner Trobin (not verified)

Well, I dropped the idea of creating the export code. One reason is that it's just an insane amount of work and I'm only one person with a very limited amount of time. The second reason is, that it's possible to express 100% (yes, really 100%, just read the RTF spec on MSDN) of the MS Word features using RTF. Due to that I'd rather help with RTF export than waste my time on direct .doc export.

Ciao,
Werner

by Charles de Miramon (not verified)

Thanks for answering...

If the RTF export filter is going to be the future path for exporting to MSWord. Could KOffice developers implement the 'Abiword trick' : id est having a .doc exporting filter whih is a rtf file with a .doc extension. I guess, it is rather easy to code and will make life easier to users that don't know what is RTF (or Rich Text Format)and don't want to know.

Focusing on the RTF export filter is definitely the best option. (Power)-users can much more easily create test cases, look the exported rtf code, try to understand where it went wrong and help the developers. Something you can't do as easily with the binary .doc format.

Cheers,
Charles

by Nicolas GOUTTE (not verified)

RTF as .doc had been discussed in the past but never implemented

Have a nice day!

by Alan H (not verified)

I should point out that the "Abiword Trick" has good precedent.

Microsoft Wordpad does not export Binary .DOC either, it only exports RTF renamed to .doc

I also recally Wordperfect and Microsoft using the .doc file extension fairly arbitrarily for various formats including Text and RTF.
There are so many version of DOC anyway that quite quickly you need a riguorous file detection algorithm.

While I am here cheerleading for Abiword I may as well mention that it would be really great if KDE users could take a look at making Abiword blend in better with KDE, I am reliably informed that Abiword follows the freedesktop.org icon specification and should be able to use KDE icons when run in KDE.

by rjw (not verified)

I never knew you could get OLE streams into an RTF file. How is this done?

by Charles de Miramon (not verified)

You can embed an ole stream in a RTF file, for example a Excel datasheet in a Word document with the \object tag.

IMHO, embedding one application into another in MSOffice or KOffice is a nice technological trick but is a recipe for ugly looking printed documents because the two applications use different typographical engines, or different fonts. It is also a hog on ressources on a slow computer. It is much more useful, to have intelligent cut&paste for example a wizard to transform a KSpread table in a KWord table.

Cheers,
Charles

by Andy Parkins (not verified)

This is all very well until you want to edit the embeded object. For example, making an invoice: I want the spreadsheet for doing all the formulaeic work and the word processor for putting some nice headers and footer and any covering text in. And then I want that to be a template so I can use it again. As far as I can tell, intelligent cut and paste just won't cope with that sort of job.

Obviously the option to intelligently remark the is nice to have available but I don't think that should preclude the addition of an embedded facility.

by johannes wilm (not verified)

Well, RTF-export is nice. However, there don't seem to be many people around understabnding that code. I tried sending different people code to let the rtf-filter handle tables with only 1 line needing to be changed... I got the answer that nobody had the time/knowledge so that tables will be disabled in rtf-export for 1.3.
I hope that changes some time in the future.

by Nicolas Goutte (not verified)

Can you re-send that one line of code? (Or point to where the patch is on http://list.kde.org .) I am interested about it.

I am sorry but I was out of "business" for a few months, so I have missed your patch.

Have a nice day!

by Johanneswilm (not verified)

Hi again,
well my HD has broken down since then, but the newest patch I send I could find on koffice-devel is at http://lists.kde.org/?l=koffice-devel&m=105756234418255&w=2 .
The line that needs to be changed is the one starting with "FrameData frame =" .

by aleXXX (not verified)

i.e. the next koffice version (1.3) will be the last which works with KDE 3, and KDE 4 ain't even scheduled yet (AFAIK)

Bye
Alex

by ac (not verified)

I'm sure there will be 1.3.x releases as necessary.

by Strider (not verified)

The talk is that Qt 4 will be release middle of next year and that KDE 4 will be the next release after 3.2. At least that is what I have been hearing today.

Strid...

by Nicolas GOUTTE (not verified)

Well, you can see the need in two ways:
- KDE 4.0 will need a KOffice version, so why not a new one.
- the new Koffice version will need time to be done (for example file format switching) and could improve due to Qt4 (for example in KoText, the text engine.)

Have a nice day!

by panzi (not verified)

I wonder what's the difference between QSA and kjsembed.
I know kjsembed adds some nice features, but else it's compleat the same? Eaven the cpp source? If that's true, why is kjsembed LGPL and QSA GPL?
I'm confused.

(And when will KDevelop support JavaScript?)

by Vajsravana (not verified)
by yg (not verified)

looks like this has been read: http://www.mind.lu/~yg/office.html

... ;-)

so now we gotta convince Abiword and Gnumeric developers...

by Maynard (not verified)

A little wrong here though. I think Gnumeric beats OOo calc anyday. It is really quite amazing. I do wich they could use the same file format though. That way, they could probably cooperate to use the same export filters too.

by James Richard Tyrer (not verified)

Much of what: http://www.mind.lu/~yg/office.html says is simply wrong.

What does it mean that you have to "deal with Microsoft Office (MSO) files"? Does this mean that you have to be able to open them in an application so that you can edit them, or does it mean that you just have to read them somehow?

This is an important distinction. Does this "you" really need import filters or just a way to view the file? It would appear to me that it would be MUCH simpler to make (or reverse engineer the MS one) a file viewer than to make an import filter.

And the printer example is even dumber. Hasn't he heard of PDF. Which also means that you don' have to ask somebody to send you a "weirdo-0.00001%marketshare.xxx format???" file, you need to ask them to please send you a PDF.

--
JRT

by anon (not verified)

> And the printer example is even dumber. Hasn't he heard of PDF. Which also means that you don' have to ask somebody to send you a "weirdo-0.00001%marketshare.xxx format???" file, you need to ask them to please send you a PDF.

Most windows users don't know how to make pdf's. They are pretty uncommon in the buisness world compared to .doc's. Having MS Office compatability is *wayyyyyyyyyyyyyyy* more important for most users of koffice than having good pdf compatability, although it'd be nice to have both :-)!