Sort contacts alphabetically

RESOLVED FIXED in 0.3b1

Status

Instantbird
Contacts window
--
enhancement
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: florian, Assigned: florian)

Tracking

Details

(Whiteboard: [0.3-wanted])

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

4 years ago
*** Original post on bio 343 at 2010-02-18 15:51:00 UTC ***

Most users probably expect buddies to be sorted alphabetically by default.

The current display order (recently connected buddies at the bottom of the list) should probably still be available (with a pref hidden in about:config?) for users who like being able to get quickly the answer to the question "who is connected that I haven't seen online today yet?"
(Assignee)

Updated

4 years ago
Whiteboard: [0.3-wanted]
*** Original post on bio 343 at 2011-02-02 22:05:43 UTC ***

I've spent some time on this today and the sorting works so far. Although it seems to have a performance problem on my (not so fast) computer despite doing a binary search for the correct place to insert when adding a new item (c.f. participants list on MUCs). Will post a patch tomorrow night (or later).

I think the other sort order can be achieved by making the sort function return a constant value all the time (sorting the new item to top or bottom of the list).
Assignee: nobody → benediktp
Status: NEW → ASSIGNED
*** Original post on bio 343 at 2011-02-03 04:42:50 UTC ***

(In reply to comment #1)
> I've spent some time on this today and the sorting works so far. Although it
> seems to have a performance problem on my (not so fast) computer despite doing
> a binary search for the correct place to insert when adding a new item (c.f.
> participants list on MUCs). Will post a patch tomorrow night (or later).
Performance when new buddies sign on or the initial time? If it's the initial time...we should be able to easily and quickly presort everyone.

Also is your binary search searching the DOM elements themselves or a parallel list? I think DOM access is always slower, so it might be best to find the proper placement in just an array and then use that information to place the element.

From performance problems would this need to be replaced w/ a tree as well (like the MUC participants list)?
*** Original post on bio 343 at 2011-02-03 08:16:32 UTC ***

(In reply to comment #2)
> (In reply to comment #1)
> > I've spent some time on this today and the sorting works so far. Although it
> > seems to have a performance problem on my (not so fast) computer despite doing
> > a binary search for the correct place to insert when adding a new item (c.f.
> > participants list on MUCs). Will post a patch tomorrow night (or later).
> Performance when new buddies sign on or the initial time? If it's the initial
> time...we should be able to easily and quickly presort everyone.

You mean getContacts should return a presorted list already? 
 (http://lxr.instantbird.org/instantbird/source/purple/purplexpcom/public/imIContactsService.idl#91, used from here http://lxr.instantbird.org/instantbird/source/instantbird/content/group.xml#71)
That would work if we didn't want the search order to change since we'd need to re-sort the buddy list anyways then.

> Also is your binary search searching the DOM elements themselves or a parallel
> list? I think DOM access is always slower, so it might be best to find the
> proper placement in just an array and then use that information to place the
> element.

I'm doing the search on an array at the moment, even though it contains DOM elements (the internal list kept by the group element). I thought it would be fine as long as I'm not using the DOM tree directly?
I could as well keep an array with only the buddy names as string and nothing else.

I also haven't addressed re-ordering elements at this point (e.g. because there was a rename or changed search order).

> From performance problems would this need to be replaced w/ a tree as well
> (like the MUC participants list)?

I though of this as well. There were some drawbacks, like not being able to use overlays and ugly ways to style the tree. The icon is not the big issue here, you only need an extra cell for that and have to return the image path via "getImageSrc" of the tree view for the approriate row/cell. Voila
(Assignee)

Comment 4

4 years ago
*** Original post on bio 343 at 2011-02-03 09:12:07 UTC ***

(In reply to comment #3)
> (In reply to comment #2)

> > From performance problems would this need to be replaced w/ a tree as well
> > (like the MUC participants list)?
> 
> I though of this as well. There were some drawbacks, like not being able to use
> overlays and ugly ways to style the tree.

The biggest problem (ie the reason it isn't a tree since 0.1) is you can't attach an XBL binding to a tree row.
Using a tree for the buddy list would kill almost all extensibility possibilities for the buddy list UI...
(Assignee)

Comment 5

4 years ago
*** Original post on bio 343 at 2011-04-14 22:38:55 UTC ***

(In reply to comment #0)

> The current display order (recently connected buddies at the bottom of the
> list) should probably still be available (with a pref hidden in about:config?)
> for users who like being able to get quickly the answer to the question "who is
> connected that I haven't seen online today yet?"

I changed my mind on this. I don't think the list of available contact is an acceptable UI to display recent activity. We could do much better with a specific "event history" view.
Assignee: benediktp → florian
Summary: Sort buddies alphabetically → Sort contacts alphabetically
(Assignee)

Comment 6

4 years ago
Created attachment 8352329 [details] [diff] [review]
WIP

*** Original post on bio 343 as attmnt 587 at 2011-04-14 22:42:00 UTC ***

Work in progress that doesn't support reordering yet.
I mean, reordering when the display name of a contact changes.

Reordering when the sort order changes is outside of the scope of this bug, and most likely not something we will have for 0.3.

I think another sort order we may want to implement later is 'sort by availability' (and then alphabetically amount the contacts of the same status).
That will be for a follow-up or an add-on.
(Assignee)

Comment 7

4 years ago
Created attachment 8352331 [details] [diff] [review]
WIP 2

*** Original post on bio 343 as attmnt 589 at 2011-04-15 14:47:00 UTC ***

Reordering when the display name changes is handled.
Not ready yet, as reordering should be prevented when a contact is selected/expanded, otherwise reordering buddies or aliasing can give really surprising results (the contact disappears immediately and reappears somewhere else).
(Assignee)

Comment 8

4 years ago
Comment on attachment 8352329 [details] [diff] [review]
WIP

*** Original change on bio 343 attmnt 587 at 2011-04-15 14:47:25 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8352329 - Attachment is obsolete: true
(Assignee)

Comment 9

4 years ago
Created attachment 8352332 [details] [diff] [review]
Patch v3

*** Original post on bio 343 as attmnt 590 at 2011-04-15 21:47:00 UTC ***

I think it's ready this time! :)
(Assignee)

Comment 10

4 years ago
Comment on attachment 8352331 [details] [diff] [review]
WIP 2

*** Original change on bio 343 attmnt 589 at 2011-04-15 21:47:33 UTC was without comment, so any subsequent comment numbers will be shifted ***
Attachment #8352331 - Attachment is obsolete: true
(Assignee)

Comment 11

4 years ago
*** Original post on bio 343 at 2011-04-15 23:20:02 UTC ***

https://hg.instantbird.org/instantbird/rev/a2e165a80dec
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.3b1
You need to log in before you can comment on or make changes to this bug.