Bug 176130 - Create new folder dialog doesn't take the currently highlighted folder as the default
Create new folder dialog doesn't take the currently highlighted folder as the...
Status: CLOSED UPSTREAM
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: evolution (Show other bugs)
4.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Matthew Barnes
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-19 12:49 EST by Suzanne Hillman
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-30 21:47:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 Desktop 339629 None None None Never

  None (edit)
Description Suzanne Hillman 2005-12-19 12:49:53 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):
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.
Comment 1 Suzanne Hillman 2005-12-19 13:49:37 EST
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-19 22:31:37 EST
Works for me on my test x86_64 box, running RHEL4 U2 with evolution upgraded to
evolution-2.0.2-25
Comment 3 Suzanne Hillman 2005-12-20 13:12:30 EST
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 17:19:15 EST
Reproduced as you describe on RHEL4 U2; not a regression; reassigning as a RHEL4
bug.
Comment 6 Matthew Barnes 2006-12-30 21:47:50 EST
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.

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