[RFC] Possible KView Maintainership

[James Richard Tyrer]

Wilfried Huss wrote:
> Am Monday, 24. October 2005 19:16 schrieb James Richard Tyrer:
> 
>>>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.
> 
> 
> As the current maintainer of KViewShell I strongly dissagree with this. While
> it would certainly possible to add the ability to open images to KViewShell,
> the result would be a very crappy image viewer.
> 
> KViewShell is a document viewer, and therefore supports things like selecting
> and copying text, search, exporting of the whole document as ASCII-text,
> outline view, hyperlinks, various page layout modes, integration with kile, ...
> 
> An image viewer would require a very different feature set and GUI, and even
> more important KViewShell's internal structure would not be a good fit for this
> job.
> 
> I don't think anyone would like to view his holiday photos in Acrobat Reader
> either.

Note that I said: "merging" not tacking on.  I don't know if this is a 
feasible project, just throwing out the idea for what it might be worth. 
  Obviously, the shell would have to become more of a shell with a KPart 
for each type of file to be viewed.  This would mean that the menus, 
toolbars, and features available would change based on the type of file 
being viewed.  But there are things common to viewing all files which 
contain an image -- PostScript, DXF, and SVG are more similar than you 
might think.

How would this be different than just using Konqueror?  When KParts are 
used in Konqueror, there is only a limited subset of the features 
available when the KPart is used in a stand alone app.  Here, we would 
want to have all of the features available when using the viewer shell.

You can view (some) Adobe AI files in Acrobat Reader, and copy and 
export parts of an image, so I don't see this as a valid argument 
against it.

Perhaps it would be better to have this (a unified image viewer) started 
as a new project based on Cairo.

-- 
JRT