Ashley Winters sent this mail to kde-bindings list (the listing was stripped due to excessive xml usage :p -- you will find it in the archive):

[snip]

Germain Garand replied to this: Eventually, you'll need to discuss it on kde-core-devel, since that's something very involving for the whole KDE project. The prospect of having documentation mapped to those, and such a thorough formal description of the API is exciting... it goes far beyond mere bindings concerns :-) Also, I'm a bit worried about the timing of your proposal... people are already entrenched in "freeze mode", and by christmas, the mailing lists will probably look like a mornfull desert. Maybe posting an introduction to your work (to kde-core) a tad before could help to open up the minds?. I must agree with him on this. Regarding the timing, Ashley replied: I don't have such a short timescale in mind. KDE-3.2 doesn't need anything I have to offer -- it's already great. Nor am I asking for a change to the KDE source-code or methodology (unless someone comes up with a good idea for doing so). I would like to shoot for integration with KDE-4.0 down the line (and, perhaps, to nudge Qt-4.0 far enough into my corner to make it work REALLY well with this design)..

There was some technical discussion in the thread -- as i said, go, read the archive.

In a different vein, i quite look forward to rdf.kde.org. Looks promising.

Falk asked the list about electing the maintainer for KDevelop:

Both developers replied, saying they could do the job, if needed. Also, Alexander raised concern about Caleb Tennis having done a lot of work for 3.0, and about being unfair electing someone else just before release. To this, Falk replied: Caleb was great but it's no good to have noone being active. OK, if nobody wants to be the official maintainer, this discussion can be closed, and we just have 2 unofficial ones. chuckle. Alexander agreed, and put out a new vote:

As there were no more posts, i guess this proposal passed.

Update: Amilcar sent his blessings of this proposal to the list, too.

Two long threads came out of this innocent-looking post:

Eric Laffoon pointed Melvyn in the direction of KImageMapEditor: You're in luck (or we're just lousy getting the word out). KImageMapEditor, which can be found by the same name on sourceforge, not only does a great job here but it works as one of the standard plugins with Quanta. It's really tempting to put it in CVS so it ships with it if people aren't finding it. Any votes?. Rest of the discussion was mainly concerned with putting KIME into Quanta CVS and its pros/cons. However, it was generally agreed, that, as there is no tool even remotely close to KIME, author should be contacted and its inclusion negotiated. You can read about this in next summary.

Eric Laffoon executed the consensus from previous thread and contacted the KIME developer (Jan Shaefer):

Jan was heard to say: Well, I have thought about this myself, as I think that everybody, that uses KImageMapEditor, also uses Quanta. The main problem is perhaps, that people using Quanta, who wants to do an image map, will look in the Quanta menus, wether there is any possibility of doing this. If they don't find an entry, they do the image map by hand. So, I am for moving the CVS to KDE. I have write access to the KDE CVS, so I can do this. Within the next week I will do it.. After this point, thread turned into discussion about directory layout within quanta module. Andras proposed 2 solutions:

kommander
kfilereplace
kimagemapeditor
kxsldbg (is it usable as a standalone app?)
...
quanta
    libs
    plugins
    parts
    ....

The discussion ended when Eric summed up the decision like this:

Karl-Heinz Zimmer announced on koffice-devel:

In a mail on kde-optimize, Oswald pointed out a performance problem with KDE applications in non-native (ie. non-KDE-session) environment. You might know this problem -- try to launch eg. konqueror in a blackbox session. Casey Allen Shobe seconded, giving specific example: I would say that when a KDE application is started, that it should not start the DCOP server when KDE is not running. Some people have complained that this is the biggest problem with running a minimal X with a fullscreen konsole, and I can speak from experience that starting Konsole on my SparcStation 20 w/2x125MHz CPUs & 360Mb RAM from ratpoison (minimal window manager) takes 3-5 seconds to start. When wanting to run it at startup, it was quite annoying to have a 3-5 second delay to get started in an environment that otherwise started instantly.. George came with a counter-example: So if I start app X and KDE is not running, it doesn't start dcopserver and doesn't talk dcop. Then I start app Y. App Y sees that KDE is not running and does not start dcopserver or talk dcop. I want app X to talk to app Y. How? Also since most apps use kded, it's kind of pointless to avoid starting dcopserver. It's almost guaranteed that an average KDE app is going to talk to kded sooner or later.

