KAlbumPhoto

[Patrick Julien]

This discussion seems to be more on kde-devel than kimageshop, so I might not 
have the entire picture here, but here goes anyway

> Ok, so we have kuickshow, gwenview, we have kalbum and kphotoalbum, there
> is imgseek and kmrml. And there are krita, karbon and kontour (although
> slightly in a different league). Maybe we can define the purposes of all
> those apps to compile a feature list and share some code.
>
> Even better to integrate them functionality wise (I guess merging is
> unreasonable). At least they should all use the same image collections.

I can't speak for the non koffice components since I know nothing about them, 
but it seems that these non-koffice components are viewvers for the most part 
and are pixel based while karbon and kontour are vector based editors.  Not 
much to share here, besides what they're already sharing right now (kdelibs, 
qt, etc).

Now this only leaves Krita to share code with.  I'm not sure this is very 
wise.  Krita's, unlike Krayon before it, in-core image format is now tile 
based.  This means that displaying an image isn't just loading a QImage into 
a drawable.  Krita needs to do this so that things like Undo/Redo and loading 
incredibly huge images are possible.

Yes, Krita should be able to display all kinds of images you can see with 
these other programs and more. However, it's using a lot of very small chunks 
of memory instead of one large one to display it.  This also means it's using 
much more memory than a viewer would.