[RFC] Possible KView Maintainership

[Wilfried Huss]

Am Wednesday, 26. October 2005 22:05 schrieb James Richard Tyrer:
> >>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.

What you describe is exactly how KViewShell works, with two important
differences.

First KViewShell does not load arbitrary KParts, but only subclasses of
the KMultiPage class, which provides a high level but extensible API that
allows you to create a KViewShell plugin for a certain format by implementing
only a handfull of functions. The result is a full featured viewer for this
particular file type.

Second, while plugins are allowed to add their own menu- and toolbar items,
configuration settings, sidebarwidgets, and much more, all functionality
which is common to all supported fileformats is provides by KViewShell itself,
and we try to keep the interface differences between the different filetypes
as small as possible.

Most of what KViewShell provides for it's plugins, makes no sense for simple
images.

> 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.

So your viewer will not really share much code between different filetype
plugins, and also the GUI will be different. So what's the advantage of
this approach over different application for different types of files?

> 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.

This only works because AI files in newer versions of Illustrator are
just PDF files, with some additional features probably. Just as AI files
of Illustrator < 7 or 8 are basically just PostScript files, that you can
open in any PS Viewer.

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

Greetings,
Wilfried Huss