[Fwd: KView for KDE4?]

[James Richard Tyrer]

Hi:

I wanted to make sure that you knew that I do realize that your
application has more features than KView.  The issue I am considering is
whether it is a suitable replacement for KView which I see as a generic
image viewer (that might do with a few less features than it currently 
has).  In this context, your additional features (which are nice) are 
not necessarily an advantage.

Aurelien Gateau wrote:
> Hello,
> 
> I'm the main developer of Gwenview.
> 
> James Richard Tyrer wrote:
> 
>> Gwenview seems OK, but it lacks features that I normally use.
>> Although it has some other features that are probably good.  I
>> don't like the large cursor (hand) and I find that some things are
>> not done the KDE way.  Although it would be nice if the
>> disappearing floating toolbar was added to KDE.  The menus do not
>> comply with the KDE standards -- but I forget that it is only the
>> KView on my system that is compliant with the KDE menu standards
>> :-).
> 
> 
> 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.  You have 
status bar and toolbar items on the same bar which is not supposed to be 
allowed.  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.
> 
>> I found the Gwenview KPart for Konqueror to be buggy.  While
>> browsing, I came to an XCF file and although the app showed it
>> fine, the action of the KPart was to open The GIMP.  Then I came to
>> a small picture (jpg) and it opened the KPart for KView.
> 
> 
> I guess you're speaking about the image KPart (Gwenview has two
> KParts, a file and a dir one).

Yes, the one that showed up in the right click: "Preview In" menu.

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

> Of course if there's some way to keep the same KPart while browsing
> files, we would be glad to fix Gwenview.
> 
I do not know how the KView KPart does this, but it does do it.
>  
>> To some extent, I see only minor differences between Gwenview and
>> KView so I wonder why the new project was started.  I don't think
>> that Gwenview is ready and KView is a stable application.  I think
>> that it would be less work to maintain KVIew then to get Gwenview
>> ready.
> 
> I started Gwenview because I wanted an image viewer which would show
> the current image and the other images of a folder in the same window
> (You've got to keep in mind that Gwenview was started in 2000).
> 
> I would list the following advantages of Gwenview over KView (in no 
> particular order): - 

> - Thumbnail view. (current SVN version can show big thumbnails up to
> 256x256).

Yes, this is nice.

> - Support for KIPI plugins.

Yes, if it is going to have plugins, they should be standardized.

> - Nicer (IMHO) fullscreen mode.

Yes, but I have configured KView so that I can have a floating toolbar 
to switch images.  Your tool/status bar is neat, but it would be better 
if KDE supported the disappearing tool and status bars.  Currently 
floating toolbars in KDE are not 100% stable -- then do need some work.

> - JPEG comment editor.
> - JPEG lossless operations (rotate/mirror)

Do you mean that KView's rotate and mirror of JPEG are not lossless?

> - Bookmark support.

> - The adjust-image-to-window mode is easier to toggle: It's on the toolbar
> in Gwenview and will automatically be disabled when clicking on the zoom
> toolbar icons. 

Yes it is on the toolbar -- I'm not sure if it needs to be on the 
toolbar -- but it should be in the menu not hidden somewhere.  But the 
Gwenview: "Auto Zoom" doesn't seem to enlarge images to fit the window 
like the: "Fit to Page" operation on KView does.

> It's a configuration preference in KView, and it renders the
> zoom toolbar icons useless.

Yes, this is a serious bug that needs to be fixed.

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

> - Brightness and contrast adjustement (this feature needs more exposure,
> though)

Yes, this is the one major feature I would add to KView.

> - Support for External tools.

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

-- 
JRT