[RFC] Possible KView Maintainership

[James Richard Tyrer]

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
>>>in KDE:
>>>
>>>- 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 negative.
> 
>>>(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 
standpoint.
> 
>>>>	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 
application issue.

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.

-- 
JRT