[RFC] Possible KView Maintainership
James Richard Tyrer
tyrerj at acm.org
Mon Oct 24 18:16:49 BST 2005
Matthias Kretz wrote:
> On Sunday 23 October 2005 00:14, James Richard Tyrer wrote:
>>The current maintainer said that he could no longer maintain it.
> That'd be me. And that statement is right.
Hi, Matthias. I like your app and was disappointed to hear that it
would probably be dropped.
>>>If I remember well, the main one was there are a few similar applications
>>>- khtmlimage (kdelibs)
>>IIUC, all khtmlimage will do is display an image as is at 100% in Konqueror
> Right, khtmlimage is the most basic KPart based image viewer that normally
> does not have enough features. Scaling is a must have for a viewer. On the
> other hand it does incremental loading which is pretty much impossible with
> the QImage/KImageIO based approach KView uses.
As I have said elsewhere, incremental loading has points both positive
>>>(And there is also Gwenview, an extragear application.)
>>The Gwenview maintainer is working on it with the intention of having it
>>included in KDE. It has more features than KView.
> I think there still is a place for KView in the KDE4 world. And having
> Gwenview (and Showimg, and whatnot), the KView maintainer finally has the
> possibility to make KView a real viewer.
> Actually my dream for KView was to create a lightweight viewer using KDE
> Component technologies that can be reused throughout KDE. Just look at the
> interfaces I defined (which I never moved outside of KView :-(). They provide
> a generic interface for an image canvas, and an Image-KPart.
> This is really usefull stuff, but I never let it take off :-(
Perhaps (ultimately) merging the KView and KViewShell projects would
provide this uniform interface -- which would be good from a usability
>>>> Remove some features to make it less complicated -- target it as
>>>> JUST the general purpose image viewer (users that want more
>>>> features now have other choices).
> Yes, it's probably best to remove all image editing functionality. On the
> other hand I wrote it in a way that KView only provides the hooks for editing
> while the functionality all goes into KPart plugins.
> Which is an approach I really liked because you could have your lightweight
> image viewer, but if you just needed to crop, you didn't have to open Gimp
> (or Krita nowadays :-)). What would be really usefull though: add menu
> entries to open the image in an image editor...
Actually, KolourPaint will crop, but doesn't yet have the ability to
digitally adjust the selection (a needed feature). We now have a KDE
scanner application. I haven't throughly looked into the slide show
OTOH, integration is an idea that some want and plugins for a standard
interface certainly has its points. The issue is a product design one
that is a more general issue than just KView. Currently, we appear to
be going with the separate app approach for some of these, but there is
also the (unrelated) KViewShell project. If this could all be
integrated into the KViewShell app, this would be easier for the user.
>>If you look closely, you will find that it has some somewhat hidden features
>>that I never use and which don't work correctly. Currently you can step
>>through the images in a directory but this feature isn't 100% stable. I
>>don't know if this is needed or not.
> Don't hesitate to ask me, I should be able to motivate most of the
> features. :-)
The: "Resizing" options are hidden in the "Configure" dialog. I think
that this is a usability issue and needs some rethinking.
> Especially the stepping through the images in a directory is a very usefull
> feature. Why it doesn't work correctly 100% of the time I never understood.
> At some point I gave up and hoped it wasn't my fault and would some day get
> fixed in kdelibs ;-) (though I did go through the kdelibs code as well).
We have 4 votes to keep this (including me) so this feature appears to
be needed. Did you try to debug this with the KDE/GNU debugger? One
thing I miss in Linux is the Borland debugger.
>>>>Then, consider whether it is worth the trouble to port it to KDE-4 and
>>>>see if someone will help us with the port.
> I'd go for a standalone KDE3 application.
Yes, I planed to work on the KDE-3 app first. I know the pitfalls of
trying to do too much at once.
More information about the kde-core-devel