[Fwd: KView for KDE4?]

[James Richard Tyrer]

Aurelien Gateau wrote:
> 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.
> 
What I am saying it that these special features for full screen mode 
should be standardized and be part of KDELibs.
> 
> 
>>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.
> 
The disappearing bar in full screen is both a toolbar and a status bar.
> 
> 
>>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.
> 
Yes.
> 
>>>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.
> 
Yes, there should be a limit on how large a pixmap can be created by 
zooming (in any image app).  This should be configurable somewhere (like 
it is in GIMP) so users with a lot of memory could change it.  Is the 
tiled method a possibility since it has some of the advantages of both 
methods.
> 
> 
>>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.

Yes, this would be a good time for a change.  OTOH, we should avoid too 
much change with KDE4.

> 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), 

KWrite and Kate are the same application with two personalities.  KWrite 
is a basic editor and Kate is an editor with a lot of features.  Perhaps 
this same strategy could be used with the image viewer.  A viewer with a 
lot of features could also have a simpler personality (like KWrite) for 
users to use when they just wanted to look at an image.

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

As long as it has the features, there should be no great problem.

> but I think it has some advantages too.

Yes, if you can develop Gwenview into a viewer that will have the 
capabilities of KView and Kuickshow, this would be good.  Or, if someone 
was available to do it, we could make a single viewer from KView and 
Kuickshow to replace them.

-- 
JRT