Under the KDE umbrella, the KOffice project took part in the 2006 Summer of Code with four participants. And not only that, but the Dutch Programmeerzomer, sponsored by Finalist, also selected a KOffice project. The summer is over, the season of mists and long hacking nights has arrived and the question that's obviously in everyone's mind is, have these five delivered? -- and, more importantly, will Gabor, Alfredo, Emanuele, Thomas and Fredrik continue hacking on KOffice?
Emanuele Tamponi: Krita
Emanuele Tamponi, an 18 year old student from Calangianus, Sardinia
had the ambitious plan to add three important features to Krita:
- a bezier curve tool with stroking using Krita brushes
- a selection tool based on the bezier curve painting tool
- a magnetic outline selection tool
Emanuele himself says:
My SoC application was split in 3 parts: firstly I had to code a framework
to handle curves (that are lists of points, managed by "special points" or
"pivots"); then I had to deploy a tool for Bezier Curves and for Magnetic
Outline Selection based on the Framework.
Bezier Curves are curves created by applying a recursive function on a set
of up to four points: the result is a smooth curve, ideal for all types of
design (from cars to fonts...).
Magnetic Outline Selection (MOS for short) is like the "Magnetic Lasso"
tool from Photoshop or the "Select part of the image" (Scissors tool) from
the GIMP. My MOS just behaves better than both:
First I compared two tools for the "intelligent scissors": Photoshop one
and gimp's one.
1) Photoshop follows your mouse while *moving* (not just dragging) it,
adding other control points when the mouse is getting too far from the
last control point. This way, it can be fast (just small area of the image
are computed) and precise (because it *follows* the mouse, so it follows
the edge that *you* want to select).
2) Gimp does it in a more "standard" way: it calculates the edge between
two clicks of the mouse. It's fast because it calculate the edge only once
per click, but it's not precise because you can't see the curve generated
*while* you follow the edge.
But gimp gives you the possibility to *edit* (moving or deleting) already
inserted control points, whereas Photoshop can only delete the last
inserted control point, without other types of editing *during* the line
makeup (with Photoshop you can edit the control points *after* you close
the curve, and this is not always the right solution).
My MOS mixes both: it follows the mouse as Photoshop does, but if you want
to edit a control point, you just hit "Ctrl" and you switch to Editing
Mode, then edit, add or delete the control point you want, and when you're
done, you can either it "Ctrl" again to return to "Automatic
(Photoshop-like) Mode", or hit "Enter" or the button on the Options Widget
to end the selection.
Emanuele was mentored by Bart Coppens and did indeed finish his project on
time and on spec, and is now getting ready to port his work to KOffice 2.0.
His tools will first be release in KOffice 1.6 -- real soon now!
Alfredo Beaumont: KFormula
project consisted in adding full native support of MathML / OpenDocument
format to KFormula. There were also some related tasks that needed to be
accomplished, such as improving mathematical font support, rewriting user
interface to take advantage of new functionalities allowed by MathML and
extending / rewriting old native format code for backwards compatibility.
I think that project was quite successful, even if I haven't reach 100% of the
objectives. We have now native support of both MathML and OpenDocument, with
an internal layout that resembles very well these formats' layout. We have
achieved nearly full support (more than 70% of tests passed, comparing to 20%
of old KFormula and 22% of OOMath2). New font engine has been developed,
replacing old TeX font support with new Unicode font support. KFormula now
includes Arev fonts with great mathematical support by Tavmjong Bah, and
allows the user to choose whichever Unicode font they have installed. That's
all I did during SoC period, but till then I have been working in the fourth
task, and some UI changes have already been added. All these features can be
seen in action in KOffice 1.6 beta that will be released in a week. Still
improved MathML / ODF support, refined UI and extended old format are
expected for final 1.6 release.
A preview of the work done can be seen in the screenshot: Navier's equation
with each part of the equation highlighted with a different background.
Alfredo is now the official maintainer of KFormula. His mentor was David Faure.
Fredrik Edemar: KWord
Fredrik Edemar, a computer science student from Uppsala, Sweden. has
have worked on two smaller projects: automatic heading recognition in KWord
and version support for all KOffice applications. Both these new features
will be included in KOffice 2.0.
KWord now recognizes headings and puts them in a tree view. This makes it
easier for a user to get an overview of large documents. From the list, it is
possible to move and delete headings.
Version support can be very handy if several people are writing in one
document. Let us assume that the first user saves the file, and the next
wants to make changes. Then she can create a new version with the old
content, do her changes and finally save her work. In that way it is possible
to later go back and see what the first writer saved. The versions are off
course stored in the OpenDocument file format.
Fredrik was mentored by Boudewijn Rempt. As soon as the current sweeping redesign of KWord's
frame system is done, Fredrik will port the header feature to KWord 2.0; the versions feature was
developed in 2.0 already.
Gábor Lehel, KOffice core
Mentored by Cyrille Berger, Gabor Lehel coded a second-generation widget for all of KOffice, based
on his work for Krita's layers widget.
Many of KOffice's applications use a similar concept for dividing documents up into parts.
Krita and Karbon have layers, KPresenter has slides, KWord has pages. I wrote
a widget to display a list of these in a uniform way across KOffice 2.0 applications.
It is implemented as a QAbstractItemDelegate and likely a QAbstractItemView subclass,
and each application can provide their own QAbstractItemModel subclass, tailored to
the application's data format. Two main view modes have been created: a thumbnail view with only
large thumbnails and possibly a name / label below them (as in KPDF), which would be most
suitable for KWord and KPresenter, and a detailed view, with smaller thumbnails and
information next to them, including editable properties (as in Krita 1.5), which would
be most suitable for Krita, Karbon and Kivio. But all applications can show both modes,
so it's possible to get really large layer previews in Krita or detailed meta information
about pages in KWord.
Thomas Schaap: KOffice Core
Thomas Schaap studies in Delft, the Netherlands and was selected by Finalist to participate
in the Dutch Programmeerzomer. Having wanted to work on KOffice for quite some time, he grabbed
this opportunity to really get into KOffice. Brad Hards was the real, practical mentor,
while Boudewijn Rempt was his pro-forma mentor.
The project was to provide support for encrypted documents in KOffice. The big difficulty, which is still not completely solved, is compatibility with OpenOffice encrypted
documents. Thomas not only had to learn KOffice and its development culture, but also needed to learn
about OpenOffice and find his way on their mailing lists. And then, of course, Thomas needed to
work in KOffice trunk. The day his project began was also, coincidentally, the first day that KOffice
2.0 actually compiled against KDE 4!
But despite these difficulties and a very tight schedule,
he managed to finish all core functionality and get it checked in -- as Thomas says himself: "I did
a good job of, the KOffice guys are really happy with what I did." Next stage: signed documents!
Five projects, five successes! Thanks Thomas, Gábor, Fredrik, Alfredo and Emanuele for your
work, and thanks Google and Finalist for organizing these projects!