Searched thrue bugzilla, but could not find this RFE... I wonder does only I need this? I want to being eble to sort my folder. What I mean is: Inbox | |-aaa |-bbb |-ccc Now they sort only alphabetical. But I would like to have the ccc at the top of all folders. This should work also in subfolders.

related to bug 140257?

No, this is about being able to sort all folders manually, as I would prefer...

*** Bug 253517 has been marked as a duplicate of this bug. ***

*** Bug 245672 has been marked as a duplicate of this bug. ***

Sorry, imho, it would be very useful feature becouse of the large quantity of multiple folders with different importance. Is this feature still developing?

*** Bug 328060 has been marked as a duplicate of this bug. ***

howdy y'all, [1] my tbird info ... Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.2) Gecko/20060308 Thunderbird/1.5.0.2 - Build ID: 2006030803 [2] REQUEST - change PRODUCT from "mozilla application suite" to "core". why? cuz the following tbird bug/rfes have been duped to this one ... - Provide means to manually order (sort) folders or groups https://bugzilla.mozilla.org/show_bug.cgi?id=245672 - Cannot order or sort newsgroups in alphabetical order https://bugzilla.mozilla.org/show_bug.cgi?id=251707 - Enh: Possebility to sort the newsgroup list in the navigation https://bugzilla.mozilla.org/show_bug.cgi?id=328060 [3] REQUEST - change OS and HARDWARE to "all". i really doubt this has any os or hardware dependency. [4] REQUEST - mark the following ... - Ability to rearrange the order of the folders within an account https://bugzilla.mozilla.org/show_bug.cgi?id=318467 ... as a dupe of this bug/rfe take care, lee

Moving bug to Core, as it also applies to Thunderbird. If this is wrong, then it needs to be forked into two versions. Gerv

