Category: koffice

Well, only a soft freeze, not hard yet. But that means that we won’t add new features to KOffice anymore that haven’t yet been announced in our feature plan. And those features, even though in the plan, that haven’t been at least a little credibly implemented by September 16th won’t make the cut for 2.0.

What does that mean? Well, our blogs will become a lot more boring. We’ll be doing more and more stabilisation work. And more and more bug fixing. And more and more smoothing out of wrinkles. And more and more things no-one can interpret as a “promise”, even though it’s only the enthusiastic articulation of a developer in the heat of the hunt.

On the other hand, we’ve been working on KOffice 2.0 since 2006. That’s right — we started porting KOffice to Qt4 and KDE4 March 27th, 2006. And it’s no denying the road has been gruelling. Really, I totally grok the GTK people who don’t want an api break for GTK 3.0. On the other hand, unless GTK gets gingered up a lot, any GTK app will be too nineties for words in a year or two.

And moving an app over to a new API is only the beginning. Frictions among KOffice developers, chasing the taillights of kdelibs, Qt4 that wasn’t really as excellent as it should have been until 4.3, personal things like job or house changes, an increase in bad manners among the general public (although I remember saying the dot wasn’t any fun anymore in 2006 already). Sometimes the fun and excitement was hard to find. And now we’re in boring stabilisation mode again…

And I’m still worried about sustainability. I worry whether it’s possible to write world class office software with more or less one part-time coder per application. Especially when that part-time aspect gets eroded by days jobs. That is why it’s so great that NLnet sponsors us, with money for logos and money for Girish Ramakrishnan to really focus on some issues. But we really need more people!

You don’t need to know C++ — we can teach you that, no problem. And despite the aforementioned frictions we’re a nice bunch of people, really. And we’re pretty patient with questions. We cannot promise money or riches, but we can guarantee fame and fun! And we’re committed — we’l go on and on, alpha after alpha until we have something we dare call a beta — and then we’ll go on and on until we’ve got a release candidate.

And KSpread runs, too!

And KOffice trunk, of course, compiles with CMake, and I must say, I rather like CMake.

Today is a big day for KOffice — Laurent and David have starting porting trunk to Qt4/KDE4. That’s great new — and a lot of work has already been done. Cyrille has started coordinating the 1.6 effort — a feature release for Krita, Kexi and KChart. I’m bugfixing already for the successor to the first release candidate for KOffice 1.5. Had a nice chat with Thorsten about tools for flake. Lots of activity, very bracing.

On the other hand, koffice.org is down so we cannot release 1.5 rc1 even though everything is ready!

Yesterday, Rob, Casper, Thorsten, Peter and I discussed the architecture and the design of our new shared KOffice-wide graphical object library.  When taking a short breather, strolling through the snow we decided to provisionally call this library Flake — after the complex shapes that were filling the night sky.

The goals of this library are to have in all KOffice application that can use graphical objects like clip-art, stencils, borders, animations, embedded movies and whatever:

• Common object handling in all libraries: the same user interface for creation, selection, moving, resizing, snapping to rulers and guides etc.
• A simple object hierarchy with a common manipulatable base object class and subclasses for svg objects, lines, movies, embedded documents and text objects. Svg objects and lines should always have the option of an associated text object.
• Color management (may be hard to achieve with Arthur)
• Connectors and snapping
• Excellent printing
• The possibility of adding high-level behavior to objects (click on an object and move to another page in Kivio.
• Copy and paste and drag and drop in and between applications
• Saveable in OASIS
• Inspector widgets
• Undo and redo (of course)
• The objects render themselves to a QPainter
• Oh, and while we’re at it, let’s try to get a common ruler implementation, shall we?

What we don’t want to do is:

• KOffice independent. Initially it will be, because we’re developing on Qt4, but it’s no hard requirement, unless people from outside KOffice start helping and hacking, perhaps.
• No canvas. This is no canvas library: every application will have a canvas optimized for the kind of things it needs to do (although Karbon14 and Kivio will merge their canvas and use the same thing.)
• Creation of complex svg itself: use Karbon14 or Inkscape for that
• Save in KOffice’s old file format

Of course, we immediately started hacking, and we can already put a red square with a black border on screen and manipulate it! Our first bit of Qt4 code. Impressive isn’t it?

I may be missing the Libre Graphics Meeting (but Cyrille is going to hold up the Krita banner), but we’ve got our own little KOffice Graphics Meeting here in Deventer this weekend. Peter Simonssen (Kivio), Thorsten Zachmann (KPresenter), Casper Boemann (Krita) and Rob Buis (Karbon14) are here to discuss how we’re going to handle graphical objects in KOffice 2.0.

Rob is right now typing up a list of items from our initial dinner discussion: Common handling of complex graphical objects, connectors, color management, fine-grained application integration (objects, not documents!) and shared canvas have been discussed tonight. And tomorrow we’re going to do some real discussion, design and perhaps even API stubbing.

Thorsten and Casper have arrived — at least, Thorsten has just arrived, but Casper and I have been hacking all day on Krita already.

Rob has joined us.

Peter has arrived from Sweden — time for dinner and initial exploratory discussions, interleaved with preparing the KOffice 1.5 beta 2 release. Tomorrow we’ll do the dot story… Everything is prepared except the kliks, but Kurt Pfeiffle is busy bribing Isaac to prepare the debs…

As Bram notes, Krita still crashes now and then. We did fix most of the performance issues last week, and Krita is unlikely to become any faster before the release. But since the last beta, Krita got about 500 commits; and KOffice as a whole another 1000. KPlato, KSpread, KWord, Kexi, the libraries, KChart, KPresenter. Lots of new code. And as anyone knows, lots of new code means lots of new bugs.

So, fairly unanimously, we decided to do a second beta release and slip the final release until April 11. I do hope the second beta will get a lot of testing: I mean, the first beta was really easy to test thanks to binaries for Debian, Kubuntu and SuSE, not to mention the kliks. Nobody has an excuse for still filing bugs against 1.4.2! Even the first 1.5 beta is much better than the 1.4 series.

And it’s really, really, really, really important that users test these packages. Developers do not find bugs: developers seldom have time to actually use what they work on, and developers know the safe path
through their code instinctively. And we have only a very limited mix of environments. No ppc, for starters, and a small set of distributions.

So: if you’re a user, and if you’ve had a crash in a Krita beta (or in any other KOffice application, but I’m the guy you need to approach for Krita crashes), please, please, mail me the backtrace. I’ll get back to you right speedily and either tell you it’s something I just fixed, it’s something I’m fixing right now, it’s something I will fix soon, or something hard and complicated. If the latter, I’ll ask you to file the bug in kde’s Bugzilla. I don’t need you to look in bugzilla first to check whether it’s a known bug, if it is, I’ll tell you, and still thank you for your help.

Without your reports, the crashes you experience will in all probability not get fixed: it is entirely probable that neither me, nor the other Krita hackers experience those crashes. You get a crash, you mail me — and then I can try to fix it. No report, no fix, and crash bug in Krita 1.5. That’s the deal.

Note that I do not read web forums, do not regularly check blog comments, hardly ever read usenet and am a lot less available on irc than some time ago — you need to mail me (or go to bugzilla directly, but I prefer an initial mail), otherwise I will not see your report.