Description of problem: If you have selected a folder, and then try to create a new folder, the selected folder is not the selected folder in the create new folder dialog. It's quite likely that anyone who selects a folder and then tries to create one expects that to be the default selected folder under which the new folder is to be created, so having to select it again is annoying and counterintuitive. Version-Release number of selected component (if applicable): evolution-2.0.2-25 How reproducible: Always Steps to Reproduce: 1. Right-Click on a folder in Evolution 2. Select "New Folder" Actual results: You have to select the folder under which to create the new folder. Expected results: The initially selected folder should be selected by default in the New Folder dialog. Additional info: I believe I saw this behavior in RHEL3's Evo, too. This might count as a feature request, rather than a bug. It's annoying, whatever it is.
Changing to note x86_64, but I suspect that this one is not specific to the viper I'm testing it on, nor specific to x86_64.
Works for me on my test x86_64 box, running RHEL4 U2 with evolution upgraded to evolution-2.0.2-25
Hmm. With further investigation, this appears to be only a problem if I've a top level folder like "On This Computer" selected and try to create a new folder. The subfolders of "On This Computer" seem to work fine if selected and then one tries to create a new folder, and I have verified that creating a folder under "On This Computer" does actually work (so it's not a result of the problem where it lets you try to create folders where you aren't actually able to do so).
Reproduced as you describe on RHEL4 U2; not a regression; reassigning as a RHEL4 bug.
This problem was also reported upstream: http://bugzilla.gnome.org/show_bug.cgi?id=339629 I investigated this some months ago and found that the problem does not appear trivial to fix as I had originally thought. It looks like it will involve changing libcamel in ways that may break its API. Since this bug was never proposed for a RHEL-4 update, I'm resolving this as UPSTREAM. Please refer to the upstream bug report for further updates.