ODP support for Okular

As you probably read on the Dot yesterday Okular doesn’t support much of ODF. I remembered that Jos had created the Slidecompare tool, so I got the idea to combine it with an Okular generator. It turned out that it’s pretty easy to combine the ends from both worlds. Okular offers a very nice API to write generators, which is almost an exact match to the KOffice one.

The generator currently supports only formats supported by KPresenter: ODP, PPT and PPTX. Currently only rendering is supported (so no search).

The generator is now in KOffice trunk. Even though it’s just 107 lines of code, it can make use of all the work that went into the KOffice import filters. I love integration!

KOffice font rendering again

A few months ago I blogged about font rendering in KOffice. The problem has been discussed and analysed a lot on the last KOffice meeting and the KOffice forum. The conclusion was that the problem can’t be fixed inside KOffice, but needs to be fixed in Qt. Since the problem is far from trivial and we don’t have developers with experience in that specific area, we rely on Nokia to fix the problem. Problem has been reported in two bugs here and here. Unfortunately the bugs have very low priority at the moment, so we need to make clear to Nokia how much these fixes are needed.

Everybody who is bothered about these rendering problems please vote on the two bugs I pointed out above.

In case these bugs don’t get fixedm a possible plan B would be to switch the rendering to use Cairo + Pango. Till then you can try to work around the problem as I have pointed out in my old blog post.

Have you seen this widget?

For some time we have been searching for this widget for Krita. It’s basically a button group with adjacent buttons (see the mockup that Jaroslaw made).

It’s a very common UI element e.g. in Plasma or Blender, but it seems that  no KDE application uses it. So has anyone seen this widget used in KDE (outside Plasma) or implemented it?

I’m asking because if doesn’t exist yet (which is very unlikely in my opinion) we would have to implement it ourself and I would prefer not to duplicate existing work.

We need more bug reports

The Krita 2.3 is now in development for some time and we try to make it as fast and stable as possible. For that we need more tester.

Krita has often been criticized for being too unstable, like c’t (german computer magazine) who wrote about Krita being “absturzfreudig” (likes to crash). So it shouldn’t be any problem to get lots of bug reports. Right? In practice we don’t really get a lot of bug reports. Which leads to a recurring pattern: Every time we prepare a new release, we fix almost all reported crashes in Bugzilla (Crashes and data loss are considered release blockers) and still miss crashes that haven’t been found. So Krita definitely doesn’t get as much testing as would be needed.

As I mentioned most of the testing is done by Krita developers and a few enthusiastic artists. Even though this group finds most of the bugs and fixes them, we can’t do the testing alone. There are several reasons why we need lots of other testers. Krita is a quite complex application and even though we have less features than comparable applications nobody can test all of them. Additionally Krita runs on a large range of platforms, libraries and hardware. The developers run only a very small subset of these.

Another problem with developers testing an application is that they know a lot about how the application is “supposed to work”. So the way the developers use the application is different than somebody who is new to Krita and don’t seem some of the problem that new users have (I’m wondering if that effect has a name). So we need tester who have less experience with Krita.

One might argue that we should to test it longer and do more beta releases. The problem with that is that not many people test beta releases. Most bugs are reported several weeks or months after the final release. Of course the fact that we currently don’t have that many users plays into it. There is a bit of a contradiction: To get many testing users we need advertise Krita more, but before we can advertise it we need more testing.

To summarize we need more testers, testers that are not developers and have them test Krita earlier.

One thing I notice regularly is that many users have problems, but don’t report them. There might be be several reasons for that like Bugzilla being to slow and requiring to register or they assume that the developers already know about the problem. We are trying to improve on that e.g. with the Krita forum where several users gave us feedback about their usage of Krita, which is very much appreciated and already gave valuable input. In 2.3 for example we redesigned the the eraser after some user reported problems with it.

I hope I have motivated you to test Krita, give feedback and help us to improve it.

KOffice Mid 2010 meeting

Last weekend the KOffice Mid 2010 meeting took place at the Linuxhotel in Essen. As usual the meeting was pretty amazing. The Linuxhotel is a really great place for sprint: Many places to dicuss and hack (like the big lawn in front of the building), free drinks and good connectivity. All the food very food nearby, so we gained more time for being productive. Additionally it’s easy to reach from Dortmund which is also nice.

