Printing in KOrganizer is really in need of some attention. Especially now that we are providing RichText capabilities in calendar descriptions and elsewhere. You can even write journal entries entirely in RichText. But the printing system doesn't know anything about RichText.

There are dozens of outstanding bugs related to printing in KOrganizer.

The job involves knowledge of low-level drawing primitives (move-draw, set pens and brushes.. stuff like that).

I was surprised to get so much feedback about the KOrganizer agenda items after I posted the screenshots in my last blog entries. There seem to be some strong opinions about rounded corners. Michael Lentner did the right thing and sent a patch. I applied it and suddenly the agenda items look much more slick.

[image:3066 width="640" height="452" hspace=100]

There is even more space around the items, which seemed to be one of the things which disturbed some people, so I don't know how this change will be accepted. How do you like it?

It also doesn't seem to respect the resource colors anymore, but I'm not sure if that wasn't broken before already. The selection also has a slight problem as it isn't visible when there is no header displayed, but I guess that's fixable.

Hi, I'm a Google Summer Of Code student and I'm working on creating a kresource to add support to add a journal and retrieve them from a blog.

You can monitor my progress on the kresourrce in trunk/KDE/kdepim/kresources/blog/.

The next stage of my project is revamping the journal support in Kontact/Korganizer. This will not be completed by the end of the summer but I plan to keep working on it regardless.

If you have an ideas or input on either of these parts of my project then send me an email at mike@mikearthur.co.uk or talk to me on #kontact.

As I wrote in my last blog, KOrganizer now has the ability to export the calendar to all different kinds of formats using technology called XSLT transformations. The only thing that I'm missing (because I'm entirely bad at those things) are good designs that I can implement. So I'm looking for nice and visually appealing designs of how calendar exports might look. Possible export formats are e.g.

• SVG graphics
• HTML (to-do list, calendar, journal, showing just one event)
• PDF output

Just be creative! In principle, one can create anything from the calendar data, from A0 wall poster calendars to A8 pocket sheets, from SVG graphics showing the calendar with a nice holiday picture in the background to professional-looking calendar books.
Of course, with SVG and HTML it would be much easier for me to implement if your design is already in SVG or HTML.

BTW, if anyone wants to try it out, the KOrganizer plugin is currently in the kdepim-3.5.5+ branch for new features to 3.5 (branches/work/kdepim-3.5.5+/korganizer/plugins/xslt/ in SVN). To work with the 3.5 branch, just copy that directory over and it should work. You'll have to enable the plugins in korganizer's config dialog before you can see them in the "File -> Export" menu, though. There are some proof-of-concept style sheets available already (for HTML, SVG, CSV, etc.), but they are mostly dummy styles and do not really produce any useful output (and if they do, the output is plain ugly, so I won't give an example here).

As I wrote in my last blog, my to-do list for KOrganizer keeps growing and growing (sure, I implement / fix lots of stuff, but it seems that its still a long way to make KOrganizer perfect). So, I thought, I bet there are a bunch of interested guys and gals out there who were always interested in kdepim development, but never really dared to take on some open issue.

So here is a short list of some Junior Jobs (JJs), which I think are not too hard to implement, and which would serve as nice small projects to get familiar with our code:

• Add an "File->Import->Import Calendar Resource" item (see http://www.userbrain.de/kdepim/korganizer_menu.html, Suggestion 4 for the File Menu). This would basically do the same like the add in the resource view or in the kcontrol resource configuration..
• Write a "How to upload Hot New Stuff" (also see the above menu proposal by our usability expert Ellen)
• Add a menu item / toolbar button to let the user select a date to jump to. (see again the above proposal)
• Add a menu to quickly toggle the alarm for the selected item. In the agenda view's RMB (right mouse button) menu this functionality is already available, it's just not currently available to all other views.
• The default reminder time currently has only 5 possible values (in the config dialog). Extend this to use any hh:mm value (using the same time widget as the default length) and use this offset in the editor dialog.
• If you are working on a manually opened calendar file, and you import a file, the option to import it as resource should not be shown (since there is no resource calendar available).
• etc, etc.

If you need any help or you want to work on any of these, or you have other ideas or questions, just join us either on IRC in the channel #kontact (on the server irc.kde.org), or at the mailing list kde-pim@kde.org...

There are also several open bug reports / wish list items at http://bugs.kde.org, so if you see something that fits you, just tell us. We'll definitely help anyone get familiar with our kdepim code!
And we can use anyone who want to help us make kde-pim even better!

Actually, today I wanted to do some serious bug fixing and reduce the number of items on my to-do list, but then I didn't get beyond one of them: Multiple reminders in KOrganizer.
Actually, like so many other features, multiple reminders were already supported by libkcal as well as by korgac (the reminder daemon), it was just the GUI component that was missing. I added that today, so it's now possible to have :

• reminders before / after the start / end date of an event
• multiple reminders per event
• repeating reminders

Seems like korganizer in kde 3.5 will also have some new stuff to show off...

Actually, this feature implements our second-most requested wish for korganizer... And it fixes some problems identified by our usability guys / gals. (BTW, they are doing a tremendous job! Just look at http://openusability.org/projects/kdepim/ and http://www.userbrain.de/kdepim/. The only problem is that this keeps my to-do list of open issues growing immensely )