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, 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!

My SoC
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!

Conclusion

Five projects, five successes! Thanks Thomas, Gábor, Fredrik, Alfredo and Emanuele for your
work, and thanks Google and Finalist for organizing these projects!

Most of kdelibs is LGPL. GPL can be linked to LGPL just fine. Why do you think there are businesses like The Kompany (i.e.- http://www.thekompany.com/home/) that creates semi-closed source software that uses kdelibs?

yeah, i'm impressed. i mean - helloooooh, version support!!!!! that's soooo cool... i hope it has/will have a good gui, a timeline and it'll keep the undo after subsequent savings - these things i've been looking for for a long time.

i would also love some way to attach/embed some text snippets, alternatives, to (parts of) documents. i often have a second or third alternative for a paragraph with text - and i'd love to be able to save them some way. but i guess that's a little too much to wish for, and there are much things which have higher priority ;-)

It would be awesome to have some sort of versioning system for documents... like when you save, you can save it as a more recent version, but still keep all the previous incarnations in the same file. Then have a view mode that lets you see the document with all the previous versions at the same time, in a heirarchical view, in reverse chronological order... maybe even let you pick out, paragraph by paragraph, the version you want to keep, then at the end, view what you picked as a coherent document. It might help to have some sort of plugin that runs diff on each section of text against every other section, so as to weed out duplicate paragraphs. This would be quite awesome.

Congratulations to all of the five! It's great to hear about these developments and potential new developers!

I've heard that the bezier-code won't be used in krita2.0, since that will use flake, and that will somehow replace the current bezier code. I hope that it will live on in flake?!

I think the layers/parts-widget still needs a lot of tweaking: First, it wastes a lot of space, like many such widgets in koffice. The "layers"-tab is too high, then there's too much vertical space before the "normal" combobox. There needs to be some room between the listwidget and the buttons below. Then, it doesn't really need a statusbar. The information for each layer (thumbnail, layername, the eye, the lock) looks really cluttered at one point, while there is LOTS of space to the right. And it goes on and on.

I realize its development code, so this is just meant as constructive criticism!

The statusbar you see in the screenshot is Krita's statusbar :-). As for the layout, we hope we'll be able to have it tighter once KDE4 settles a bit. As it is now, it's really hard. Sometimes buttons appear (like to the right of the opacity spinbox), for instance.

Just getting a drop-down slider was already really hard! We took the example for that from Photoshop 5.5 for OS X. Coding custom widgets like these takes a lot of time, so I cannot promise we'll be able to have the time to code something like you mention.

What would be really great is if Qt libraries themselves implemented such a widget, don't you think?
And in the end, it maybe worth it for Trolltech if they want to attract Adobe to choose Qt for their Linux port of Photoshop. ;) ;)

woohoo! :)))
well, sorry... ;)
here is an image with 4 screenshots of an effects palette showing how it looks. The last two are perhaps not as frequently used, but I put it here for reference.

The widget is really simple, so simple I would say it's almost the absense of it what makes it so great:
- If I want to change a parameter calles, let's say, Brightness. The program presents it's name and to the right the value, there's no input box, just the underlines value, as if it were an Internet link.
- If I press left mouse button over the value and drag to the left, I decrease the value (pressing Shift while doing this, will change the value by ten units increments).
- If I press left mouse button over the value and drag to the right, I increase the value (pressing Shift while doing this, will change the value by ten units increments).
- If I single press left mouse button over the value and release it, then the value appears surrounded by a white box (with the value selected) to let me input a new value to replace the current one. (At this moment, pressing right mouse button allows the standard Cut, Copy, Paste operations with the value).
- If I single press right mouse button over the value a context menu appears offering to setup the limits the "virtual slider" (let's call it that way) moves between when dragging to change values, and also to reset this parameter to the default value.

Basically that would be all. If you have any doubt I am willing to help.
And thanks for just trying! :)

I forgot to mention...
it doesn't show on the screenshots, but when the mouse pointer is over the value it is shaped almost equal as when you are using an Internet browser (a hand with the index finger pointing upwards) but it also shows tiny left-right pointing arrows to the sides of the index finger, to indicate the direction of possible movement. Once the user starts dragging, the hand disappears and only the tiny arrows remains on the screen.

There can't be any copyright on this. FLTK is using such wifgets a while now. I really like the concept. Agreed, I don't like the way KDE is mostly using MS Windows like widgets. Toolkits like FLTK provide some astonishingly well though widgets, take the file selectors for example - just intuitive and simple.

I'm personally less then impressed by these widgets. They are quite unlike anything I ever saw and I'm pretty sure many will not see it as something they can alter at all without being trained to do so.

And in the end the small buttons are not taking a lot of space at all so the advantages are pretty small to begin with.

These widgets are *very* nicely usable. To be honest, I think opensource lacks a little in the widget-department. For example, there are STILL input fields for INTs from 0 to 100 that have up-and-down-arrows. How useless is that?

