Red Hat Bugzilla – Bug 176130
Create new folder dialog doesn't take the currently highlighted folder as the default
Last modified: 2007-11-30 17:07:22 EST
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):
Steps to Reproduce:
1. Right-Click on a folder in Evolution
2. Select "New Folder"
You have to select the folder under which to create the new folder.
The initially selected folder should be selected by default in the New Folder
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
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
This problem was also reported upstream:
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.