After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 255428 - vfolders in no order in folder tree
vfolders in no order in folder tree
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
1.5.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 212600 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-03-10 18:07 UTC by Joe Shaw
Modified: 2013-09-10 14:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Joe Shaw 2004-03-10 18:07:11 UTC
This bug is somewhat related to bug 212600 and bug 255426.

The vfolders in the folder tree don't appear to be in any order whatsoever.  In 1.4.x and previous 
versions, they were sorted alphabetically.  Because of bug 255426, there doesn't appear to be any 
way to reorder them, and the order appears to be totally random because they're not in creation 
order (like they maybe should be, per bug 212600).  If the plan isn't to make them reorderable, 
then going back to the alphabetical order seems best.  It has become a real burden to manage 
my 70 vfolders because of this.
Comment 1 Not Zed 2004-03-11 07:08:02 UTC
ok, this is mostly fixed.

when inserting nodes in order, it was always prepending rather than
appending because of the sort function.

you can still get funny results if you move folders down the list,
because they're aren't moved in the vfolder editor, only renamed.

i.e. with
foo
bar
baz

rename foo to baz/foo

you'll get baz listed in the tree view above bar.  since the folders
become

baz/foo
bar
baz

but you can move them in the vfolder editor to fix this.  a better fix
will have to wait till we have a better vfolder editor.
Comment 2 Jeffrey Stedfast 2004-03-11 21:18:23 UTC
*** bug 212600 has been marked as a duplicate of this bug. ***