KDE Commit-Digest for 17th June 2007

In this week's KDE Commit-Digest: Work on engine configurability, data management, a packaging system for Plasmoids and themes, and new refinements in desktop icon interaction in Plasma. The Oxygen window decoration and widget are both moved into kdebase. Further work in the Icon Cache, Kopete Messenger update, KRDC and Context Help Summer of Code projects. Improved highscore handling and network management across kdegames. New keyboard engine becomes live in KTouch, whilst the Step physics simulation package receives support for annotations. Support for many new text styling options in KOffice. Further work towards Amarok 2.0, including work on the context view and the display of lyrics. More recent and precise elevation data added to Marble. KColorScheme colour roles are added to aid usability. User documentation is started for Dolphin. More work in Strigi and NEPOMUK. Work on vector selections and a smoothing algorithm for drawing implemented in Krita. Many improvements in the KMix sound management utility. Digikam begins to be ported to KDE 4. Large scale reorganisation in the kdegraphics module: KColorEdit, KIconEdit, KPovModeller, Kuickshow and Ligature move to extragear/graphics, whilst Kooka and kmrml are removed completely.


Is a replacement planned for Kooka?
Otherwise I'm curious how one should scan under KDE 4.

By Evil Eddie at Mon, 2007/06/18 - 5:00am

all the important bits are in libkscan which is still in kdegraphics. various applications use this already, such as kword and krita. the idea is to scan from the app you will be using the results in.

if someone writes a new app that acts as a shell around libkscan, much as kwrite is around katepart, that could be cool. but we already have scanning available without kooka in both kde3 and 4.

By Aaron J. Seigo at Mon, 2007/06/18 - 5:00am

I agree, an app which wraps around libkscan would be nice. It's nice to have an app just for scanning, when all you want to do is scan images and save them.

By Kyle Williams at Mon, 2007/06/18 - 5:00am

then again, i'm not sure why krita wouldn't fit that bill pretty well?

By Aaron Seigo at Mon, 2007/06/18 - 5:00am

> then again, i'm not sure why krita wouldn't fit that bill pretty well?

For the same reason I don't open want to open Digicam to just copy pictures from my camera to /mnt/data-dump/pictures/ I just want to get the job done, not open a fully fledged painting application. Following your logic, KSnapshot can be removed too in favor of krita, but this doesn't make sense to me either.

IMHO, it's newbie friendly to have a simple wizard with (1) scan preview > (2) select bounds, rotate > (3) scan > (4) save as, send by e-mail or post to flickr. Windows XP has a nice type of application for this, and it seams to be used a lot because it's simple.

By Diederik van de... at Mon, 2007/06/18 - 5:00am

for everyone commenting about how badly this is needed, please read the whole thread.

note that i first say that a little scanner shell would be cool. then i say that we have something good enough for now. put the two together and you get:

it would be nice to have a little scanner shell, but we are ok for now even if we don't.

By Aaron J. Seigo at Mon, 2007/06/18 - 5:00am

All your required functionalities (and much more) are already
available as kipi-plugins (and therefore in gwenview
showimg, kphotoalbum, digikam and ksquirrelmail)

As gwenview will be part of KDE4 maybe an new option

gwenview --plugins scan

that start the plugin on gwenview startup ,wrapped in
a scan-images.desktop is all you want ;)


By Achim Bohnet at Tue, 2007/06/19 - 5:00am

~> gwenview
QGDict::hashAsciiKey: Invalid null key
KCrash: Application 'gwenview' crashing...

~> gwenview
libkscan: WARNING: Trying to copy a not healthy option (no name nor desc)
libkscan: WARNING: Trying to copy a not healthy option (no name nor desc)
KCrash: Application 'gwenview' crashing...

Still needs some work i guess :o)

If it is reproducable, i'll post a bug report about it

By whatever noticed at Tue, 2007/06/19 - 5:00am

For all who are not aware of it:
I recently added support for scanning into kolourpaint (in KDE3 and KDE4 of it)
kolourpaint is a nice, compact application which every normal user should be able to deal with.

By Martin Koller at Fri, 2007/06/22 - 5:00am

