image viewers: a different approach

[Lubos Lunak]

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

 I have also the same trouble with the KView interfaces, this time even 
considering Konqueror.

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

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

> - Replace the photo album part with Gwenview dir part
> - Merge thumbnail view improvements from Gwenview into Konqueror thumbnail
> view.
>
> 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.

-- 
 Lubos Lunak
 KDE Developer