Version: 2.0.89 (using KDE 4.6.0) OS: Linux Adding new identities, receiving and sending accounts lacks consistency. In each of those cases the name of the entry is provided differently. "New identity" dialog takes the name in the first dialog, text entry is at the top of the dialog. "Receiving" account takes a name in the second dialog (first text entry), the input in the first dialog is a filter (and is at the top). "Sending" dialog takes the name in the first dialog, but for some reason it is below the type selection widget. It is also not required, so it's easy to miss and leave empty. It would be nice to have all those configuration dialog "feel" similar. They could all follow the same logic and flow - maybe all should have the name in the first dialog? Or all of them in the second. Also, the "name" text entry should be in the same place in all those dialogs. Also, renaming those entries works differently, either there is a separate 'rename' button, or it requires "modifying" the entry and changing the name inside the dialog. It would be nice to have it consistent. Now it feels messy. Reproducible: Always OS: Linux (x86_64) release 2.6.37-ARCH Compiler: gcc
Start to fix in : http://commits.kde.org/kdepimlibs/cc9a7f884748a9c4f46f465d2c3d96fa616a18fb now we must set name in transport
"Receiving" account takes a name in the second dialog (first text entry), the input in the first dialog is a filter (and is at the top). For the receiving we can't change it. Each resources has the same method to configure it. So we can fix it.
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.