It is a nice app, but it isn't a scanning app. It's a doodling app, and not the first place someone will look for to scan something, and it contains a lot of functionality unneeded by someone who wants to scan something.

Don't get me wrong, I think it's nice that kolourpaint can scan, but it's hardly a replacement for a simple scanning app. For all the talk of making things easier and simpler for newbies, lumping functionality many people consider unrelated into now larger and more complex apps is precisely what one doesn't want to do.

By jason at Fri, 2007/06/29 - 5:00am

Well maybe you don't want to open a large and powerful graphics application just to scan a picture. I would rather open up digiKam, since it has the basic functions you're likely to do on the image before you save it, i.e. rotate, crop, fix colours, but not do complex painting.

On the topic of scanning, any word on a KDE4 frontend for performing OCR? I hear tesseract-OCR is a fantastic library.

By Schalken at Mon, 2007/06/18 - 5:00am

Wonderful. In the same way Windows users open up Photoshop to scan things. That's the first place I'd look.

Luckily everyone has koffice (with krita) installed instead of OOo and Gimp.

By jason at Mon, 2007/06/18 - 5:00am

That's *****!
Almost nobody uses Koffice cause it's barely compatible with ODF and not
compatible at all with MS files (and most of us need to communicate even with
non-linux users). Krita sadly isn't still 50% as useful as gimp.
So most (90%?) people uses OOo and gimp, and will continue to.
These apps are not really mature, and you know. Givin
scanning functionality only to Koffice users will not force users to use
koffice, most of them will just move to other scanning solution,
or will to others DE if they badly need integration.

By matte at Thu, 2007/06/21 - 5:00am

>>So most (90%?) people uses OOo and gimp, and will continue to.

You can also scan images with OOo and Gimp.

By whatever noticed at Sat, 2007/06/23 - 5:00am

I'd heard there were still a few people around who had no concept of sarcasm. What a wonderful sighting this has been.. like visiting primitive tribes in the rainforest. Thank you for this.

By jason at Fri, 2007/06/29 - 5:00am

Text messages are not an ideal medium for transporting sarcasm and/or irony.

There are two reasons why sarcasm messages can fail: the reader and the writer...

By MK at Fri, 2007/06/29 - 5:00am

>then again, i'm not sure why krita wouldn't fit that bill pretty well?

Krita isn't a scanning application, and it is not part of KDE itself.
Novice users that just want to scan a document will be looking for a scanning application, not for an image editor to do the job.

A simplified digikam could do the job, as it has the necessary abilities to order scanned images and editing features to scale, crop and rotate images and to change the file format.

By whatever noticed at Mon, 2007/06/18 - 5:00am

I'd be very keen to see good scanning functionality built into digikam anyway - not all my photos are taken using a digital camera and it would be nice to be able to scan slides / negs / prints and bring them straight into my digikam workflow.

By Adrian Baugh at Mon, 2007/06/18 - 5:00am

install kipi-plugins and you'll find in digikam:

Album -> import -> scan images

By Achim Bohnet at Tue, 2007/06/19 - 5:00am

I agree with the others on this one - having a separate scanning application is immensely preferable. Kooka has served KDE very well for a number of years, and I have found it particarly useful. Inserting scanning into an application such as Krita makes a simple task rather complicated for a number of users. This seems especially to go against the grain of the Unix philosophy of providing simple utilities, and also decisions such as to separate off file management into Dolphin. Please retain Kooka!

By David Joyce at Mon, 2007/06/18 - 5:00am

> Please retain Kooka!

I'd go for a alternative with much more friendly UI... (the wizard I described somewhere above). for the remaining, you've complemented the other arguments nicely.. :-)

By Diederik van de... at Mon, 2007/06/18 - 5:00am

Actually, I don't use Krita to scan images myself. I haven't even tried it -- not even now that I have a scanner again. I actually had forgotten that Krita was supposed to be capable of directly scanning images in. And I'm the maintainer... But I tried Kooka and went to using XSane myself, because it does 16 bits. I'm not sure whether libkscan supports 16 (or rather 12) bits per channel at all.

But it should be easy enough to write a standalone scan application using libkscan -- you can probably do it yourself, in Python or Ruby or C++.

