KDE Traffic #71 For 14 Dec 2003

Editor: Peter Rockai (mornfall)

By Henrique Pinto  and  Peter Rockai (mornfall)

This issue is dedicated to memory of Mario Mariano, Henrique Pinto's grandfather, who died of cancer recently.

Table Of Contents

Introduction

Welcome to KDE Traffic!

If you like KDE Traffic, please consider making a donation to the KDE project. Visit http://www.kde.org/support/ for details.

I would like to apologize to Diego Iastrubni for misspelling his name in KDE Traffic #69. And sorry for being late with this, it slipped my sight in the last issue.

In a different vein, we noted an increase in "[PATCH]" traffic on the lists, especially on kde-core-devel. Also other lists reflect the fact we are nearing the release: last-minute fixes, bugfixes and the like are more common as the release approaches. Also translators are working hard to bring their respective languages up to date. All in all, we are nearing a release: you can feel it from the mood on the lists.

The new kdepim-users mailing lists is now among the covered lists. As there was almost no traffic on that list yet, no threads from it are being covered in this issue, but we are watching it closely, and as soon as there is some interesting content in the list you'll have it covered here. We are looking forward to cover more mailing lists in the next issues, if you have any suggestions or if you think you can help us, feel free to drop us a message (mailto:kc-kde@kde.org) .

The kde, kde-devel, kde-core-devel, kde-extra-gear, kde-usability, kde-i18n-doc, kmail-devel, kde-pim, kde-optimize, kfm-devel, quanta-devel, kopete-devel, kde-bindings, kdevelop-devel, koffice-devel and kolab-devel mailing lists are also being covered, what means that now we're covering 17 lists.

We hope you will like this issue!

Mailing List Stats For This Week

We looked at 721 posts in 3075K.

There were 204 different contributors. 115 posted more than once. 101 posted last week too.

The top posters of the week were:

1. RDF of KDE API [kde-bindings]

10 Dec 2003 - 11 Dec 2003 (6 posts) Archive Link: "permanent URIs"

Summary By Peter Rockai (mornfall)

Topics: KDE Core Development, KDE Bindings

People: Ashley WintersGermain Garand

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

Howdy folks,

I've come scurrying out from behind the rocks to float an idea past you. If you have a long memory, you know I'm auto-generating some RDF/XML voodoo to completely specify the API of KDE. Since every method in KDE will have a URI, I'd like a permanent place to house the resulting data.

For instance, here is an example (non-existant, as yet) URI that I am contemplating use of right now (it's a doozy):

http://rdf.kde.org/kde/3.2/kdeui#KPushButton::addButton(const+QString&,+bool)

Some sample XML from /kde/3.2/kdeui would look like so:

[snip]

That concludes today's RDF exposition. Is my idea of rdf.kde.org too much? Would it be worth proposing once I come up with some library-specific XML files and a version of smoke to use them? :)

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.

2. KDevelop maintainer [kdevelop-devel]

9 Dec 2003 - 15 Dec 2003 (6 posts) Archive Link: "KDevelop maintainer"

Summary By Peter Rockai (mornfall)

Topics: KDevelop, KDE Development

People: Falk BrettschneiderAlexander Dymo

Falk asked the list about electing the maintainer for KDevelop:

Hi,

IIRC last election hadn't a result. For instance harryF never agreed... We noticed that situation on IRC #kdevelop yesterday. Well, this is a new trial. :-)

What about setting amilcar to the maintainer? Actually he's already doing (well) what a maintainer does, so he just would get the title and About-box entry, additionally. Another active guy (concerning to organization stuff) would be adymo...

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:

Good idea, Falk! :)

New questions to put to the vote:

  1. assign two official maintainers for the next KDevelop release (me and Amilcar);
  2. assign above two persons as unofficial co-maintainers for current KDevelop release.

PS: I agree. Amilcar?
PPS: Silence means agreement :)

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

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

3. Quanta and KImageMapEditor, part 1 [quanta-devel]

8 Dec 2003 - 9 Dec 2003 (13 posts) Archive Link: "Image widgets"

Summary By Peter Rockai (mornfall)

Topics: Quanta, CVS

People: Melvyn SopacuaEric Laffoon

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

Hi,

I had to create an imagemap last week and ended up with The Gimp and some guessing. Then I thought it would be a nice "ease into KDE development" project for me, but was surprised to not find a widget to create a selection on an image or at least an imagewidget that receives events.

Does anybody here know if there is such a thing or is creating a custom widget the only way?

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.

