image viewers: a different approach

Ingo Klöcker kloecker at
Sat Oct 29 22:31:41 BST 2005

On Sunday 30 October 2005 00:00, Benjamin Meyer wrote:
> On Friday 28 October 2005 6:39 pm, Ingo Klöcker wrote:
> > On Friday 28 October 2005 12:08, Benjamin Meyer wrote:
> > > Just to kill this portion of the thread here are a few apps off
> > > the top of my head that want an embeded viewer for images:
> > >
> > > KMail, viewing images
> >
> > Sorry for repeating what I already wrote above:
> >
> > Why should we want an embedded viewer for images in KMail? If we
> > show images inline then they are simple <img> tags in the HTML code
> > we create for displaying the message in the KHTMLPart. So no
> > embedded viewer is needed for this.
> You make no sense.  You are embedding khtmlpart so embedding *is*
> done.  In essence khtmlpart is your image viewer.

It might not make sense to you because I didn't explain it good enough. 
Anyway, the current situation is like this:
- For viewing messages we use KHTMLPart. If attached images are shown 
inline then they are obviously displayed by the KHTMLPart. This won't 
- For viewing single attached images (e.g. via context menu->View) we 
currently open a simple window with a KHTMLPart which displays a 
trivial HTML page with a single <img> tag.

I don't like the latter (because the user can't even rotate the image) 
and therefore want to use an external image viewer in KDE 4.

> > And if the user wants to view the picture
> > then why should we use an embedded viewer instead of a fast
> > standalone viewer. In fact I'd very much prefer to use an external
> > standalone viewer instead of an embedded viewer because it means
> > less code.
> Because people send each other photos all the time, not having to
> launch another app to view a common image formats is a feature most
> people expect a mail client to do.

Do people also expect the mail client to allow rotating, scaling, 
whatnot'ing the image? Because this is what this discussion is about, 
no? If people don't expect this then we can simply stick with our 
current solution and thus have no need for a KImageViewerPart. And 
FWIW, I surely don't expect to be able to do any image manipulation in 
a mail client.

With respect to "not having to launch another app": The user doesn't 
care whether an external image viewer is started for viewing the image 
or not as long as the image is displayed (almost) instantaneously. Of 
course, the latter might be a problem due to slow starting apps. 
Anyway, the problem I have with embedding a KImageViewerPart is the 
additional code that's necessary for this and that needs to be 
maintained. For starting an external app no additional code is 
necessary because we anyway need this code for viewing attachments 
which can't be viewed by KMail (e.g. PDFs).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the kde-core-devel mailing list