There's just one thing I'm certain of: nobody actually working on KDE4 has time to start or restart a dedicated scanning application. Kooka has been seriously unmaintained for ages. So -- if you want a scanning application, if you think it's important that there is a scanning application, then you need to act. Stop pleading. Stop hoping. Follow the instructions on techbase and start a development environment. Start developing. Become a widely-admired hero!

By Boudewijn at Mon, 2007/06/18 - 5:00am

> I'm not sure whether libkscan supports

... i'd be surprised if it doesn't as it uses sane, so should follow what xsane can do.

> nobody actually working on KDE4 has time to start or restart

which is exactly what i was thinking when suggesting krita is good enough for now. due to having ways to scan there's no big impending doom cloud hanging above if there isn't a little scanner shell in 4.0.

> Kooka has been seriously unmaintained for ages.

it would need a pretty big rethink/rewrite in any case as the UI really needs to be completely rethought. given that most of the logic (except the ocr stuff) is in libkscan, it makes the choice even more obvious.

> Start developing. Become a widely-admired hero!


By Aaron J. Seigo at Mon, 2007/06/18 - 5:00am

it would need a pretty big rethink/rewrite in any case as the UI really needs to be completely rethought.

I'll second that :)

By forrest at Mon, 2007/06/18 - 5:00am

I'll second that :)

Could you please elaborate? What do you not like about the current user interface, and what ideas do you have to make it better? It would be great if we could collect some ideas here, so that the soon-to-be-widely-admired hero knows what to do...

By ac at Tue, 2007/06/19 - 5:00am

my main problem with the current interface is that you can close the views in the main screen, but cant get them back in the same fashion.
Most novice users i work with come to me with an empty kooka screen and the only way to restore it to its default layout is by removing ~/.kde/share/config/kookarc.

By whatever noticed at Tue, 2007/06/19 - 5:00am

more than anything else, keep it simple. it doesn't need docks, it doesn't need galleries, it doesn't need a separate image viewer space ... simplicity. if the user wants all of those things, they can use gweview or krita. preview, crop/select, rotate and save: that's all that's needed.

second, do it fast. there were a number of things kooka tried to automate or handle "smartly" that made the app a bit slow.

third, don't try and manage the image results automagically. kooka tried quite bravely to keep automated galleries around. imho the scanner app should treat the scans as documents (think kate, kwrite, kword, etc) and not try and auomatically mange them.

that's just mho though, and to be fair i've used kooka for years and have got a lot of utility out of it. so it's a good app. but we can probably do even better by learning from it.

By Aaron Seigo at Tue, 2007/06/19 - 5:00am

OK, I'll happily admit this is better than whining about kooka disappearing. If a better scanning app comes out of this it's a win.

By jason at Fri, 2007/06/29 - 5:00am

We've been over this ground a few times now, haven't we??? :-)

>> I'm not sure whether libkscan supports

>... i'd be surprised if it doesn't as it uses sane, so should follow what
> xsane can do.

Having trawled through libkscan in the past, I can say there's a lot of stubs in there where the author intended to support all the features in SANE, but didn't in the end. It's also very messy. I'm of the opinion that libkscan needs a full re-write for the post-Solid & Windows/Mac world that finally does support all my scanners features :-) I have some code that speaks to my scanner OK, but I'm a bit like the artilleryman in War of the Worlds...

Everything else is a +1 from me. Kooka tries to do too much, we already have great image management apps. Instead its widely agreed that a beefed up libkscan in kdegraphics and a couple of new smaller apps outside libs is the way to go.


By odysseus at Tue, 2007/06/19 - 5:00am

Aaron & Boudewijn,

Start developing - perhaps this is an invite I can't resist. With the amount of spare time I have, it will have be a _slow_ process!

I'll try and get in touch with you to see what I can do. The UI suggestions posted seem very sensible - I've always thought the gallery pane, and that sort of stuff, added undue complexity to the whole scanning process.

- David

ps. best leave the hero bit out, I think... :-)

By David Joyce at Tue, 2007/06/19 - 5:00am

Sure. Feel free to contact me, either by email or on #koffice.

By Boudewijn Rempt at Wed, 2007/06/20 - 5:00am

