image viewers: a different approach
l.lunak at suse.cz
Thu Oct 27 21:24:46 BST 2005
Dne čt 27. října 2005 17:59 Aurelien Gateau napsal(a):
> Benjamin Meyer wrote:
> >> 2. Enhanced viewer. For image folders (photos). Basic manipulation.
> >> Features: previews, step through images, rotate (and save), exif
> >> manipulation.
> >> Most of the current viewers fit more or less in this category.
> >> 3. Image organization. Not so much a viewer but closely related from the
> >> users perspective. From a simple folder layout to a database, depending
> >> on what the user wants.
> >> Kimdaba belongs in this category. Afaik digikam has such features as
> >> well.
> > I don't really see a difference between #2 and #3. #2 really seems to be
> > a relic of 1998 where everyone was writing there own photoViewer2000++
> > and cramming as many things into it as possible, but being crap compared
> > to photoshop. Enhanced viewers are both crappy editor and crappy
> > organizers because of how they define themselves. Much more usefull as
> > shown by countless companies producing applications such as iPhoto are
> > image organization applications with basic manipulation.
> > Really there should be three, not four
> > 1) Image viewer component that any application can use
I have to admit I have a little trouble coming up with an application that'd
benefit from this and wouldn't be called Konqueror, but maybe that's just me.
And not that it really matters anyway, Konqueror is good enough a reason
I have also the same trouble with the KView interfaces, this time even
> > 2) Image Organizer with basic editing tools
> > 3) Image Editor
> I agree with you, and that's why I always resisted to implement funky image
> effects in Gwenview (only manipulations available for now are rotation and
Note that 1) says component. Gwenview the app is closest to 2) here. And
editing makes sense there. One probably doesn't want to do cropping or red
eyes correction on a bunch of photos in Krita.
> I was thinking about how Gwenview could be integrated to KDE 4.0 a few days
> ago and I came to a possible solution: forget Gwenview as a standalone
> application, focus on KParts and Konqueror instead:
> - Replace the khtmlimage part with Gwenview image part
AFAIK the main reason why khtmlimage still isn't pushing up daisies is that
it's in kdelibs, so that just kdelibs+kdebase is enough for viewing images in
> - Replace the photo album part with Gwenview dir part
> - Merge thumbnail view improvements from Gwenview into Konqueror thumbnail
> It sadden me a bit to give up the standalone application, but maybe this
> would be the best solution...
That wouldn't be that big loss given that app/ is just relatively small
portion of gwenview/ . Which first of all means keeping app/ around shouldn't
be that big effort, and it also means that both the app and parts benefit
from improvements in gvcore/ where most of the code resides.
And we shouldn't hurry that much with dropping the app before checking this
really would be the best solution. Gwenview in browse mode indeed looks a lot
like Konqueror with gvdirpart, view mode looks a lot like Konqueror with
gvimagepart, and a lot of code in app/ more or less duplicates what Konqueror
can do as well, but there are issues. Technical issues would be things like
fullscreen mode - a KPart can't make Konqueror (or any hosting app for that
matter) switch to fullscreen mode and it probably shouldn't; on the other
hand Konqueror's fullscreen mode is just making the window fullscreen and
removing the menubar, which is far from Gwenview's fullscreen mode.
Non-technical issues could be e.g. usability things like people already
complaining about Konqueror being too complicated and whatever ... I guess
I'm too resilient here to really judge this :).
I'm not against this, it would certainly make sense in many areas (funnily
enough it could mean e.g. faster startup because of Konqueror preloading) and
after a quick thought I don't see any fundamental reason against (technical,
no idea about the users point of view). But there shouldn't be just a quick
thought and we should first reconsider what this would mean for Konqueror and
KParts and for which kinds of documents this would make sense.
More information about the kde-core-devel