David came with idea to special-case konsole (and other apps who need the kded/kio/dcop/whatever not). Lubos was concerned with creating too mich special cases all over the place, but David reassured him this would be rather limited. Josef Weidendorfer came with idea of delayed kdeinit startup like this: "(dcopserver; konsole) & (sleep 5; kdeinit)" which supposedly gives you the konsole itself much faster. He asked whether this could be made default for whole of KDE, but Waldo cooled him down: You must be able to guarantee that konsole will not try to access klauncher, kded, kdeinit or ksycoca during the first 5 seconds and that it doesn't need kconf_update to update its settings before it uses them..

Chris Humphries wondered why one has to be concerned by performance of KDE apps outside KDE at all. Oswald explained: every heard something about interoperabitily? that includes that an app behaves in a foreign environment, also performance wise..

In another subthread, the discussion about konsole continued. However, it was concluded konsole, too, uses daemon-provided facilities and thus would be rather inpractical to make her run in daemonless environment. The load-on-demand argument was raised once again (by Casey), but David reasserted this would be of limited use (not talking about implementation complexity).

So, there was no real conclusion, apart from sticking to status quo for now. Maybe we'll see some work in this area for 3.3...

Two announcements regarding image viewers have happened in the extra-gear mailing list recently. On Sunday 30, Aurelien Gateau announced the release of Gwenview v1.0.0 with the following message:

The day after, Richard Groult announced that his program "ShowImg" had just been added to kdeextragear-2:

While the news were received well (BTW: Congratulations to both Gwenview and ShowImg, the two are very nice apps.), some people noticed that the two applications were very similar, what resulted in a discussion on whether or not it is wise to have that many image viewers in the KDE repository, given that kdegraphics already ships KuickShow and KView. Especially on the Gwenview-related article at the dot, lots of comments were made in that sense.

We have talked with both Gwenview's developer Aurelien Gateau and ShowImg's developer Richard Groult about their applications, the "there's too many image viewers in KDE!" issue and the possibility of merging these apps:

Interview with Aurelien Gateau

Gwenview 1.0.0 was just released. What makes it unique, i.e., why should I choose it when there are already so much image viewers around?

Aurelien: It's strong points (to me) are:

• A dockable view interface which let you adjust Gwenview layout to the type of images you're looking at. For example, I don't use the same layout to browse icons than to browse wallpapers of photos.
• It can manipulate your jpeg files losslessly using jpegtran, without losing EXIF information.
• You can easily edit JPEG comments without the hassle of opening a property dialog for each image.
• It does not try to do everything. I do not want to implement every possible feature like batch renaming or html gallery generation. Instead you can define external tools and start a specialized application for these needs, pretty much like file-associations in a file manager. For example you can do batch rename with KRename or generate an HTML gallery with Kallery. The advantages of this system are:
  • Smaller viewer executable.
  • More flexibility: if you'd rather use another HTML gallery generator than Kallery, you can. You can very easily extend the program possibilities. Have a look at KDE bug 65467 for an example of how it was possible to add a rotate-losslessly-all-selected-images feature to Gwenview 1.0.0.
• No extra dependencies, it relies on Qt to load images.

The kdegraphics package already ships KuickShow and KView. Gwenview is part of kdeextragear. Shortly after the announcement of the 1.0.0 release of Gwenview, ShowImg was added to kdeextragear-2. Other KDE-based image viewers exist outside the KDE CVS. Do you believe there is space for so many image viewers? Do you believe that one of them will eventually "win", making the others obsolete? On a related subject: have you considered making Gwenview part of kdegraphics?

Aurelien: The number of available image viewers is not strange to me. Lots of open source applications are started because someone is not satisfied by the available applications, or find them to be too big, too slow or whatever. Therefore they start developing their ideal application. This is not specific to image viewers, look at the number of available IRC clients or mp3 players.

People have different needs, therefore you can find different applications. As long as application XYZ fullfill someone needs and no other application can, then there is room for XYZ. To me it's even a sign of healthiness, the fact that lots of similar applications exists for KDE means that KDE is quite successfull and that the user can choose whatever application he prefers to perform some task. On the other hand, it's true that this situation leads to code duplication and dispersion of brain usage :-)

As for the two image viewers in KDE, I think it's a bad idea. I believe there should be only one image viewer which would provide the union of KView and Kuickshow features. I think KDE should provide one application for each task, then as a user you can install whatever other application you need. I noticed that in the KDE world, when an application starts to be of production quality, it's often included in KDE: I'm thinking about Quanta, Umbrello, KDevelop or KPovModeler. As a result I realized by looking around me that most KDE users do not run any third-party application. Maybe it's because the standard KDE distribution is feature complete, maybe it's because these third-party applications are not good enough but maybe it's because there's not enough noise around them. With the exception of K3b, I think most KDE third-party application are not really well known.