The main meeting on Saturday was divided into a big part where we discussed the general direction of the project and another part where we discussed specific technical problems. We spend quite a lot of time analysing the successes and failures of project. Boudewijn described lots of the things in the new Last week in KOffice, which is the new weekly development update similar to Last week in Krita.

Compared to previous meetings we are more filling remaining gaps than designing new things like flake. Even though there is still a lot todo, the progress of the last couple of months is very impressive. Mobile device are getting more and more important for KOffice especially for KWord, KPresenter and KSpread. It really shows that the whole work that went into redesign for KOffice 2 pays off.

In terms of technical discussion is good that the text-on-shape feature is now work in progress, which will allow text inside shapes needed mostly for KPresenter and Kivio. Another topic that I put on the agenda was the bad font rendering that KOffice suffers from. Jaroslaw and Sebastian have been digging through KOffice and Qt code to find a way to fix it. So far it looks like we will need to discuss is further with the developer from Qt Software to solve it.

Last but not least many thanks to everyone who help to make the sprint happen especially Alexandra and Inge for organizing it. And of course KDE e.V. and Nokia.

Krita Hackfest 2010

Last saturday I came back from the Krita Hackfest 2010, after being eight days in Deventer. It was a really long, intense and amazing sprint.

The sprint started on friday when almost the whole Krita team came together. It was nice to see everyone again and also meet with Vera, Adam and Peter who I haven’t met before. We also got some lovely Krita t-shirts.

Creating a vision

The biggest part of Saturday was the vision session. Even though Krita existed for quite a long time it never really had a vision. Over time and with different developer teams the overall direction of Krita changed from being a GIMP replacement into a more painting oriented application. As a result we now have a vision (Peter, Boudewijn and Cyrille blogged about it) which focusses Krita on being a sketching and painting application.

It was quite surprising how many comments the blog posts triggered. They covered the whole range from “Pure awesomeness” to “very disappointed”. I think it shows that on hand the Krita is going into the right direction, but there is also some interest in a Krita based photo manipulation application. Fortunately almost everything in Krita is a plugin, so photo oriented features can continue as plugins even when they are not part of the main Krita package. Depending on developer interest there might even be another application based on Krita technology in the future. Once the switch to git is done it should also be easier to maintain these things.

Development

As Boudewijn already wrote in this weeks Last week in Krita we spend the rest of the week on improving stability and performance. We also implemented several usability improvements that we discussed during the weekend.

I spend Sunday evening and Monday morning on replacing the old algorithm for brush outline. Now the brush outline works correctly even when zoomed and is a bit faster when moving the cursor. The code is now shared with the selection visualization too.

After that I continued with the paintop cleanup. Creating a new paintop in Krita is now very easy. A simple paintop needs only two classes (settings widget and the paintop itself) and Lukáš demonstrated that you can write a new paintop in few of minutes. Besides the cleanup I continued the work on the paintop presets, which can now show images that are cut out from the new scratchpad that Boudewijn created. The screenshot below shows the preset chooser with the scratchpad. Cyrille also did some nice work to reduce the size of the presets, so that they are mostly just a few kilobyte big even with the preview image.

Another cool things that we got out of the discussion on the weekend was the design for a new slider to replace KDoubleNumInput with a tablet friendly widget. After Boudewijn blogged about it Justin Noel created a very nice widget for us. After doing some small adjustments like double and exponential support the slider is now being integrated into Krita.

Visiting the Durian team

On thursday we visited the Durian team in Amsterdam. This was one of my highlights in this sprint. Ton Roosendaal showed us the Blender Institute, which was much bigger than I had expected. We attended one of the weekly meetings where every artist and developer show the work in the last week. In about two hours we saw some really amazing stuff like the the face of main character Sintel and some early dragon scences. I’m sure that the final movie will be fantastic. After that we went to a nice Thai restaurant nearby, where we had lots of inspiring discussions.

If you are interested in digital painting another DVD might be interesting: David Revoy, who does the concept art for Durian, creates a training course that can be pre-ordered from the Blender shop (Preview here).