I hope that KDE will at least create a cache API and make it possible to slip in caches via a quick configure. In particular, I see the icon cache and of course there is the html cache. It would be nice to skip all that, and have something like squid serve the needs. Yes, I know that icon cache is meant for local caching, but it seems that a small generic cache that interacts with squid (or other network cache) would be great for schools, departmental servers, businesses, etc. KDE can use more networking.

By a.c. at Mon, 2007/06/18 - 5:00am

the point of the icon cache is to speed things up. throwing them on a machine somewhere on the network seems ... counter productive.

squid helps with web browsing because it caches remote content on a system that is closer to the destination (you). integrating the icon cache with something like squid would be doing exactly the opposite, and therefore have exactly the opposite effect (e.g. slow things down).

additionally, the sort of on-disk strategies used by web cache apps are not necessarily the greatest for other work loads such as icons due to differences in access patterns. so even if squid was running locally it probably wouldn't be the best idea.

direct access to a shared local file that is tuned for icon access patterns is going to be hard to beat. and i'm really not sure what benefits a network cache would have.

i can see sharing cache files on a system serving x clients over the network (e.g. thin client setups) could be nice for disk space and disk cache friendliness ... but that's also local (to the app) and not on the network.

By Aaron Seigo at Mon, 2007/06/18 - 5:00am

Finally dolphin has rounded selected item.
I thought this features was abounded.

By terran at Mon, 2007/06/18 - 5:00am

Danny, thanks for again delevering on my monday morning habit of reading the commit-digest. Would it be possible to somehow get statistics on de progress of the porting effort to KDE4? It would give a good feeling where we are right now.

By cossidhon at Mon, 2007/06/18 - 5:00am

well, porting is done, as is improving the libraries (mostly). They're working on features now.

By superstoned at Mon, 2007/06/18 - 5:00am

Well, it would be pretty hard to get definitive statistics on the porting effort, as it is not something that is easily quantified - really, many files may be in different stages of porting, etc. And it is not as if there is some register of ported files :)

I really wouldn't know where to start in getting such a statistic. However, you might be able to form an impression through the Krazy code quality checker at http://www.englishbreakfastnetwork.org/krazy/ (where a reduction in issues over time would somewhat indicate progress in porting).


By Danny Allen at Mon, 2007/06/18 - 5:00am


will those special icon actions also be available from dolphin and konqueror ? or only on the desktop ?

By anon at Mon, 2007/06/18 - 5:00am

let's hope they won't be plasma-specific ;-)

By superstoned at Mon, 2007/06/18 - 5:00am

The quick icon actions yes I do think should be available in Dolphin under icon view.

However, other parts of Plasma such as icons having the nice rounded border and the ability to move icons around should probably remain Plasma's expertise.

It is useful to distinct the use of icons on the desktop (fewer large icons, move them around) from icons in the file manager (large number of icons, must reduce clutter).

By Schalken at Mon, 2007/06/18 - 5:00am

I disagree. I think that an icon should behave exactly the same everywhere - anything else is confusing to users as they have to figure out where the different behaviours apply and why, when they drag an icon from a dolphin window onto the desktop, it begins to behave completely differently.

By Adrian Baugh at Mon, 2007/06/18 - 5:00am

which is why icons on toolbars behave exactly like icons in sidebars, the file dialog and the file manager? ;)

icons are context sensitive. i agree that things should generally work similarly, i also think (and have done various bits of user testing and observation to base this on) that the "desktop is just a file manager view" concept is completely and utterly broken.

one of my stated goals is to break this errant connection by 4.1 so we can get on with using the desktop and panels as something that is actually useful in the general case.

By Aaron J. Seigo at Mon, 2007/06/18 - 5:00am

