Opened 9 years ago

Last modified 2 years ago

#10617 new plugin request

Option to group contacts by server

Reported by: stevendirocco Owned by: EionRobb
Milestone: Plugin Suggested Component: plugins
Version: 2.6.3 Keywords:


Right now, all my contacts from my workplace's XMPP server are mixed up with my GTalk contacts. Sometimes, the same person appears twice in the same group on two different protocols so I have to be extra careful to not send sensitive information over the internet.

I don't want this and I shouldn't have play janitor to rearrange them into separate groups.

I would like a setting somewhere to put contacts from a particular server into their own group.

Change History (15)

comment:1 Changed 9 years ago by deryni

  • Milestone set to Plugin Suggested
  • Type changed from defect to plugin request

This request is best implemented as a plugin. Currently we as Pidgin developers are not interested in implementing it. This ticket remains open as an invitation for someone to write a plugin fulfilling the request.
This is what groups are for as far as I'm concerned, and no you shouldn't have to do this now, they should have been added to appropriate groups when they were added (this is especially true if the work XMPP buddies are added by the server for you).

Also, as far as I'm aware as far as the buddy list is concerned usernames are opaque items (that is they don't have "server" bits). The buddy list can do status sorting, protocol sorting, account sorting, etc. but not anything more complicated than that (at least without the user/programmer telling pidgin how to "understand" usernames more, knowledge which a sorting method could certainly have). For example the Extended Buddy List Sort plugin (on the ThirdPartyPlugins page) supports sorting by name and protocol (among other things).

comment:2 Changed 8 years ago by dance

Well i have just came back to using Pidgin and i have to say you guys have made some major improvements and I will probably keep using it this time nice work guys.

The Account Soring seems to be the biggest drawback I see so far. A user should be able to organize the accounts at higher hierarchy in the buddy interface right now the highest hierarchy is group sorting which doesnt really work that great when you have like 2 thousand contacts you are trying to sort. And im sure other users have alot of contacts seeing to can combine all im programs in one. So from a organizing stand point you should be able to seperate the clutter of contacts by accounts.

Here is example of what im trying to explain:

MSN (Account)
----Friends (group)
----Co-Workers (group)
----DevGroup (group)
AIM (Account)
----New Buddy (group)
----Buddies (group)
----Recent Buddies (group)
ICQ (Account)
----Friends (group)
----Not Friends (group)
----Dev Friends (group)
Facebook (Account)
----Family (group)
----Work (group)
----Friends (group)

Also i added the "Extended BList Sort" by Konrad and tested it out and it is sorting at a even lower level in the buddy hierarchy. When someone on his site asked him about group sorting his reply was "Pidgin doesn’t even call my sort function when adding groups to the buddy list. So yes, it seems to be impossible. Maybe it is possible through some weird hacks, don’t know."

By no means is this meant for complaining/critizing just a suggestion for improving on the already good work you guys have done so far on you alls strive to perfection.

comment:3 Changed 8 years ago by dance

Just installed Skype API and it actually worked like it is suppose too at least somewhat so I know it is possible. In the buddy list it shows Skype as being the parent in the hierarchy but of course it did not import my groups. But that might be apart of the major bug with the Skype API not being able to have Skype app closed while using it in

comment:4 Changed 8 years ago by dance

Also noticed that in the Facebook plugin that the groups and buddies just appear out of nowhere when someone comes online in Facebook. I know that this issue is not directly associated with the account sorting. But it seems logical that if there was a account hierarchy in the buddy display than things like this could be better dealt with in the code itself to allow for some kind of standards in the buddy display.

Is this the way the buddy display it is suppose to work when handling so many different accounts or is it just the best soulution for now just curious?

comment:5 Changed 8 years ago by hansfn

This has turned into a big problem for me too now that Facebook opened up it's Chat as a normal XMPP service. Suddenly all my Facebook friend lists are groups in Pidgin. (What a mess.) Are you (devs) still not interested in this - we just need a group hierarchy as suggested above.

Thx for a great product, by the way.

comment:6 Changed 8 years ago by dance

Yeah i really wanted to stay with Pidgin this time but maybe ill be back for Version 3.0...But for now going to stick with Trillian seems to be working for what i need it to do.

comment:7 Changed 8 years ago by rekkanoryo

We are still not interested in such group hierarchies.

comment:8 Changed 8 years ago by darkrain42

