[Fwd: KView for KDE4?]
James Richard Tyrer
tyrerj at acm.org
Tue Jun 7 00:28:45 BST 2005
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.
>>status bar and toolbar items on the same bar which is not supposed to be
> 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.
>>>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 :-)
>>>- 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
>>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
> 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
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
> 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.
More information about the kde-core-devel