[Fwd: KView for KDE4?]

[Aurelien Gateau]

Le Dimanche 5 Juin 2005 09:51, James Richard Tyrer a écrit :
> Aurelien Gateau wrote:
> > The hand cursor will be removed soon I think. Can you give more
> > details on the things which are not done the KDE way ?
>
> The toolbar in the full screen mode is very neat, but ... (tm).  This is
> unique to Gwenview and the fact that is different is an issue. 

I always thought fullscreen mode is a different experience, after all in this 
mode, the application controls the whole screen, it's supposed to be more 
"immersive" (not sure it's the correct word). Furthermore, if you look at 
other KDE applications, some implement their very own appearance in 
fullscreen mode: KPDF for example has a special toolbar and a custom widget 
(the circle) to indicate the current page.


> You have 
> status bar and toolbar items on the same bar which is not supposed to be
> allowed.

I don't understand to which part of the toolbars you refer.


> As has been said, you don't have a "Fit to Page" menu 
> entry/toolbar button which is a KDE Standard Action.  Most KDE apps that
> deal with images have a: "View -> Zoom" function (I miss this).  The
> menu standard includes this function.  The shortcuts for "Zoom In" &
> "Zoom Out" do not work as expected.  This is neat, but it is non-standard.

This could be fixed.


> > I think this is just a problem of KPart priority: IIRC it's Konqueror
> > which decides whether it uses a part or start an application when
> > loading a file. If the setting for XCF is "Open in external app" and
> > the preferred KPart for JPEG files is KView you will get the
> > behaviour you observed.
>
> Yes, some experimenting with settings and I confirm that what you say is
> correct.  However, KView does not have this problem.  It displays the
> XCF file in the embedded viewer despite the fact that the properties for
> XCF files are set to: "Show file in separate viewer" and nothing is
> selected for an embedded viewer.  So, I do consider this a bug and it
> appears to be a serious one.

I guess it's time to have a look at KView KPart code then :-)

[snip]
> > - Much faster zooming. If I remember well, KView loads images in a
> > QPixmap and zooms this QPixmap, while Gwenview loads images in a QImage
> > and only zoom the visible region.
>
> There is a trade off here.  If you zoom the whole image, you can scroll
> and pan with no delay.  Your app does zoom faster but there are delays
> when you scroll and pan a zoomed image.

I don't think it's a wise trade off, because zooming to much might well blow 
your X server away. Using really big QPixmap is not a good idea.


> And, note that all of this is just my $0.02 on the question.

Sure. We could debate for a long time on whether Gwenview is better than KView 
feature wise and is KDE compliant or not, but I don't think it's the right 
problem to address (although I would like to make Gwenview more KDE 
compliant).

The real question IMHO is whether KDE should keep the same image viewing 
applications for KDE4 or whether KDE4 is a good opportunity for a change.

Actually, KDE provides two image viewers (KView and Kuickshow), which are not 
very well maintained. Since KDE has often been criticized for providing 
redundant apps (not only KView vs Kuickshow, but also KEdit vs KWrite vs 
Kate), it would IMHO be a good idea to replace two not-very-well-maintained 
apps with one which is actively developped and which has already been 
selected as the default image viewer by some distributions (Kubuntu and 
SuSE).
Of course this won't please users who are accustomed to KView and Kuickshow, 
but I think it has some advantages too.

Regards,
  Aurélien