You can, for the record, select only some groups (on Facebook's website) to which to appear online, and only those groups will appear in an XMPP client (i.e. Pidgin).

comment:9 Changed 8 years ago by dance

But we are interested in group hierarchies...are you not making Pidgin for us the users??? I would understand "you all's" decision more if it where a matter of not having the knowledge or skills to make a program flexable enough to meet the needs of its users versus "not interested". But if this is going to be the attitude of Pidgin developers "not interested" in the features we the users request then im "not interested" in using Pidgin any longer...

comment:10 Changed 8 years ago by deryni

No protocol that I'm aware of actually supports nested groups, which makes any such display client-side only (as well as not carrying over between instances of the client), which makes the feature somewhat less useful than it might otherwise be. Not to mention how that complicates actually storing the buddies on the server (which group should they actually be in, most protocols require buddies to be in some group or other).

Nested groups add, as far as I can see, approximately one thing over uniquely named groups (MSN - Friends, AIM - Friends, etc.) and that would be the ability to collapse the nesting group to hide all the nested groups, and that is a rather small feature for the price in complexity they would require to do as anything beyond being purely a sorting mechanism.

finch supports the pure sorting version of this sort of thing, we just don't think it makes sense in pidgin.

I do, however, still maintain that we should make it easier to replace just the buddy list tree view component in the pidgin Buddy List window (without needing to implement the rest of the Buddy List window's features).

Oh and for the record, when you get something for free you don't really have the right to "demand" that whoever gave it to you give you something else instead. You are free to not use pidgin if it doesn't meet your needs the same way we are free not to implement anything we don't want to implement. So, if this feature is vital to your usage and you absolutely cannot live without it (and do not want to use finch or the unique group name workaround) then good luck using the client which gives you what you want, I hope it makes you happy.

comment:11 Changed 8 years ago by stevendirocco

I don't think it is correct to conflate this request with a request for nested groups. The groupings I asked for here are groupings based on the contact's server (which I hope the client would know) and not any server-side information. If there is to be a discussion about arbitrarily-named nested groups then it should happen on another ticket.

Even having group names be displayed and sorted with their protocol (or server in the case of XMPP) prepended such as "MSN - Friends", " - Waterloo", and " - Buddies" would be enough to resolve this ticket.

Also, I think this kind of representation shouldn't be trivialized as a "sorting mechanism". As I mentioned before, clicking on the wrong protocol can send sensitive information over the internet instead of an intranet.

There are also significant reliability issues in messaging someone over a browser-based interface like facebook or gmail instead of protocols that are typically accessed using dedicated clients like MSN and AIM; namely, how do you know the person you're messaging won't close the browser window before noticing your message.

comment:12 Changed 8 years ago by deryni

Taking your comments out of order.

You have no more guarantees that they will see your message in a dedicated client than you do in an web browser. Closing windows happens in both, crashes happen the same to both, power outages happen the same to both, transient network issues blocking the message from getting through happen to both, etc. so that argument is weak at best.

I apologize for failing to notice that the nested groups discussion was not the original discussion, that's what I get for jumping back in half-way.

As a design decision pidgin has intentionally abstracted away the requirement to know what protocol the other person is using. So features that bring that back to prominence are not generally things we are interested in. I stand by the statement that this sort of thing really is a sorting issue, the fact that you want them sorted at the group display level as opposed to within a single displayed group entry is a detail not a core difference.

You are entirely free to name your groups however you see fit (including with network/server/protocol tags) though that would cause them to show up as such in other clients obviously (and I imagine some restrictive servers may not actually allow that, I know Facebook does not for instance).

I do not believe a buddy list sorting plugin can affect the displayed names of groups (at least in pidgin, it may be possible in finch I'm not sure). I don't believe they can affect the names of buddy entries either at least officially (though I'm less certain about this).

Furthermore, as a result of the volume of the response we got when we originally removed the protocol icons from the buddy list (and almost entirely because someone wrote a patch for it) the buddy list has an option to display the protocol icon of a buddy list entry (which while not entirely the same as what you asked for is related and may help).

I'm more than happy to discuss this issue further if there is more to discuss as well as more than happy to provide help for enabling solutions to this to be implemented (extending the buddy list sorting plugins to encompass the entire buddy list as opposed to functioning just group-internally for example).

comment:13 in reply to: ↑ description Changed 6 years ago by garsan


Any update on this?


comment:14 Changed 5 years ago by rekkanoryo

  • Owner changed from rekkanoryo to EionRobb

comment:15 Changed 2 years ago by dx

  • Component changed from unclassified to plugins
Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!