[RFC] Possible KView Maintainership

[Lubos Lunak]

Dne pá 21. října 2005 22:48 James Richard Tyrer napsal(a):
> I am considering volunteering to be the maintainer for KView.
> This would be contingent on my recruiting 5 or 6 new people to work on
> it with me.  If this would be OK with the main developers, I will go
> ahead and try to get some recruits.

 Wow ... does any of the image viewers that actually happen to be maintained 
now have at least half of that number of developers?

Dne po 24. října 2005 16:17 Matthias Kretz napsal(a):
> On Sunday 23 October 2005 00:14, James Richard Tyrer wrote:
> > The current maintainer said that he could no longer maintain it.
>
> That'd be me. And that statement is right.
>
> > > If I remember well, the main one was there are a few similar
> > > applications in KDE:
> > >
> > > - khtmlimage (kdelibs)
> >
> > IIUC, all khtmlimage will do is display an image as is at 100% in
> > Konqueror
>
> Right, khtmlimage is the most basic KPart based image viewer that normally
> does not have enough features. Scaling is a must have for a viewer. On the
> other hand it does incremental loading which is pretty much impossible with
> the QImage/KImageIO based approach KView uses.

 Which means the KView KPart is far from ideal too, right?

>
> > > (And there is also Gwenview, an extragear application.)
> >
> > The Gwenview maintainer is working on it with the intention of having it
> > included in KDE.  It has more features than KView.
>
> I think there still is a place for KView in the KDE4 world. And having
> Gwenview (and Showimg, and whatnot), the KView maintainer finally has the
> possibility to make KView a real viewer.

 But wouldn't it be better for KDE4 if it simply used something that already 
is a real viewer (whatever that is supposed to mean)? Don't get me wrong, but 
KView hasn't seen much activity lately and it shouldn't be that difficult to 
find another image viewer that has surpassed it meanwhile. In fact I find 
Gwenview to be a good replacement for both KView+Kuickshow, and there are 
probably more (IOW I find it very unlikely that KView and Kuickshow stay in 
kdegraphics for KDE4).

 Nobody can of course stop anybody from working on KView, but wouldn't it be 
better to focus this work elsewhere? E.g. bugs.kde.org has now 10k bugreports 
+ 10k wishes, many of these should be fairly simple and are still open only 
because the maintainer is busy or the component has no active maintainer at 
all. There are so many apps in KDE SVN that could use help, even from new 
developers, so why choose exactly KView?

> Actually my dream for KView was to create a lightweight viewer using KDE
> Component technologies that can be reused throughout KDE. Just look at the
> interfaces I defined (which I never moved outside of KView :-(). They
> provide a generic interface for an image canvas, and an Image-KPart.
> This is really usefull stuff, but I never let it take off :-(

 That certainly sounds interesting, but if I'm getting it right this is about 
new relatively unexperienced developers, isn't it? This is probably not 
something for them.

>
> > >>	Remove some features to make it less complicated -- target it as
> > >>	JUST the general purpose image viewer (users that want more
> > >>	features now have other choices).
>
> Yes, it's probably best to remove all image editing functionality. On the
> other hand I wrote it in a way that KView only provides the hooks for
> editing while the functionality all goes into KPart plugins.
>
> Which is an approach I really liked because you could have your lightweight
> image viewer, but if you just needed to crop, you didn't have to open Gimp 
> (or Krita nowadays :-)). What would be really usefull though: add menu
> entries to open the image in an image editor...

 Speaking of lightweight image viewer, I wonder what exactly that is supposed 
to mean. Going back to my claim that Gwenview can replace KView, Gwenview is 
just as lightweight image viewer as KView, now or with little work, in any 
sense I can think of:

- startup time - for showing a single image it's actually about the same (with 
KIPI support in Gwenview turned off, but the inefficient KIPI initialization 
can be fixed). Given the startup time is dominated by time spent in the KDE 
framework (KMainWindow etc.) rather than application code this is actually no 
wonder.

- memory usage - exmap reported 9M effective memory usage for Gwenview and 12M 
for KView for the same 1kx1k image 
(http://homepage.ntlworld.com/john.berthels/exmap/ - exmap's effective memory 
use value is the best memory-use-of-an-app-as-one-number value I've seen so 
far)

- simple UI - I actually don't see a big difference, but just turning off half 
of the UI elements in Gwenview in order to have Gwenview-light should be 
simple

- small app(=sources) - that has helped neither KView nor Kuickshow :(

-- 
 Lubos Lunak
 KDE Developer