Version: 1.9.5 (using KDE KDE 3.5.5) Installed from: Compiled From Sources OS: Linux Using the Kmail email composer, when I enter a recipient in a recipient line, another recipient line automatically appears. Looking through Kmail's configuration options, this behavior does not seem to be configurable. If it is configurable, the configuration location is in an obfuscated location which would need to be fixed (it's not in the "Composer" section and does not appear to be anywhere else in "Configure KMail"). Some people call this a feature. However, there are several reasons it is a bug. First of all, and most importantly, it is not configurable. Second, the behavior gets in the user's way by adding something he has not requested and leaving less screen space for the actual message. Third, the vast majority of emails have only a single recipient line, so this behavior is annoying and not useful in the majority of cases. The expected behavior is that KMail would not automatically add new recipient lines, and that if it did, the option would be easy to disable from within KMail's existing configuration system.
We won't change this and we won't make it configurable. Use the source if you don't like it.
It is a shame that KMail does not have developers who are more interested in producing a useable piece of software. There is absolutely no reason not to make this option configurable and your decision violates the spirit of KDE. I hope this will be reconsidered in the near future.
I agree with Peter. I thought linux and KDE was all about choices and configurations... I can't see the meaning of a second recipient line to appear. I can enter all the email addresses on a single line. I don't need to look up the email addresses and hence don't need a second recipient line.
I have discovered something that could potentially lead to a fix, and along with it another bug. There is apparently still a configuration option called RecipientsEditorType, with the options Classic and MultiLine. 'Classic' appears to mean the editing mode found in older versions of KMail, in which there is one line for each of To, CC, and BCC and these lines can be individually enabled or disabled. 'MultiLine' is the new style and is apparently the default. The default seems to be set (at compile time) in the file kmail.kcfg in kdepim-3.5.5/kmail/ source directory, and there does not seem to be a way to configure the option at runtime. At this point it seems that it would be almost trivial to add an option to the cofniguration dialog for the Composer to set the editor mode. However, when the default is changed to 'Classic' in kmail.kcfg and kmail is recompiled, new bugs show themselves. When the composer is first opened, the labels for the From, To, CC, BCC, and Subject text boxes all display what looks like just the last part of a character on the left side and no actual whole words/letters (screenshots available if anyone requests it). When I disable To, CC, or BCC, using the View menu, the labels mostly reappear, except that "Blind copy to (BCC)" is too long to fit in the space provided and is cut off [this could be changed to just "BCC" and similarly for "CC"...]. However, when I re-enable the recipient line that I just disabled, its label is completely blank. If I disable the From line, on the other hand, the recipient line labels show up mostly correctly (see above about BCC label length), and the Subject label looks fine, and then after re-enabling the From line, it looks fine too. Similarly if the Subject line or the Mail Transport line is disabled.
You can configure the option at runtime by hand-editting ~/.kde/share/config/kmailrc. We won't add an option to the configuration dialog. @Bjørn: If you want to know what Free Software is about then please read http://www.gnu.org/philosophy/free-sw.html. KMail is Free Software, so you can change the source code to your delight and give it to everybody who wants it. OTOH we are free to decided what we want to do with KMail. So please respect our (freedom of) choice.
This bug still needs to be fixed, not ignored. Why would you tell me to hand-edit ~/.kde/share/config/kmailrc, when there's another bug that makes RecipientsEditorType=Classic there not work properly? Did you even try it yourself before you suggested it? As I said, setting RecipientsEditorType=Classic (this applies to kmailrc at runtime too, not just kmail.kcfg at compiletime) reveals another bug. The To/From/etc. labels on the left side do not show up. Instead there are just dots.
Note that the classic recipient editor is gone in KDE4, nobody had time to port it. And I can only repeat after Ingo: This option won't be added, a config option in the GUI to change "insert new recipient lines" would be way overkill. Closing as WONTFIX again, which means we will not implement this.
Well, as I mentioned before, the new editor functionality is annoying and it's sad that you won't fix it. No, it would NOT be overkill to add a config option in the GUI to disable an unpleasant aspect of the program. However, I brought up another aspect of the bug in my recent comments, and I would not have re-opened this report otherwise. As I stated, even when the correct line is in the config file to use the "Classic" editing style, kmail does not display it properly. Have you tested this yourself since my comment and seen what I'm talking about? Please do so, if you have not. It doesn't even draw the "To:" label correctly. To say that that shouldn't be fixed is absurd.
> As I stated, even when the correct line is in the config file to use the > "Classic" editing style, kmail does not display it properly. Have you > tested this yourself I have told you that the classic recipients editor has been removed, and thus this is no longer valid.
No, you said it is "gone in KDE4". It's not gone in KDE 3, which is what this bug report is about. In fact, the bug is present in the most recent version of KDE 3, 3.5.9, which was released after KDE 4.0.0. The fact that the feature is gone in KDE4 does not mean that a bug in KDE3 should not be fixed. They're completely separate branches.
Developers have clearly stated that they won't change this behaviour or add a configuration option. This is perfectly understandable as this is a feature - and useability does not mean making anything configureable.
Anyone who would say "useability does not mean making anything configureable" knows very little about usability. Configurability has everything to do with usability. Kmail is less usable with this bug. You are correct that the developers have clearly refused to fix this bug, but their software is worse for it.