It would make sense if one could hold the field and then move the mouose to adjust the value, but who actually taps these two buttons?

The Adobe widget looks like a subclassed QLabel with the mouseMove/mousePress/mouseRelease events overriden. It shouldn't be too hard to override. The difficult part would be to get the context menu working right IMHO.

> And in the end the small buttons are not taking a lot of space at all so the advantages are pretty small to begin with.

It's true that those small up and down buttons do not take up much space, but I think they are entirely useless. Something like a QSlider is much better suited to vary a quantity over a fixed range. It seems to me that this proposed widget is basically a slider without actually showing it. How about temporarily displaying the slider when it's in "drag mode"?

By the way, what is this context menu good for? If I understand you correctly, you can already enter a specific value by simply clicking on the widget,

- The "Edit Values..." option in the context menu mainly allows the user to redefine the span of the slider (its Mínimum and Maximum values). This is sometimes useful in certain cases where the default span is so big that you lose precision while dragging (perhaps changing from 1 to 2 is already a great change in the effect, but as the slider goes from -1000 to + 1000, each time you drag the value changes too much and the slider turns "incontrolable", so lowering the span of the slider increases this precision while dragging and makes it comfortable again).
In theory the span should be preset by the programmer to "useful" values, but often users use effects in situations not foreseen by the programmer, so I guess is in these cases when this option is more appreciated.

- The other useful option in the context menu, is one allowing to "Reset" the value to their default state. Good after you've been experimenting and want to return safe home. :)

p.s. I completely agree on the current state of sliders in Qt/KDE, I never use them, to me they are useless and I end entering values by hand, which is very disrupting, workflow wise.
"Lightwave 3D" and "3ds max" are good examples of programs with good and useful sliders, but to be honest since Adobe introduced this kind of "nano" slider I prefer it over everything else, as they've had a very strong impact in how the (same) applications feel by improving the workflow tremendously.

I really meant the up and down buttons to the right of numeric input boxes, not the sliders.
My confusion came from the fact that in some programs (e.g. Autodesk 3ds Max) this buttons function as sliders when dragging up and down over them, so I tend to see them as sliders too.

I thing that the beauty of this kind of "hidden slider" is that the precision is not restricted to the small screen space where the slider resides.

Let me explain myself:
If you put a visual slider widget on the screen you have to make it "small" (I still haven't seen widgets with a screen wide extension) :)
But this small extension constraints you to put all the possible values the slider could take, from one extreme to the other, so I could end with a 3cm long widget for changing values from -500 to +500, or -2000 to +2000, so this will make the slider behave with a very low precision, mining its usefulness.

With this "hiden slider" paradigm the extension is also "virtual", so in theory it could be made as long as necessary to make the slider progress in a much more soft way, making it more useful.
Besides that, if the user wants to enter a value directly, he still can.

The other thing I would like to refute, is that this kind of solution is not intuitive.
In this Internet era, if there is something users (even novice ones) know, is that if there is a colored underlined word in the middle of the screen, they could click on it to make something happen.
In this case, what needs to be made clear to the user is that they can not only press on it, but to also drag on it from side to side, and I think that this is the main reason for Adobe chosing to show a cursor with an index pointing hand with left and right arrows when over the "hidden slider".

Finally, I teach Adobe and 3D animation programs since more than 5 years ago, and let me say this is one of the features people love at first sight in the new versions of Adobe programs, perhaps followed by the new dockable option palettes (something Krita already has! kudos!)
I really think this is the way to go, not only for Qt/KDE, but in general for interfaces.
But of course it's just my opinion.

Sometimes you have to use another level below (1), (2): Greek letters alpha, beta, gamma. More levels aren't recommended, though. Still, I've seen a variant with the levels below (1), (2) labelled (a) and (aa).
I strongly hope the header variant with mixed numbering works, too. Certain branches of study strongly recommend or require the second variant because it's laid out more clearly (the scheme is always the same - aside from the non standardized forms when it becomes nested too deep - and you know at which level you are without deciphering a long range of numbers).

Additionally, it would be totally cool if KWord could automatically generate a table of contents from these headings (with indentation, page number and space filled in between) like:
A. Header......1
I. Header......2
1. Header...4
B. Header.......4

I think MS Office can do it (by referencing an index; the headers then get recognized after they get assigned to a formatting level -- manually!)
I tried to do the same in OpenOffice but didn't succeed. Don't know if OO can do it or not. Anyways, doing it by hand is quite painful with copying all headers, getting the formatting right and changing page page numbers till the end.

If that would work, academic/scientific essays would almost write themselves ;-)

I've gotten this to work in OOo using styles. Styles can be very powerful if used correctly, and you can use different numbering systems as you indicated. I, too, am hoping for this feature in KWord. It would be nice if, by KDE 4, I could be using all the KDE apps full-time. The progress is amazing. Great work all around.