I like the new layout of KOrganizer a lot :-) (http://commit-digest.org/issues/2007-06-17/files/korganizer_themed_decor...) The "details of selected event" makes it much friendlier to use too.

Not sure about the background stuff, but well I don't expect it will be mandatory to use a background. :-p

By Diederik van de... at Mon, 2007/06/18 - 5:00am

Well, the layout in http://commit-digest.org/issues/2007-06-17/files/korganizer_themed_decor... is more of a mockup. But the "details of selected event" part is available in KOrganizer 3.5 (in fact, it's a quick cut-and-paste).
The only difference that may appear in KOrganizer 4 is that the position of the panel may become configurable (left or right), and the to-do view is being changed a little. Here's a screenshot of today's KOrganizer (still a work-in-progress):

By Loïc Corbasson at Mon, 2007/06/18 - 5:00am

What are these not-useful pictures at the bottom of each day?
Are they the "new" features?

Korganizer is a pain in usability temrs, and the solution isn't adding "cool" pictures for each day.

Please, use Google Calendar for a while and understand how simply to use it can be. For example:

- Google Calendar: After selecting a time range INMEDIATELY does appear a ball to create the new task/event.
- Korganizer: After selecting a time range you must press right buttom for context menu to appear.

Hope Korganizer will be improved in real terms.

By Iñaki Baz at Mon, 2007/06/18 - 5:00am


I'm the creator of the not-useful feature you just saw :)

I'm a student working this summer (Summer of Code) to add some theming support to KOrganizer, to make it more appealing to users that think computer-based calendars are too "unhuman" and boring, so mainly home users still using paper-based calendars instead of KOrganizer and also companies which may want to customize the calendar layouts for the employees/customers/...

The "cool" pictures are Wikipedia's Pictures of the Day, and while this may seem unuseful, this is commonly found on paper calendars which are very successful, so maybe it's not that unuseful after all?

(You sure have noticed that the goal is not to improve usability with this feature, but attracting new use(r)s.)

Now, concerning the GUI in general, I won't say KOrganizer's GUI is perfect, and I think that your example is good at showing this, but please notice two things:
- my Summer of Code project is about KOrganizer theming, so I won't be able to revolutionize the GUI in terms of buttons/actions/etc.; I'll work on themes and decorations to allow customization of the calendar views;
- we lack developers for KDE-PIM (KOrganizer being one of the components of the PIM suite) so of course you would be very welcome to join us make it better: just email kde-pim@kde.org if you'd like to (this would be greatly appreciated!). Changing the GUI requires time = people = new developers, and you'd be very welcome to help us on this!

Now, on the usability front, I personally do not think KOrganizer is a pain, and I think it is comparable to most (ok, not all) other calendar apps out there, free or not. This of course does not mean it could not be improved, and I for sure understand that some apps' functions are easier to use. If you want to help, please feel free to do a usability study or code new ideas, this again would be very appreciated.

Anyway, thanks for the feedback :)
Feel free to contact me / post on my blog (http://blog.loic.corbasson.fr/) if you'd like to add something on the theming possibilities themselves -- thanks in advance!


By Loïc Corbasson at Mon, 2007/06/18 - 5:00am

Ok, I understand the goal of your project.
Just let me explain that when I saw these images I though there were more important things to fix about Korganizer, most of them about usability, and because I expected to see a new and cool designed Korganizer I just saw the same as now but with some pictures.

Just it, I've nothing against you project, it could be cool, but I hope more improvements for a better calendar app.

Anyway I'll try to compare various calendar program to test Korganizer "bugs".


By Iñaki Baz at Tue, 2007/06/19 - 5:00am

> I've nothing against you project
No problem, I didn't take it personally :)

> Anyway I'll try to compare various calendar program to test Korganizer "bugs".
Thanks for having a look at this -- if you need some info or anything else, feel free to post to kde-pim@kde.org. This is appreciated!

Best regards,


By Loïc Corbasson at Wed, 2007/06/20 - 5:00am


Above those Image-of-the-day pics there are two numbers.

They are supposed to be the number of days in the year before THIS day and after THIS day?

Well the sum is allways 362 + THIS day would be 363, but the year 2007 has 365 days as most years.

The first number includes THIS day (31+28+31+16=106 for Apr.16), while the second number is 3 days less then the remaining days of the year.

Just wanted to mention it, in case you didn't already realize.

By Harald Henkel at Tue, 2007/06/19 - 5:00am


Thanks for the feedback! In fact, the images in the digest are mockups. I didn't notice when I created them that the numbers I added manually did not fit. But in the real KOrganizer, they do :)



By Loïc Corbasson at Wed, 2007/06/20 - 5:00am