(I'm presuming that to support this in Thunderbird or Mozilla Mail, the XUL tree widget would need to support reordering, and remembering the set order. Hence putting this bug into this component.) Gerv

I have a patch for the tree widget that adds support for ordinal attributes on treeitems. It's the same approach as ordinals in XUL boxes. The problem with folder pane is that it's not a content tree. It uses "dont-build-content" flag. Ordinals could be used to reorder accounts (different bug)

Jan: does that mean the problem is not solvable? The folder pane is usually not very large - a few hundred items, maybe. Would it be a bit performance hit to turn on content building? Gerv

(In reply to comment #11) > Jan: does that mean the problem is not solvable? > no, it doesn't > The folder pane is usually not very large - a few hundred items, maybe. Would > it be a bit performance hit to turn on content building? > > Gerv > It shouldn't be much slower, but it's quite painful to convert all the code and fix regressions.

Oh, I see - changing from dont-build-content to build-content changes the widget's interface? <sigh> Gerv

(In reply to comment #13) > Oh, I see - changing from dont-build-content to build-content changes the > widget's interface? > > basically, there's only one major difference var item = tree.view.getItemAtIndex(index) var id = item.id vs var resource = tree.view.getResourceAtIndex(index) var id = resource.Value

Jan, > I have a patch for the tree widget that adds support for ordinal attributes on > treeitems. Which bug is this?

(In reply to comment #15) > Jan, > > I have a patch for the tree widget that adds support for ordinal attributes on > > treeitems. > > Which bug is this? And did it land? Any progress on this?

> Created an attachment (id=282218) [details] > patch for trunk Jan, could you ask for a review (and update the patch if needed) ?

The patch works fine with current trunk.

Comment on attachment 282218 [details] [diff] [review] patch for trunk >@@ -1133,9 +1170,46 @@ > void > nsTreeContentView::Serialize(nsIContent* aContent, PRInt32 aParentIndex, PRInt32* aIndex, nsVoidArray& aRows) > { >+ nsAutoVoidArray elements; Instead of this complex code in Serialize, we should just use something like: struct ContentOrdinal { nsIContent* content; PRInt32 ordinal; PRBool operator< ... }; nsTArray<ContentOrdinal> arr(aContent->GetChildCount()); Then fill in the array, and call nsTArray's Sort method. This would be much simpler code and would need only one allocation. Or are you using custom sort code to ensure a stable sort? >@@ -1266,20 +1350,23 @@ > nsTreeUtils::GetImmediateChild(content, nsGkAtoms::treechildren, > getter_AddRefs(child)); > if (child) >- GetIndexInSubtree(child, aContent, aIndex); >+ GetIndexInSubtree(child, aContent, PR_FALSE, aIndex); So only top-level items support ordinals? >@@ -1368,7 +1455,7 @@ > > if (insertRow) { > PRInt32 index = 0; >- GetIndexInSubtree(aParent, aChild, &index); >+ GetIndexInSubtree(aParent, aChild, PR_TRUE, &index); We might want to consider speeding up the GetIndexInSubtree method by only checking ordinals (passsing PR_FALSE here) by caching a flag which indicates that any ordinals have been used. Also, AttributeChanged needs to be changed so that the tree is updated when an ordinal attribute changes.

(In reply to comment #24) > Or are you using custom sort code to ensure a stable sort? yes, quick sort is an unstable sort algorithm, I remember I fixed it this way in xul box code, too see nsBoxFrame::CheckBoxOrder() > So only top-level items support ordinals? no, it works in nested content too, I'll attach a new test case GetIndexInSubtree() is called only by InsertRowFor(). ordinals in nested content are not checked in this case because we sort only items in specific level. > > >@@ -1368,7 +1455,7 @@ > > > > if (insertRow) { > > PRInt32 index = 0; > >- GetIndexInSubtree(aParent, aChild, &index); > >+ GetIndexInSubtree(aParent, aChild, PR_TRUE, &index); > > We might want to consider speeding up the GetIndexInSubtree method by only > checking ordinals (passsing PR_FALSE here) by caching a flag which indicates > that any ordinals have been used. hmm, how would you know that any ordinals have been used. The method finds a correct index in a subtree to insert a new row. Ordinals are checked in that subtree. > > Also, AttributeChanged needs to be changed so that the tree is updated when an > ordinal attribute changes. > yeah, it shouldn't be hard to implement basically if an ordinal changes we need to remove row (with entire subtree) at old index and then insert it at new index. I would also call BeginUpdateBatch/EndUpdateBatch to prevent possible flashing, because RowCountChanged would be called twice.

added handling of ordinal attribute in AttributeChanged()

(In reply to comment #27) > Created an attachment (id=304756) [details] > updated patch > > added handling of ordinal attribute in AttributeChanged() > Well, even with a custom sort loop, we should still be able to use an nsTArray and avoid using the custom Element type and ChildIterator.

I don't feel automatic ordering is very useful un the folders panel. The ability to freely move the folders along the tree by hand (ooops, by mouse!) makes more sense. The same thing applies to the different accounts appearing into this pane. The user should decide how to group the sub/folders in every account. A fixed sorting rule will not fit the user's needs, mostly. Just my 50cents

Comment on attachment 304756 [details] [diff] [review] updated patch Patch has bitrotted - any chance of a new patch? $ patch -p0 --dry-run < ~/Desktop/0.diff patching file nsTreeContentView.cpp Hunk #3 succeeded at 908 (offset 9 lines). Hunk #4 FAILED at 1204. Hunk #5 FAILED at 1259. Hunk #6 succeeded at 1357 (offset 13 lines). Hunk #7 succeeded at 1376 (offset 13 lines). Hunk #8 FAILED at 1388. Hunk #9 succeeded at 1493 (offset 13 lines). Hunk #10 succeeded at 1659 (offset 13 lines). 3 out of 10 hunks FAILED -- saving rejects to file nsTreeContentView.cpp.rej patching file nsTreeContentView.h Hunk #1 succeeded at 99 with fuzz 2 (offset 7 lines). Hunk #2 succeeded at 128 (offset 7 lines).

(In reply to comment #2) > No, this is about being able to sort all folders manually, as I would prefer... https://addons.mozilla.org/en-US/thunderbird/addon/15102

Let's kick this enhancement into high gear for TB. This is very important for usability. In fact, it is a foundational design issue that must have been overlooked in the first stages of development. But it needs to be addressed now. Everyone wants to be able to change the sort order of folder, etc.. Being able to turn off the alpha sort might go a long way to making the thing work correctly. At least that would be a good start IMHO. Thanks all.

I don't think anyone is going to work on this given the plan to remove the XUL "tree" widget (bug 1446335).