KDE Traffic #68 For 16 Nov 2003

Editor: Peter Rockai (mornfall)

By Henrique Pinto  and  Peter Rockai (mornfall)

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

Table Of Contents


Welcome to KDE Traffic!

First some news regarding the Traffic itself: the stats are back, but with one "but": the sizes (kilobyte) are guessed now. As we generate the stats from gmane nntp gateway, we only get line-counts for articles, but not the byte-sizes. Our script simply multiplies this number by 70 and uses it as byte size. Better solutions are sought, but yet none found.

Also, we would like to invite you to help us writing the traffic. Not only writing summaries can be helpful, but also language (style, grammar) or factual reviews, or some other way, unthought of as of yet. If you want to help out, please subscribe to our mailing-list, kc-kde (https://mail.kde.org/mailman/listinfo/kc-kde) .

Everyone who help out (in way other than writing summaries, in which case they will be listed among authors) will be mentioned in the introduction, as to get the credit they deserve.

In this vein, I would like to thank Charles de Miramon and Chester for helping with the last issue (kde20031109_67.html) (#67), as I forgot to do so the last time. Please accept my apologies. I hope this will not happen again.

Credit for this issue goes to Charles de Miramon (again) for proof-reading. Thank you and keep up good work.

At last, I would like to note, that although kde-cvs list is covered with this issue, we want not to step on Derek Kite's (and his nice KDE CVS Digest () ) toes with this, but merely to cover some longer threads, discussing important (in our opinion) topics. Also, this list won't be included in the statistics, as it would create too much noise (in similar vein, we have excluded bugzilla traffic from lists which are bugzilla targets).

This issue covers the following mailing lists: kde, kde-devel, kde-core-devel, kde-extra-gear, kde-usability, kde-i18n-doc, kmail, kde-pim, kde-optimize, kfm-devel, quanta, kde-bindings, kdevelop-devel and koffice-devel.

We hope you will like this issue!

Mailing List Stats For This Week

We looked at 928 posts in 3252K.

There were 252 different contributors. 154 posted more than once. 116 posted last week too.

The top posters of the week were:

1. Toolbars in KDE Applications [kde-usability]

9 Nov 2003 - 15 Nov 2003 (60 posts) Archive Link: "Toolbars"

Summary By Henrique Pinto

Topics: KDE Usability Project

People: Henrique PintoAaron J. SeigoFriedrich W. H. Kossebau

(ed. [Henrique Pinto]

Disclaimer: I have contributed to this thread. Actually, I started it. I was not going to cover it because of that, but I was asked for doing this. This is not intended to be self-promotion. It was only included here because it treats a subject that may be interesting to you (our readers).

Just one more note: I'm actually covering more than one thread here, all of them related to the same subject.


(ed. [Peter Rockai (mornfall)] I was the one who asked Henrique to cover the thread, despite his participation. I have other threads to cover and this one happened on Henrique's list, so it was quite obvious choice. I think it turned out quite well. )

It all started when I sent the following message to the kde-usability mailinglist:

IMO, one of the biggest usability quirks of KDE is the toolbar layout of most apps. Consider, for example, Konqueror. It's default toolbar contains way too many icons (most of which are never used by average users), all of these being incredibly small.

Most users assume toolbars contain quick links to the most used functionallity of an app. Right now, most of our apps contain much more options than needed, and, because of default settings, they aren't really "quick links", as it's difficult to find and click them.

Based on Fitt's Law, I believe the better approach is using larger icons as default (32x32), with text at the bottom. Enabling this at KDE right now, however, will bring you more problems than solutions, since some text labels are incredibly long (and translations don't help, either), and most buttons end up hidden because of lack of space.

My proposal here is to discuss ways by which toolbars can get better, and implement these after the release of KDE 3.2 (It is madness to try to do that for 3.2, IMO).


Friedrich W. H. Kossebau, Vincent Wagelaar, Michael Pye, Luciano Montanaro and William Leese posted suggestions on how to improve the current situation regarding toolbars.

Shortly after sending the original message, I found a link to a page in the KDE CWS regarding the toolbars in KDE applications. After reading through that page, Aaron J. Seigo sent a message stating that he agreed with most of what was there, and proposed a patch for KMail toolbars (the KMail case is being covered in a separate section of this issue of KDE Traffic). Aaron also stated that he had a message sitting in his drafts folder, waiting to be posted after KDE 3.2 and covering many of the issues regarding toolbars. This indicates, that there will be even more discussion about this subject in the future (and this is great, IMO).

After the successful KMail case, Aaron asked:

what app next? (and please don't say konqueror... ;)

The answer was quite obvious: Konqueror! After many people asked for it, and Christoph Niemann started another thread devoted entirely to Konqueror's toolbars, Aaron explained that "it's easier to get changes to the toolbars of less complex apps in prior to the 3.2 release at this point in the release cycle. messing with Konqi's toolbars is a next version thing; some aspects may even be a KDE4 thing as it may require some changes to how Konqi and/or the toolbars work."

Besides that, there was also discussion regarding other applications. Charles de Miramon commented on KAdressbook toolbars (he was happy to find out that the problems had already been solved) and Sander Devrieze posted to show some usability problems regarding toolbars in kdegames.

The discussion is still open. It's also likely to continue again after the release of KDE 3.2, when it is possible to work more on the toolbars. If you have any comments on the toolbars in general or in a specific app, fell free to add your ideas to the wiki page (http://kde.ground.cz/tiki-index.php?page=Toolbar+Review) .

2. KMail toolbar cleanup [kmail]

9 Nov 2003 - 11 Nov 2003 (10 posts) Archive Link: "Re: Toolbars"

Summary By Peter Rockai (mornfall)

Topics: KMail, Usability

People: Aaron J. SeigoIngo KlöckerIngo KlöckerHenrique Pinto

Aaron posted a lenghty proposal for KMail toolbar cleanup (as a reaction to ours Henrique Pinto's post to kde-usability:

On Sunday 09 November 2003 12:45, Henrique Pinto wrote:
> I've just noticed that
> http://kde.ground.cz/tiki-index.php?page=Toolbar+Review

i agree with just about everything there, except the "Text Aside Icons" bit... i'm very concerned that this would make KDE much more cluttered looking and much harder to use on smaller screens... this is also wasted space once the user learns the basic icons (e.g. print) and most users won't know how to change that default...

otherwise, re: the clipboard icons: yes.. they should be removed from the ui_standards.rc file... there ought to be, IMHO, separate ui_standards.rc files for different types of apps, actually... for document centric editting apps, the clipboard icons should probably be there...

the undo/redo icons should also be removed. the arrows are bit too generic to be on a toolbar IMHO, and even less useful than the clipboard actions.

i also support the concept of removing the Help, Configure and Quit toolbar icons from wherever they appear...

i actually have an email sitting in my drafts folder for a post-3.2 mailing that covers many of these issues; i'd like to see us reduce toolbar icons by 30% or more in KDE ++(3.2).

looking at kmail's composer window, for instance, removing Print (how often does one print from the composer window?), undo/redo, New Composer gives us 10 icons, down from 14. that's a 28.5% improvement right there without even breaking a sweat =)

i'd probably argue for removing the Automatic Spellcheck button. and the Sign button. those are probably items people either use 99% of the time, or don't use at all. that would bring the count down to 8, and we're approaching 50%.

the address book icon could likely be removed as well since what one most likely wants is to add addresses to an email... if they wish to just consult the addressbook, they can open it up separately. that would result in just 7 icons.

as a minor niggle, Attach should probably be next to the Queue button since it's likely the next most often used icon.

kmail's main window is a lot more difficult, though the configure icon should almost certainly be removed, ditto with the Delete button ... the other 12 icons are defensible though. there should be a separator between the Print and Check Mail buttons. and Next/Prev msg should probably move to be between the mail check buttons and the trash button.. why? because one checks mail, reads through it, occasionally deleting or replying.

the resulting clean up and reduction is DRAMATIC. try it. patches attached.

kmail devels: ok to commit?

Soon afterwards, he posted screenshots of new mainwindow (http://tiki.urbanlizard.com/kmail_toolbar.png) and composer (http://tiki.urbanlizard.com/kmail_composer_toolbar.png) toolbars.

Ingo commented:

Apart from that you have green light for kmmainwin.rc although I wonder why you didn't remove the address book icon from the main window toolbar.

kmcomposer.rc: What I don't understand is why you want to remove the sign icon but not the encrypt icon from the toolbar. I guess because IYHO people normally don't disable signing once they've enabled it. Still I think signing and encryption should both be visible. After all the signing icon not only serves as action to dis-/enable signing but also as indicator that signing is enabled. Furthermore signing and encryption definitely complement one another. It would IMHO be odd if one of the two actions was missing. I'm okay with the other changes.

Also, he was concerned about existing users: "One thing I don't like about toolbar changes in general is that the changes will always be forced on all users and not only on new users (provided the version number of the rc file is increased). Especially for users who don't know how to re-add icons they've got used to this will be a PITA." . And while this is very much true, neither i nor any of the contributors to this thread knew of any simple and elegant way of preventing this (apart from Aaron noting the toolbars should have been well-designed from the start, which doesn't seem all that helpful in the light of current situation).

On another sub-topic, few people (with Ingo in lead) requested sign icon to be left where it was. Aaron counter-argumented "not only is signing something one usually sets up once and leaves that way, but encrypting is different in another way: signing relates to YOUR identiy while encrypting relates to THEIR identity. so the choice to encrypt or not really complements the action of sending an email TO someone, as who you send it to usually dictates whether you encrypt it or not." This might be true, but still (well i am biased as well) i somehow agree with Ingo. While the thread perished unconclusively, investigation on kde-cvs shows Ingo overruled them all, putting the sign button back.

3. SUSE Linux and KDE [kde-core-devel]

11 Nov 2003 (1 post) Archive Link: "Statement"

Summary By Henrique Pinto

Topics: Promotion

People: Richard Seibt

Recently, Novell announced it will be acquiring SuSE, and this led to speculations about the future of KDE in SUSE Linux.

In a message sent to the kde-core-devel mailinglist, Richard Seibt, Chief Executive Officer of SUSE LINUX AG, clarified the situation:

Dear KDE developers,

since I joined SUSE in January 2003, I learned that KDE is one of the most successful and fastest evolving open source projects. Since the first day I use it myself and I am thrilled with it. My personal thanks to all of you who contributed in the last seven years to KDE.

KDE is the defacto standard for Linux desktops in Europe. Without KDE, I do not believe we would be seeing the interest in Linux on the corporate desktop that we are seeing today and on the consumer desktop as well.

Please be clear: SUSE LINUX will continue to strongly support KDE.

Both the Ximian and SUSE LINUX acquisitions reaffirm Novell's strong belief in the value of the open source development model and strengthen Novell's commitment to supporting the open source community. SUSE LINUX is an integrator with a wealth of experience in working with both the open source community and the IT industry. SUSE LINUX brings extensive experience in KDE and has a track record working with GNOME. Ximian has core competence in GNOME and a great desktop focus, both in platform and product offerings.

Together with our Ximian colleagues at Novell, we will also enable our customers to use GNOME with the same convenience and comfort KDE offers to me and all SUSE employees today.

The integration capabilities SUSE LINUX brings will continue to help seamlessly integrate Linux-based offerings, inside and outside of Novell. Together, we might even think about new opportunities to leverage the usage of Linux on the desktop. E.g. why do we not open Linux for Apple's Mac OS desktop?

Today and tomorrow, we must be strongly committed to deliver what our customers ask us for. They know best what tools will help to fit their needs. That's why we recently choose our new slogan - Simply change! It is an affirmation to all of us to listen what our customers and users need -- and change our manners and goals, if necessary.

So I really love to stay with you in an ongoing and fruitful dialog.


There were no responses.

4. Kontact: KMail part preloading [kde-cvs]

9 Nov 2003 - 10 Nov 2003 (14 posts) Archive Link: "kdepim/kontact"

Summary By Peter Rockai (mornfall)

Topics: Kontact, KMail, PIM

People: Daniel MolkentinCornelius SchumacherZack Rusin

(ed. [Peter Rockai (mornfall)] Damn. Derek Kite covered this in his CVS Digest. Anyway, i have this written already and won't remove it. I wasn't used to CVS Digest covering longer threads on kde-cvs. But never mind. If you have already read this, feel free to skip this section. Thanks for understanding.)

Whole thread started when Daniel committed some code to kontact: "Preload certain plugins entirely. Currently only kmail does this. This will allow to fix at least the summary view and the "summaryview has no valid "new" action" bug." . Cornelius, with a raised eyebrow, asked "Does that mean that the KMail part is now always loaded on startup of Kontact?" .

Both Ingo and Daniel confirmed his suspicion. Daniel commented: "Right. That's what I discussed with Ingo and Till, and I see no other way around that. Wouldn't it look odd to you if you start you fully integrated PIM suite where you told the kmail part to fetch mails and it won't, because it's not loaded? Upps. Until KMail has not been properly splitted into libs / DCOP services. I see no better way. Otherwise we face a big usability problem and some bugs cannot be solved either (see my commit)." . Cornelius, quite upset by the time, remarked ironically: "So we are finally back to the monolithic monster app we promised not to write? What about removing the KMail summary view? I never understood what it should be good for anyway..." . Daniel tried to calm him down a bit, stating this was only temporary workaround and will be fixed after kmail gets properly splitted (see above). However, this was not enough for brave Cornelius, who, still with ironical grin, replied:

What's the point in retreiving mails before you have a GUI to actually read them? You don't start standalone-KMail in the background for retreiving mails on login either, do you?

In my point of view this at least has to be an option, if we want it at all. One very important point about Kontact is that applications are only started when needed so that we don't create the big memory-hogging monster app we always were make fun of when we talked about Evolution or Outlook. That mails aren't retreived before selecting the KMail part for the first time I can hardly recognize as a bug. This will only give the experience of Kontact being slow. Do you really want that?

This generated some more responses, pointing out korn (which Cornelius promptly used to make Kontact Mail summary look redundant) and raising the issue of KMail split once again (this time David stating, that KMail should provide part for checking email without GUI). This was enough for Daniel, who mumbled "Yes, should. And herein lies the problem. I hope we can solve this for the after-3.2-release, but the KMail guys decided to delay that, and we have to cope with that now." . This led to Zack replying with no less irony than Cornelius:

You make it sound like we've made a silly choice. Split of the core is not something we could do without breaking stuff. It seems people view it as a three step operation:

  1. split core,
  2. make kmail awesome,
  3. go get cookies.

It's not like KMail 3.2 is lacking in the new features department. It will come, just wait a bit.

This made Daniel apologize to KMail developers (while he didn't mean it as offence, apologizing never killed anyone whom i knew, so it was probably right thing to do). Here the thread ended, with angry Cornelius mumbling in the corner (or maybe he coped and forgiven Daniel and the others).

5. Deeper freeze [kde-core-devel]

11 Nov 2003 - 13 Nov 2003 (33 posts) Archive Link: "deeper freeze"

Summary By Peter Rockai (mornfall)

Topics: KDE 3.2

People: Stephan KulowRichard DaleIngo KlöckerRob KaperStephan KulowStefan RompfWaldo Bastian

Stephan Kulow, our well-known and well-loved release manager, announced:


The actual freeze didn't really work out as expected. The rate of reorganizing commits isn't really what it should be in this time of release schedule ;(

Starting with tomorrow I'd like to emphasize the release freeze even more in applying the following commit rules:

Starting with next monday (17.11) the extra rule applies:

So far I count 50 confirmed bugs >= major. Every other bug can wait for 3.2.1. We made excellent progress and KDE CVS is an excellent shape (if you look at the 50 bugs, you'll figure that most of them aren't new) - it just got some rough edges.

Everyone that isn't able to help with the big bugs I'd like to ask to test (e.g. move away your .kde for a moment and look at KDE as a user :) and/or send Lauri patches for updated docu (but avoid duplicated work and check http://people.fruitsalad.org/lauri/doc-patches/ before you start writing)

Greetings, Stephan

P.S. feedback and discussion welcome - I'm little disappointed   on the little feedback I get about the schedule.

Well, the bunch of replies in this flamewar^Wconstructive debate must have pleased Stephan. First to step forward was Richard Dale, with an question about kdebindings module: "Does this apply to the kdebindings module too? In the past I've regenerated the java bindings about a week or so before the final release. If I do it too early, it only needs one minor change in one kdelibs header to break the build, and the kdebindings list gets bug report mails. As far as I know there are no translation or artwork dependencies affecting the current JNI based java bindings." Stephan suggested sticking to schedule, while late header fixes would grant Richard right to change (regenerate) the affected bindings. Rob came with an idea of tagging branch, which was silently ignored. Richard agreed that it might indeed work this way and noted, that he would like to get rid of autogenerated stuff in cvs in a later release. In this same subthread, QtRuby was mentioned by Richard, who asked whether it might be possible to include them in 3.2.1. Stephen suggested releasing separately, as point releases are bugfix-only (and addition of whole new bindings can be hardly disguised as a bugfix, i think).

In another vein, Ingo (somewhat ironically) exclaimed: "So we can stop fixing crashes? Great news! :-p" . Stephen admitted, that crashes are hard to categorize and that it would depend on severity and frequency of crash and on the complexity of a fix. Rob was quick to object: "So the same rules no longer apply to all KDE applications?" , noting along the way that it would mean deeper freeze for less important applications and not-so-deep freeze for the really important ones (which seemed backwards to him). Stephan replied: "You mix up things. I didn't talk about importance of applications, but about importance of user data. I simpy do not consider a patience session as important as a mail folder." Rob reiterated his former arguments, adding that association between kmail and mail folder or patience game and patience session makes some applications inherently more important. Also, he made this interesting point:

From what I understood from the original mail, the problem is that freeze policies aren't respected. Changing policies won't solve the problem of people ignoring policies, especially not when adding restrictions based on subjective arguments.

If developers cannot fix minor bugs anymore, we'd actually punish those who don't have any outstanding major bugs, whether that definition inherits from "importance of user data" or not.

Stephen rebutted:

Yes. If you consider being forced to test the desktop instead of continuously patching it, punishing - then I punish you.

I don't know if you actually figured, but if you read kde-cvs, many of that little patches turn out to break another aspect or do not compile, or have to be discussed, etc. That's the way open source development (within KDE) works - just not a two weeks before scheduled release.

In response to Andras Mantia's reply, Stephan stated: "Well, stagnating is part of the release cycle. As I said: draw a line somewhere and stagnate on that level for some weeks. Not too long of course, but long enough to get a real overview how good it is. Currently it's more like "oh, you're using 16h hour old code, you better update."" . Waldo Bastian suggested adding another beta to catch regressions.

In another response to another Andras Mantia's post, Stephen explained: "If you read my words I was naming "how easy to fix and how likely it is to happen" as two other conditions for a crash beeing major. That means if app X crashes in obscure situations (and unlike what Rob said, there are obscure situations: "when I hit F5 very quickly", "when my installation is broken and X can't find the wallpaper" are just two examples) and the fix is a one liner "if (m_widget)" I'm fine with it. But e.g. in kmail there are some crashes that result from unclear object life times, were kmail may crash when you're spelling checking while the POP server goes down - whatever. That crash I wouldn't consider major - if the only solution is a rewrite of the kmail kernel." . That clarified the deeper freeze concept quite a bit.

In another subthread, Stefan Rompf asked about adding some optimizations for 3.2.1. Stephan Kulow explained, that point releases get very little testing and optimization is quite risky change (risky in sense of introducing bugs), so the change should be made to HEAD after 3.2 is branched, tested there and if working well, backported to BRANCH.

In yet another subthread, Andras asked about including one more complicated fix for Quanta+ in 3.2. The thread ended irresolutively however. I think this was solved by adding beta2 to schedule (see the section KDE 3.2 Schedule Altered in this issue for details).

6. KDE 3.2 Schedule Altered [kde-core-devel, kde-devel, kde-i18n-doc]

13 Nov 2003 (17 posts) Archive Link: "ANNOUNCE: another shift in 3.2 schedule"

Summary By Henrique Pinto

Topics: Development Plans, Release Schedule, KDE 3.2

People: Stephan KulowRob Kaper

Stephan Kulow announced:

Several points led to the conclusion that we can't keep the current schedule. I'd say "608 bugs opened in the last 7 days" is 'nough said, but there are other points too - one beeing that figured for myself that you can't have a happy life when working for 16 hours a day over two months.

So I'll tag a beta2 on 29th-30th and hope that most regressions are fixed till then. As I will stick to my vacation plans for december, I'd move the first release candidate towards 4th week '04.

The review rules I posted in the "deeper freeze" thread still apply till beta2 is _released_, after that I don't think it makes too much sense as many are on christmas vacation and reviewing won't happen that much. So I'd suggest to suspend the deep freeze between week 50 and 02 (still hoping for a white christmas in nothern germany :) and then start with the real deep freeze towards 3.2.0 at end in januray.

Please be still very conservative what you fix and what you leave in the bug database. Otherwise we'll never release.

And try to make beta2 as good as possible...

This was received without hassle. Rob Kaper stated that he would like a 3.1.5 release, but there were no responses.

In the kde-i18n-doc mailinglist, Kevin Donnelly asked for more time for the translations, what was granted by Stephan, who also recommended that some patches for the documentation that were being held until the final release were committed after beta2.

7. Kontact Bug Squashing Day [kde-pim]

13 Nov 2003 - 14 Nov 2003 (3 posts) Archive Link: "Kontact Bug Squashing Day on Sun, Nov 16"

Summary By Peter Rockai (mornfall)

Topics: Kontact, PIM, Bug Tracking

People: Cornelius SchumacherReinhold KainhoferMark Bucciarelli

Cornelius Schumacher posted this announcement to kde-pim and kmail mailing-lists:

This weekend on Sunday, November 16, from 00:00 UTC to 23:59 UTC we will hold a Kontact Bug Squashing Day in order to get Kontact into a good shape for the KDE 3.2 beta release. We will meet on IRC (channel #kontact at irc.kde.org) and together try to fix as many bugs as possible. A couple of core developers will be there which will allow us to quickly review patches sent to the kde-pim or kmail mailing lists.

If you would like to help us squashing the last ugly bugs of Kontact you can help us by:

Make sure that you have a current version of Kontact from the HEAD branch at hand, so that we are all working on the same state.

See you on Sunday on #kontact.

Two developers, Reinhold Kainhofer and Mark Bucciarelli announced they unfortunately couldn't attend. Mark expressed hope for another such Bug-Squashing day.

8. KMail: purpose of different Reply actions [kmail]

12 Nov 2003 - 14 Nov 2003 (6 posts) Archive Link: "Mailing list and reply-to."

Summary By Peter Rockai (mornfall)

Topics: KDE Tips, KMail

People: Paul SprakesIngo KlöckerIngo Klöcker

Paul Sprakes asked about (for him) confusing behaviour of different reply types in relation to setting 'Folder holds an mailing-list':


There seems to be some strangeness with mailing list folders and the automatic reply to address.

If I have the "folder holds a mailing list" option checked and have a value set for the mailing list adrress, then when I reply to a message the to box will contain the email originators address.

If I unset the option the mailing list address becomes ghosted out and replies still have the originators address set.

However if i reset the option, but this time delete the contents of the mailing list address field the replies will then have the mailing list address set.

The only way I can consistently get the correct "to" address is to right click the message header and select "Reply to mailing list" menu option.

Ingo explained the intended behaviour of different reply actions:

That's because the semantics of the different reply actions was changed. We have three reply actions.

Reply - This one should ideally address the reply to the sender of the message. Unfortunately it's difficult for KMail to find out whether the Reply-to was altered/set by the mailing-list software or whether the user set the Reply-to. After you had removed the mailing-list post address from the configuration KMail couldn't anymore detect that the Reply-to was set by the mailing-list software and therefore used this as recipient for the reply.

Reply All - Addresses the reply to the sender and all known recipients of the replied-to message. Should ideally put the sender of the replied-to message in the To: and all other recipients in the Cc: except for mailing-lists where (ideally) the mailing-list address is put in the To: and all other addresses are put in the Cc:

Reply to Mailing-List - Addresses the reply to the mailing-list.

So if you want to reply to a mailing-list message then use Reply to Mailing-List, i.e. by pressing 'l' (small L).

Paul somehow misunderstood the difference between reply and reply to mailing list, so he asked: "What I am confused about is that when the mailing list IS set in folder properties KMail doesn't seem to pick it up, but when I delete the address from folder properties it does (obviously from the mail headers)." and "I suppose what I'm expecting to happen is that KMail would know that I'm in a mailing list folder (because of the "Folder holds a mailing list" property) and would then try to use the post address from folder properties if one exists. However the only way I can get that behaviour is to delete the contents of "Post address" in folder properties." Ingo responded to this: "Most likely the mailing list message has the mailing-list address in the Reply-to header. Now if you told KMail the mailing-list address then KMail sees that the Reply-to header contains the mailing-list address and therefore uses the From address and not the Reply-to address as recipient for the reply. But if KMail doesn't know that the address in the Reply-to header is a mailing-list address then it uses this address as recipient for the reply. That explains the confusing behavior that you've noticed." and "No. You have to use "Reply to Mailing-List" if you want to reply to a mailing-list message." .

This should clarify the purpose of the different reply actions and illustrate what is the difference between them.







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.