Thanks!

The sprint was so much fun and such a nice time. My biggest thanks go to Boudewijn, Irina and their family for the amazing work they put into this sprint. Many thanks also to the Durian team for the opportunity to have a look at their work. Good luck with the rest of your project! And of course to KDE e.V and the community which made this sprint possible.

Kivio IRC meeting this saturday

Jos wants Kivio. Do you want an easy to use diagramming and flowcharting application with tight integration into other KOffice applications too? Then this is your chance. This saturday 13th February, 9 am UTC there will be a meeting in #koffice on irc.freenode.org with everyone who wants to help to get the first version of Kivio for KOffice 2 finished. It doesn’t matter if you haven’t done KOffice development before, just come around and see what you can do.

KOffice Sprint

Last weekend I have been attending the KOffice Sprint is Oslo. Like every other KOffice sprint it was really cool and we had lots of fun. It was the first time I visited Norway and I really liked it. Unfortunately these sprints are always so busy that you don’t really see much outside the office. I arrived friday night at the airport, where I met Jos and Jos. During the travel to the city I could try the new N900, which is really a cool device.

On saturday we had lots of interesting discussions about the lots of stuff. In contrast to the previous meetings many different things that are not directly technical issues in KOffice have been dicussed like the impending move to Git, release schedules, decision-making and the involvement of Nokia. Nokias testers did a huge amount of testing and I’m really looking forward to the development that will be done for KOffice 2.2. I got a N810 from Nokia and we had a lottery with five N900 as six month loan after dinner.

Back at the hotel we had a Krita meeting, where we discussed the plans for Krita 2.2. For 2.2 we are mainly focusing on stability and performance with the midterm goal to get Krita ready for the next Blender open movie. To reach this goal we are running a fundraiser to get Lukáš Tvrdý, famous brush wizard of Krita, working full time on Krita for three months to improve performance, stability and usability. See more information is available on the Krita website.

On sunday morning we had a discussion about getting KOffice end user ready. There is much to do to and even though it’s remarkable what this small group of developers achieves we still need more developers. So in case you want to help making KOffice ready don’t hesitate to drop by on IRC or the mailing list and we will get something for you.

Big thanks go to Nokia, KDE e.V. and the organizers of this great sprint for providing the location, devices, food, accommodation and everything else that made this sprint such a great experience.

KWord font rendering

For quite some time I have been wondering what’s wrong with font rendering in KWord. I have seen KWord on other systems where the fonts rendering looked nice and sharp, but I couldn’t get the same look at my own system. The screenshot below shows how that looked.

The topic was discussed in the KDE forum and then in the KOffice IRC channel, where I finally got the right hint. The clue is changing the hinting style in the KDE systemsettings. This requires a some experimentation to find out which mode works best.

For me the change from full hinting to no hinting brought a great improvement as you can see below. The font in menu and toolbar changes a bit too, but that doesn’t bother me that much.

Maybe it’s possible to get even better rendering by flipping some secret switches, but so far I’m quite happy with the result.

The state of Kivio

As you might know Kivio, the KOffice diagramming and flowcharting application, hasn’t been released with KOffice 2.0. Since the release a lot of people asked on IRC how long it will take until Kivio will be released and what’s still missing for the release.

So what do we have so far? The current Kivio version in trunk consists of 223 lines of code. On the screenshot below you can see how it looks at the moment (with my own docker placement):

Of course the small code size doesn’t mean that it doesn’t have any features. Due to the high integration between the apps and the KOffice libs most of the features of KPresenter/Karbon are already available. For example load/save, inserting and arranging shapes, managing pages etc are done. Shapes can be rotated which was really missing in 1.6. Thanks to flake all shapes can now be interchanged seamlessy between Kivio and the other KOffice apps. At the moment there is also ongoing work to improve the connection tool.

What’s missing in Kivio? Most of the work to make Kivio usefull has been done KOffice libs. What Kivio needs now are developers to fill the missing gaps. The most important missing features at the moment are stencils sets as we had them in 1.6 and support for text on shapes. Unfortunately we are all already busy with developing the other KOffice apps and day jobs, so nobody is working on this at the moment.