Bug 176130 - Create new folder dialog doesn't take the currently highlighted folder as the default
Summary: Create new folder dialog doesn't take the currently highlighted folder as the...
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: evolution   
(Show other bugs)
Version: 4.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
: ---
Assignee: Matthew Barnes
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-12-19 17:49 UTC by Suzanne Hillman
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-12-31 02:47:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 339629 None None None Never

Description Suzanne Hillman 2005-12-19 17:49:53 UTC
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):

How reproducible:

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

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.

Comment 1 Suzanne Hillman 2005-12-19 18:49:37 UTC
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.

Comment 2 Dave Malcolm 2005-12-20 03:31:37 UTC
Works for me on my test x86_64 box, running RHEL4 U2 with evolution upgraded to

Comment 3 Suzanne Hillman 2005-12-20 18:12:30 UTC
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).

Comment 4 Dave Malcolm 2005-12-20 22:19:15 UTC
Reproduced as you describe on RHEL4 U2; not a regression; reassigning as a RHEL4

Comment 6 Matthew Barnes 2006-12-31 02:47:50 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.