Concerning Kuickshow, what I find regrettable is that it introduces a dependency on Imlib, which is not used anywhere else in KDE. It's not that bad because Imlib is packaged by most distributions, but it can cause problems (look at the trouble with KDE 3.0 and Debian).

I initially asked whether Gwenview could be included in kdegraphics, (have a look at this long thread: http://tinyurl.com/yllh ). It wasn't possible to include kdegraphics because three image viewers is out of question and Gwenview was not feature complete to replace both KView and Kuickshow, therefore it was decided to move Gwenview to kdeextragear-1.

Do you consider the idea of joining efforts into the creation of a single image viewer program?

Aurelien: Absolutely, you can have a look at this comment I posted on the dot: http://tinyurl.com/ylll. In short, I'm willing to merge with ShowImg, because the programs are very similar, but I have a somewhat precise idea of what an image viewer should do or not do and would like to avoid changing this policy.

Someone at the dot proposed the creation of a plugin-based image viewer system, that would allow us to have a simple image viewer that could be extended with a plethora of plugins? What do you think about this idea?

Aurelien: An image viewer should be extensible, but plugins are not the only way. Plugins are great when there's a tight coupling between the application and the plugin. For example image format loaders are good candidates for plugins (and in fact Qt supports the notion of image loader/saver plugins). But features like acquisition, batch renaming or conversion, slideshow, html generation... can easily be added to an image viewer through process forking. This is what I had in mind when I implemented Gwenview external tool support.

For now, the only place where I think plugins would be usefull is image manipulation because the plugin must manipulate core data of the application. But I think this kind of functions are better implemented in a image editor than in an image viewer. There is quite some movement in this area right now with the new Kolourpaint application and Krita which is coming back to life. I'm looking forward to see these two applications ready to use.

Interview with Richard Groult

Why ShowImg? With Kuickshow, KView, Gwenview, etc. around, what makes ShowImg special? What are your goals?

Richard: The special ShowImg features are:

• the detection of similar images (resolution, format, minor differences, ... can be detected);
• batch rename (using a pattern);
• fast ans light zoom feature;
• support .xcf (as gwenview) and .psd (using gimp);
• album management;
• you can browse the archive files (.tar, .tar.gz, zip,...) and extract images using drag'n'drop...

The goal of ShowImg is just to be an image viewer, with some management features, but not to be an image editor! You can sort, compare, and will be able to search... soon I hope :)

Why did you create it?

Richard: Once upon a time... A long time ago... I've created it to feel the lack of 'good' image viewer, to my mind and for my personnal needs. Now, I add features according to users' and my own needs.

What is your position on the "there are too many image viewers in KDE" issue? Do you consider the idea of joining efforts into the creation of a single image viewer program?

Richard:I wonder how in fact. For the moment,

• users have the choice, not all users want neceserily the same viewer and they have differents needs.
• my personal planning don't allow me to work on it regularly...

Maybe we can ask the users, what kind of new features do they want?

Someone on the dot proposed the creation of a plugin-based image viewer system, that would allow us to have a simple image viewer that could be extended with a plethora of plugins? What do you think about this idea?

Richard: It could be a good idea, but too much plugins can 'kill' the software, look at 'noatun' which I think is too 'heavy' for me... Only some additional features could be written as plugins, like 'print' or 'batch rename' feature.

Conclusion

I would like to thank Richard and Aurelien very much for the interview. I would like, also, to congratulate again both developers for their excellent work.

I would recommend anyone to test both Gwenview and ShowImg, you'll surely like both. While they are really similar, some features are exclusive of one or the other, and it is these little details that will guide your choice.

From the interviews and the dot comments, it looks like there's real possibility of merging ("GwenImg" was proposed as a name...), and that will probably lead to the better image viewer in the world. That would also help me in solving a personal problem: even though I'm using both programs for almost a week now, I just can't choose one! They both seem to be "perfect" ;)

You can find Gwenview at http://gwenview.sourceforge.net and ShowImg at http://www.jalix.org/projects/showimg/.

Update

Aurelien Gateau wants to add that he had a meeting with Richard on IRC where the possibility of a merge was discussed. According to Aurelien, the meeting wasn't very productive [...] We can't agree on some technical choices like whether a viewer should implement everything or rely on external programs for some tasks. Another problem is that Richard can't work on ShowImg in a regular way so it will be difficult to work together. He has setup a Wiki page to discuss the possibility of a merge, which you can find at http://kde.ground.cz/tiki-index.php?page=ShowImg+Gwenview+merge. He notes that he is the only one who expressed his opinion on that page so far, but it would be nice if users could comment on it.