4. Quanta and KImageMapEditor, part 2 [quanta-devel]

9 Dec 2003 - 11 Dec 2003 (13 posts) Archive Link: "Quanta and KImageMapEditor"

Summary By Peter Rockai (mornfall)

Topics: Quanta, CVS

People: Eric LaffoonJan SchaeferAndras Mantia

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

Hi Jan,

I don't know how closely you've been following the quanta developer list... Of course I wish it was very closely because you were contributing lots of code to Quanta. ;-)

Recently one of our developers posted looking for a program like yours. It all comes back to me how frustrating it can be making sure your program is known. Most of us don't do imagemaps everyday but when we need to your program is just what the doctor ordered. I took a look on your site and saw the mention of a few language translations and I was wondering the status of development. It seems to work really well and do all that's needed. (I especially liked when you showed Homer Simpson's brain x-ray)

My question is whether you would like to move KImageMapEditor into the Quanta CVS module. My initial motivation is insuring exposure and inclusion of a really great plug in tool. Additional benefits would be that it would be translated by KDE translators and benefit from other KDE people with some maintenance. It's a real no brainer where it should go with inclusion in KDE and ironically we've been given a wide latitude to incorporate web related programs as we deem them worthwhile. In that regard KIME seems almost overdue.

The inclusion would be in the development branch (quanta_be) for now and into HEAD after 3.2 but we will be releasing BE as our premiere package during 3.2 given the profile of what is done and what's in work. The big question would be where you are at on this. Ideally you would move CVS to KDE in the Quanta module and do other fun stuff with us. ;-) However there are a number of options as to how to proceed if you like this idea.

Please feel free to respond on the list as this has been a recent topic of discussion and I'm happy to conduct the conversation there.

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:

We can go in two ways:

  1. treat the quanta CVS module as a module, like kdebase, kdepim, etc.
  2. treat the quanta CVS modules as one app with several plugins and additions, like in case of kdevelop

In case 1 we can have a structure like:

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

Case 2 what we have right now, but with somewhat different structure, as now some things are under plugins which are tightened very much to quanta core and also the kafkapart is using quanta core, so I don't know if we can call it a completely separate part. And it's not installed as a part...

Maybe you're right and #1 is better. But this requires moving of data on server, so we must first carefully plan how we would like to be our directory structure and ask the sysadmins to move the files.

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

To sum up:

  1. After 3.2 all plug in apps go to first level directories
  2. Andras will specify where to put KIME at this time as he will be managing the move later.

5. KDChart updated in KOffice [koffice-devel]

13 Dec 2003 (1 post) Archive Link: "KChart now updated to current KD Chart 1.x source level."

Summary By Peter Rockai (mornfall)

Topics: KOffice

People: Karl-Heinz Zimmer

Karl-Heinz Zimmer announced on koffice-devel:

Hi,

having integrated our KD Chart 1.x branch sources into KChart now I will be available (by mail) tomorrow in case there should be any concerns or complaints ... you never know. ;-)

This commit was for bug fixing purposes only, all existing features should function just as they did before, so no change in the KChart code should be neccessary due to this sync, see CVS comment for details.

6. KDE application performance outside KDE session [kde-optimize]

8 Dec 2003 - 13 Dec 2003 (32 posts) Archive Link: "dcop auto-overuse"

Summary By Peter Rockai (mornfall)

Topics: Optimization

People: Casey Allen ShobeGeorge StaikosWaldo BastianOswald Buddenhagen

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

7. Image Viewers [kde-extra-gear]

7 Dec 2003 - 8 Dec 2003 (4 posts) Archive Link: "[Kde-extra-gear] Gwenview 1.0.0 has been released"

Summary By Henrique Pinto

Topics: Image Viewers, New Application

People: Aurelien GateauRichard Groult

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:

I just released Gwenview v1.0.0. The changes are the following:

Get it from http://gwenview.sf.net

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

Hi,
I just inform you that ShowImg ( http://www.jalix.org/projects/showimg/ ) is now part of kde extra gear (yes... another image viewer :)

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 (http://dot.kde.org/1070836018/) at the dot (http://dot.kde.org) , 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:

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 (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

(ed. [Peter Rockai (mornfall)] I have corrected the text of Richard's answers -- the sense remained unchanged as far as i can tell)

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

Richard: The special ShowImg features are:

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,

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 (http://gwenview.sourceforge.net/home/) and ShowImg at http://www.jalix.org/projects/showimg/ (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 (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.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.