Opened 11 years ago

Last modified 8 years ago

#5876 new patch

ability to hide away/idle buddies as well as mobile buddies

Reported by: sumitk Owned by: deryni
Milestone: Patches Needing Improvement Component: pidgin (gtk)
Version: 2.4.2 Keywords:
Cc: jviggiano, justineatworld, chaddaniels, boydster2000, cphuntington97, spidey3, sumitk

Description

patch to allow users to show all away buddies or select ones. Option added under Buddies/show as "Away Buddies". Away buddies includes idle, away and mobile buddies.

This will close Ticket #4112.

Thanks, Sumit Agrawal

Attachments (8)

hideaway.patch (18.1 KB) - added by sumitk 11 years ago.
hideaway_nocore.patch (12.9 KB) - added by sumitk 11 years ago.
hideoffline.JPG (9.6 KB) - added by justineatworld 11 years ago.
List of statuses that can be considered "offline" and hidden
hidemobile_nocore.patch (12.8 KB) - added by adk 11 years ago.
simple mod of original plugin to only hide mobile contacts
configure_inactive.png (21.9 KB) - added by sumitk 11 years ago.
hide_away_final.patch (13.2 KB) - added by sumitk 11 years ago.
hide_inactive.c (10.5 KB) - added by sumitk 11 years ago.
Hide Inactive buddies plugin
hide_away_patch.2.5.3.patch (9.8 KB) - added by sumitk 10 years ago.

Download all attachments as: .zip

Change History (71)

Changed 11 years ago by sumitk

comment:1 Changed 11 years ago by rlaager

  • Cc jviggiano justineatworld chaddaniels boydster2000 cphuntington97 spidey3 added
  • Keywords path for Ticket #4112 removed
  • Milestone set to Patches Needing Improvement

Thanks for the patch. I haven't tested it, but in general, it looks well done. However, this patch adds a bunch of API. While that's not inherently bad, I think we can simplify this patch some and reduce a bunch of it:

  1. purple_blist_node_get_bool_with_default() wouldn't be necessary if you flipped that from "show_away" to "hide_away" and flipped the logic related to it.
  1. I'm concerned about the, purple_presence_is_away(), purple_status_is_away(), and purple_status_type_is_away() functions. You're checking for a primitive of PURPLE_STATUS_AWAY. I haven't tested this, but doesn't that mean that someone who is "Extended Away" would not count as as away here?

Instead, could you replace calls to purple_presence_is_away() with !purple_presence_is_available()?

  1. Is it really necessary to allow people to show certain buddies when they're away but this option is on? If so, why? Are those people going to be the same ones you would want to see when they're offline? If so, then those options can be merged.

comment:2 follow-up: Changed 11 years ago by sumitk

  1. purple_blist_node_get_bool_with_default() wouldn't be necessary if you flipped that from "show_away" to "hide_away" and flipped the logic related to it.

Isn't that a missing/needed API anyway? Give an option on what should be the return value in case key(string) is not found ??

neway, I can get rid of that API if you really think its not needed.

  1. I'm concerned about the, purple_presence_is_away(), purple_status_is_away(), and purple_status_type_is_away() functions. You're checking for a primitive of PURPLE_STATUS_AWAY. I haven't tested this, but doesn't that mean that someone who is "Extended Away" would not count as as away here?

    You are right. Should be in.

Instead, could you replace calls to purple_presence_is_away() with !purple_presence_is_available()?

I think offline, invisible, dnd will fall in !available. More, I think there is a need for this API.

  1. Is it really necessary to allow people to show certain buddies when they're away but this option is on? If so, why? Are those people going to be the same ones you would want to see when they're offline? If so, then those options can be merged.

Think of this case - "set idle when away for n mins" setting is on. But actually buddy is there. (people working on desktop machines and signed on laptop next to them can set them away after 'n' minutes but actually there are there) but may not want to display if he is offline.

You know people may be in as away (not invisible) and answer some urgent stuffs. What's you think ?

comment:3 in reply to: ↑ 2 ; follow-up: Changed 11 years ago by rlaager

First off, when replying, the previous text should be marked with brackets, not your text.

Replying to sumitk:

  1. purple_blist_node_get_bool_with_default() wouldn't be necessary if you flipped that from "show_away" to "hide_away" and flipped the logic related to it.

Isn't that a missing/needed API anyway? Give an option on what should be the return value in case key(string) is not found ??

neway, I can get rid of that API if you really think its not needed.

I'm not sure what to say about this. I could go either way on it.

  1. I'm concerned about the, purple_presence_is_away(), purple_status_is_away(), and purple_status_type_is_away() functions. You're checking for a primitive of PURPLE_STATUS_AWAY. I haven't tested this, but doesn't that mean that someone who is "Extended Away" would not count as as away here?

You are right. Should be in.

Instead, could you replace calls to purple_presence_is_away() with !purple_presence_is_available()?

I think offline, invisible, dnd will fall in !available. More, I think there is a need for this API.

You can't tell if someone is invisible, so that's rather irrelevant, but see my next point. If you're ignoring people who are away because they're not available to chat, why wouldn't you want to ignore people who are busy as well? You're right about offline. So what about this logic:

if (purple_status_is_online() && !purple_presence_is_available()

  1. Is it really necessary to allow people to show certain buddies when they're away but this option is on? If so, why? Are those people going to be the same ones you would want to see when they're offline? If so, then those options can be merged.

Think of this case - "set idle when away for n mins" setting is on. But actually buddy is there. (people working on desktop machines and signed on laptop next to them can set them away after 'n' minutes but actually there are there) but may not want to display if he is offline.

Yeah, you're right. Here's another example: A lot of people set themselves to Away to trick people into not IMing them, but the people they communicate with a lot know it's a bogus status.

comment:4 in reply to: ↑ 3 Changed 11 years ago by sumitk

Replying to rlaager:

First off, when replying, the previous text should be marked with brackets, not your text.

Replying to sumitk:

  1. purple_blist_node_get_bool_with_default() wouldn't be necessary if you flipped that from "show_away" to "hide_away" and flipped the logic related to it.

Isn't that a missing/needed API anyway? Give an option on what should be the return value in case key(string) is not found ??

neway, I can get rid of that API if you really think its not needed.

I'm not sure what to say about this. I could go either way on it.

  1. I'm concerned about the, purple_presence_is_away(), purple_status_is_away(), and purple_status_type_is_away() functions. You're checking for a primitive of PURPLE_STATUS_AWAY. I haven't tested this, but doesn't that mean that someone who is "Extended Away" would not count as as away here?

You are right. Should be in.

Instead, could you replace calls to purple_presence_is_away() with !purple_presence_is_available()?

I think offline, invisible, dnd will fall in !available. More, I think there is a need for this API.

You can't tell if someone is invisible, so that's rather irrelevant, but see my next point. If you're ignoring people who are away because they're not available to chat, why wouldn't you want to ignore people who are busy as well? You're right about offline. So what about this logic:

if (purple_status_is_online() && !purple_presence_is_available()

dnd is mostly set to avoid unnecessary traffic. To me, DND can be violated if really needed. What's say ? {If I don't want anyone to talk to me, why am I here ?)

  1. Is it really necessary to allow people to show certain buddies when they're away but this option is on? If so, why? Are those people going to be the same ones you would want to see when they're offline? If so, then those options can be merged.

Think of this case - "set idle when away for n mins" setting is on. But actually buddy is there. (people working on desktop machines and signed on laptop next to them can set them away after 'n' minutes but actually there are there) but may not want to display if he is offline.

Yeah, you're right. Here's another example: A lot of people set themselves to Away to trick people into not IMing them, but the people they communicate with a lot know it's a bogus status.

comment:5 follow-up: Changed 11 years ago by sadrul

I think something like a FinchBlistManager (http://developer.pidgin.im/doxygen/dev/html/structFinchBlistManager.html) would be useful for Pidgin too (except 'find_parent', perhaps). That would allow plugins to determine whether to show a particular blist-node or not with finer granularity (with the current behaviour as the default, of course). So there could be a plugin that could hide idle buddies, away buddies (for its own definition of 'away'ness), idle or away buddies, mobile buddies, buddies who are not listening to any songs etc. etc.

Thoughts?

About the API additions: some of them (e.g. purple_blist_get_non_away_online_count) look very special purpose, and doesn't need to be in the API at all. (also, you may want to look at purple_blist_node_next).

purple_blist_node_get_bool_with_default looks like a good idea (the documentation for it is not quite correct, though ;) ). We should probably have those for _get_int and _get_string too. Perhaps there should also be a 'purple_blist_node_has_setting' to check whether a particular setting is set for a blistnode. Or it could return a PurpleValue? for the setting (NULL when none is set). That would help in pref-migration if the type of a setting is changed.

purple_presence_away doesn't look all that good (especially with the weird include-parameters). I agree with rlaager that checking for online and !available should do.

comment:6 in reply to: ↑ 5 Changed 11 years ago by sumitk

Replying to sadrul:

I think something like a FinchBlistManager (http://developer.pidgin.im/doxygen/dev/html/structFinchBlistManager.html) would be useful for Pidgin too (except 'find_parent', perhaps). That would allow plugins to determine whether to show a particular blist-node or not with finer granularity (with the current behaviour as the default, of course). So there could be a plugin that could hide idle buddies, away buddies (for its own definition of 'away'ness), idle or away buddies, mobile buddies, buddies who are not listening to any songs etc. etc.

Thoughts?

About the API additions: some of them (e.g. purple_blist_get_non_away_online_count) look very special purpose, and doesn't need to be in the API at all. (also, you may want to look at purple_blist_node_next).

Will remove them as API.

purple_blist_node_get_bool_with_default looks like a good idea (the documentation for it is not quite correct, though ;) ). We should probably have those for _get_int and _get_string too. Perhaps there should also be a 'purple_blist_node_has_setting' to check whether a particular setting is set for a blistnode. Or it could return a PurpleValue? for the setting (NULL when none is set). That would help in pref-migration if the type of a setting is changed.

purple_presence_away doesn't look all that good (especially with the weird include-parameters).

Yeah, I know. Will clean those API's. (remove those include-params)

I agree with rlaager that checking for online and !available should do.

Still, I am thinking that this will also hide dnd buddies and will not be able to differ b/w "dnd" and away. (if I set show when away for that buddy, buddy will be displayed when he is dnd as well as when away). What do you say ??

comment:7 follow-up: Changed 11 years ago by rlaager

I'm not sure that we need to differentiate between DND and away. Do you have a lot of buddies who use both DND and away regularly that you'd want to talk to when they're set to DND, but not when they're away?

comment:8 in reply to: ↑ 7 ; follow-up: Changed 11 years ago by sumitk

Replying to rlaager:

I'm not sure that we need to differentiate between DND and away.

Do you have a lot of buddies who use both DND and away regularly that you'd want to talk to when they're set to DND, but not when they're away?

Indeed, that is it.

People sets dnd to avoid unnecessary traffic mainly during working time or busy time but answers good/needed query. For ex: I don't want a popup "What's up ?" if I am busy, but can answer "Have you done that feature? or can you help me with gtk ?"

comment:9 Changed 11 years ago by adk

Also, should there be an option to only hide mobile buddies too? (maybe not lumping mobile in with away/idle?) I find myself wanting to show people who are away/idle but not those who are mobile, because I never end up concerning myself with those on their mobile devices (they usually dont answer anyways, at least in my case)

comment:10 Changed 11 years ago by rlaager

adk: That seems like quite the corner case. You're talking about having a lot of people who fake away that you want to talk to as well as a lot of people who have configured themselves to show up when mobile that don't respond to you when mobile but do when they're not mobile so that you have them on your buddy list. I don't think that adding an option for this is worth it.

If you have specific people that pretend to be away, you could override them and then use the hide feature (both from this patch). If you have a ton of people that do that, then you can probably just ignore the mobile ones like you're doing now.

comment:11 in reply to: ↑ 8 ; follow-up: Changed 11 years ago by rlaager

Replying to sumitk:

People sets dnd to avoid unnecessary traffic mainly during working time or busy time but answers good/needed query. For ex: I don't want a popup "What's up ?" if I am busy, but can answer "Have you done that feature? or can you help me with gtk ?"

I see the point. You could still check for this in the UI, though. I'm not so sure I want to add more functions to the core for something that is clearly a UI decision.

comment:12 follow-up: Changed 11 years ago by adk

That seems like quite the corner case. You're talking about having a lot of people who fake away >that you want to talk to as well as a lot of people who have configured themselves to show up >when mobile that don't respond to you when mobile but do when they're not mobile so that you have >them on your buddy list. I don't think that adding an option for this is worth it.

I can see where you're coming from, I was more talking about the fact I still like to see away messages that people might have but mobile contacts almost never mark themselves away, For the time being, i'm using a modified version of the patch that I made to do what I wanted, so, even if you guys dont want to put an option in because it isnt widely desired, I can understand that, thanks.

comment:13 in reply to: ↑ 11 Changed 11 years ago by sumitk

Replying to rlaager:

Replying to sumitk:

People sets dnd to avoid unnecessary traffic mainly during working time or busy time but answers good/needed query. For ex: I don't want a popup "What's up ?" if I am busy, but can answer "Have you done that feature? or can you help me with gtk ?"

I see the point. You could still check for this in the UI, though. I'm not so sure I want to add more functions to the core for something that is clearly a UI decision.

Well I think core should be updated as and when required and when new stuff fit in core definition. (also to remove duplicates things in around core stuff)

Anyway I don't think we should discuss it more, So here is the patch. (hideaway_nocore.patch)

Changed 11 years ago by sumitk

comment:14 in reply to: ↑ 12 Changed 11 years ago by pdredsox5

Replying to adk:

I can see where you're coming from, I was more talking about the fact I still like to see away messages that people might have but mobile contacts almost never mark themselves away, For the time being, i'm using a modified version of the patch that I made to do what I wanted, so, even if you guys dont want to put an option in because it isnt widely desired, I can understand that, thanks.

Would it be possible to get that modified patch? I'm in the same boat as you with just wanting to hide mobile buddies. Thanks!

comment:15 Changed 11 years ago by justineatworld

I first proposed this change back with ticket 1519 (http://developer.pidgin.im/ticket/1519) and one of the biggest goals of the patch was to be able to hide mobile contacts. Miranda has a great, simple implementation that I think deserves to be looked at where there is a ticker that says "hide inactive" and then check boxes that allow the user to define what "inactive" means. You can check off away, idle, mobile, available, and more. I think that for simplicity's sake, the option to hide away, idle, and mobile contacts are all that is necessary.

I'll attach a screen shot in a second.

Changed 11 years ago by justineatworld

List of statuses that can be considered "offline" and hidden

comment:16 follow-up: Changed 11 years ago by adk

I think that for simplicity's sake, the option to hide away, idle, and mobile contacts are all >that is necessary.

Definitely, if i end up posting my modified version it would need to be cleaned up, I will do that if people want me to, but I really like that idea you just showed us in that screenshot even better, do you have the patch for that? is it on the previous ticket?

comment:17 in reply to: ↑ 16 ; follow-up: Changed 11 years ago by justineatworld

do you have the patch for that? is it on the previous ticket?

I had one in development when my HD crashed, but based on the patch you have posted here it doesn't look like too much work to clean it up to entry standards. If I get a chance I'll take a look again, but for now you seem like you've got this way under control

comment:18 in reply to: ↑ 17 ; follow-up: Changed 11 years ago by adk

Replying to justineatworld:

do you have the patch for that? is it on the previous ticket?

I had one in development when my HD crashed, but based on the patch you have posted here it doesn't look like too much work to clean it up to entry standards. If I get a chance I'll take a look again, but for now you seem like you've got this way under control

oh no thats not what i meant, I was talking about a patch i have not posted, that isnt mine, I modified his patch to just allow people to hide mobile buddies

comment:19 in reply to: ↑ 18 ; follow-ups: Changed 11 years ago by justineatworld

I got it, but the patch posted on this ticket by Sumit is the only one I know to be publically available with these features. I assume you just modified his patch by erasing the code that stops blist from including away and idle buddies. If instead you could take that code and wrap it in an if statement conditional on check boxes like the image I posted, this patch would be essentially complete. My knowledge of pidgin libraries is minimal, so I can only propose ideas, not impliment them :(

comment:20 in reply to: ↑ 19 Changed 11 years ago by adk

Replying to justineatworld:

I got it, but the patch posted on this ticket by Sumit is the only one I know to be publically available with these features. I assume you just modified his patch by erasing the code that stops blist from including away and idle buddies. If instead you could take that code and wrap it in an if statement conditional on check boxes like the image I posted, this patch would be essentially complete. My knowledge of pidgin libraries is minimal, so I can only propose ideas, not impliment them :(

sort of, the patch included actually a boolean argument in one of the functions for includeidle, and it passed TRUE to that by default, I changed that and removed the part about including away buddies, theres a function in there to determine if a presence is an "away" buddy or not, modifying that allowed me to make it so that only mobile buddies fell into this category, im trying to learn about the pidgin libraries myself at the moment, so, when i get time, Ill try and clean the modifications up and have it make sense as best i can

comment:21 Changed 11 years ago by adk

here is a slight modification of his patch, it is not all that different than the original, just providing it because people requested a modification to just hide mobile contacts, feel free to comment and/or clean it up =]

Changed 11 years ago by adk

simple mod of original plugin to only hide mobile contacts

comment:22 in reply to: ↑ 19 Changed 11 years ago by sumitk

Replying to justineatworld:

I got it, but the patch posted on this ticket by Sumit is the only one I know to be publically available with these features. I assume you just modified his patch by erasing the code that stops blist from including away and idle buddies. If instead you could take that code and wrap it in an if statement conditional on check boxes like the image I posted, this patch would be essentially complete. My knowledge of pidgin libraries is minimal, so I can only propose ideas, not impliment them :(

I think it would be good to have a plugin to configure the kind of nactive buddies (see bitmap - configure_inactive.png) and logic to hide inactive buddies in core and plugin notifies to configure blist using purple_signal. What's say ?

Changed 11 years ago by sumitk

comment:23 Changed 11 years ago by AaronCompNetSys

Ping to get a owner on this one please - very useful for cooperate XMPP. Thanks.

comment:24 Changed 11 years ago by AaronCompNetSys

Ping again? Doesn't the lack of this feature annoy the crap out of anyone else? Pretty please, sorry I'm of no help myself.

comment:25 follow-up: Changed 11 years ago by rlaager

I'm finally getting back to looking at this. Looking at sumitk's hideaway_nocore.patch, I think we're on the right track. However, I see the following issues at a quick glance:

  1. It uses comments. Those should be replaced with /* */ style comments, which is trivial.
  1. Why are you checking for PURPLE_BLIST_NODE_FLAG_NO_SAVE? What does that accomplish? (I'm not saying it's not useful, just that I'm suspicious and would like to know the rationale behind it being there.)
  1. This one is longer:

In the function to set show_away (gtk_blist_menu_showaway_cb), you're setting show_away recursively on groups and contacts. This is wrong, because if you move/add a buddy to that contact or group, it won't have the setting set the way you'd expect.

I doubt it's useful to be able to show an entire group's contacts when away, so that can probably be ignored and no such option shown on groups. For buddies vs. contacts, is it useful to override this on the buddy level? I'd guess it's probably not. So, unless someone has a good use case to the contrary, I think this should be limited to the contact level.

Thus, you'd only show the right-click option on contacts or collapsed primary buddies. (The "Set Custom Icon" option might be a good example for you to look at in this respect.) In any case, when the callback is called, you'd check to see if it's buddy or contact, and set it on the contact. (So if it's a buddy, you set it on that buddy's contact, otherwise you set it on the contact directly.)

comment:26 in reply to: ↑ 25 Changed 11 years ago by sumitk

Replying to rlaager:

I'm finally getting back to looking at this. Looking at sumitk's hideaway_nocore.patch, I think we're on the right track. However, I see the following issues at a quick glance:

  1. It uses comments. Those should be replaced with /* */ style comments, which is trivial.
  1. Why are you checking for PURPLE_BLIST_NODE_FLAG_NO_SAVE? What does that accomplish? (I'm not saying it's not useful, just that I'm suspicious and would like to know the rationale behind it being there.)
  1. This one is longer:

In the function to set show_away (gtk_blist_menu_showaway_cb), you're setting show_away recursively on groups and contacts. This is wrong, because if you move/add a buddy to that contact or group, it won't have the setting set the way you'd expect.

I doubt it's useful to be able to show an entire group's contacts when away, so that can probably be ignored and no such option shown on groups. For buddies vs. contacts, is it useful to override this on the buddy level? I'd guess it's probably not. So, unless someone has a good use case to the contrary, I think this should be limited to the contact level.

Thus, you'd only show the right-click option on contacts or collapsed primary buddies. (The "Set Custom Icon" option might be a good example for you to look at in this respect.) In any case, when the callback is called, you'd check to see if it's buddy or contact, and set it on the contact. (So if it's a buddy, you set it on that buddy's contact, otherwise you set it on the contact directly.)

Patch that I am using is for the snapshot I uploaded last. (a plugin to allow hiding and changes in pidgin to allow doing that)

Take a look at it. I have updated my patch to include your comments.

  1. No probs. Done.
  2. I have no idea, I used the same as it done for other options ;-)
  3. Agreed, included in the patch.

Take a look at hide_away_final.patch & hide_inactive.c (plugin)

Changed 11 years ago by sumitk

Changed 11 years ago by sumitk

Hide Inactive buddies plugin

comment:27 Changed 11 years ago by spidey3

What's happening with this? I was really hoping to see it in 2.5.2...

To the patch developer: Is there a win32 plugin dll which I can try out? I love being a guinea pig :)

Spidey!!!

comment:28 Changed 11 years ago by AaronCompNetSys

Try out from sumitk: http://code.google.com/p/mypidgin/downloads/list

Thank you sumitk for your work.

comment:29 follow-up: Changed 10 years ago by sumitk

What's the status? Anyone looking on to include in next release (2.5.3 is out) or anything to improve?

comment:30 Changed 10 years ago by AaronCompNetSys

[Self censored comment of my own rage about other bugs fixed in 2.5.3 but not this one] Re-installed sumitk's build.

comment:31 follow-up: Changed 10 years ago by deryni

From a quick look at the patch my only concern is that it doesn't seem to migrate the existing preferences to the new names, which means that people will lose the 'show offline' flag for buddies, and the 'Show Offline' preference for the buddy list.

comment:32 in reply to: ↑ 29 Changed 10 years ago by rekkanoryo

Replying to sumitk:

What's the status? Anyone looking on to include in next release (2.5.3 is out) or anything to improve?


This patch has been marked as needing improvement. Until Richard reviews the patch again, it will sit.

comment:33 in reply to: ↑ 31 ; follow-up: Changed 10 years ago by sumitk

Replying to deryni:

From a quick look at the patch my only concern is that it doesn't seem to migrate the existing preferences to the new names, which means that people will lose the 'show offline' flag for buddies, and the 'Show Offline' preference for the buddy list.

Yes, migration is missing. I'll fix that.

Is there anything like post-install scripts here which can do this? or do we do these kind of stuff on every run time? If its on run time, what should be correct place -- blist callbacks or something like purple_blist_load (or gtkmain) ?

Any pointer would be appreciated.

comment:34 in reply to: ↑ 33 ; follow-up: Changed 10 years ago by rlaager

Replying to sumitk:

Replying to deryni:

From a quick look at the patch my only concern is that it doesn't seem to migrate the existing preferences to the new names, which means that people will lose the 'show offline' flag for buddies, and the 'Show Offline' preference for the buddy list.

Yes, migration is missing. I'll fix that.

Why not just leave the preference as "show_offline"? I realize it's not perfect (and it has the opposite sense of show_always, so you'd have to reverse your logic), but leaving it would avoid all the migration code.

comment:35 in reply to: ↑ 34 Changed 10 years ago by sumitk

Replying to rlaager:

Replying to sumitk:

Replying to deryni:

From a quick look at the patch my only concern is that it doesn't seem to migrate the existing preferences to the new names, which means that people will lose the 'show offline' flag for buddies, and the 'Show Offline' preference for the buddy list.

Yes, migration is missing. I'll fix that.

Why not just leave the preference as "show_offline"? I realize it's not perfect (and it has the opposite sense of show_always, so you'd have to reverse your logic), but leaving it would avoid all the migration code.

Well, after getting this feature in, "show offline" will not be that clear . To me that would be "show all online buddies + show buddies that not hidden by the plugin + offline buddies" -- which could be not *all* buddies.

But yeah, taking a note from your point --- though not perfect but --- I can use the same keys (show_offline and show_offline_buddies) to store the values. Guess that should be okay!?!?

comment:36 Changed 10 years ago by sumitk

Here is the updated one with migration support. This patch is made from 2.5.3 code base.

Changed 10 years ago by sumitk

comment:37 Changed 10 years ago by hackel

Let me just add my opinion that Pidgin should have an option to hide mobile buddies, or at *least* classify them at the bottom of the list. I have seen many people discussing this feature, but I wasn't sure if it made it into the final/latest patch. I do not want to hide "away" buddies, just mobile.

The biggest reason I want this, is that I often send people URLs which they cannot (easily) view on their mobile. It also affects which buddy is displayed first within a contact. I would prefer simply changing the sort order, so that in case I did need to send an urgent message, I could still find the mobile buddy without going into the preferences.

comment:38 follow-ups: Changed 10 years ago by AaronCompNetSys

Argh. Use sumitk's old build with this patch and broken MSN support, or use the latest version and have hundreds of away/idle contacts to scroll though. Please please please?

comment:39 Changed 10 years ago by rekkanoryo

  • Milestone changed from Patches Needing Improvement to Patches Needing Review

This most recent patch needs review.

comment:40 in reply to: ↑ 38 Changed 10 years ago by rekkanoryo

Replying to AaronCompNetSys:

Argh. Use sumitk's old build with this patch and broken MSN support, or use the latest version and have hundreds of away/idle contacts to scroll though. Please please please?

There are no "builds" on this ticket. If you want to use this patch, you will need to build Pidgin yourself.

comment:41 in reply to: ↑ 38 ; follow-up: Changed 10 years ago by sumitk

Replying to AaronCompNetSys:

Argh. Use sumitk's old build with this patch and broken MSN support, or use the latest version and have hundreds of away/idle contacts to scroll though. Please please please?

If you are on windows, you can get the patched version from http://code.google.com/p/pidgin-plugins/downloads/list. On Linux? .... build yourself ;-)

comment:42 in reply to: ↑ 41 Changed 10 years ago by AaronCompNetSys

Replying to sumitk:

If you are on windows, you can get the patched version from http://code.google.com/p/pidgin-plugins/downloads/list. On Linux? .... build yourself ;-)

You, sir, are awesome. Thank you for your time.

comment:43 follow-up: Changed 10 years ago by adk

I built this plugin for Linux, I really like how it allows you to configure which buddies to hide! I had a few questions about it: First, I had to add "#define PURPLE_PLUGINS" at the beginning of the plugin to get it to work correctly, otherwise it would complain about it not calling purple_init_plugin, was this intended to be in there in the first place? Second, Is there a reason that it does not hide the buddies all right away? it hides them all as soon as the arrow indicating they signed on goes away (i noticed this immediately when it initially showed all of the mobile buddies on my list, then removed them all one by one as the arrow cleared), is that intended?

comment:44 in reply to: ↑ 43 Changed 10 years ago by sumitk

Replying to adk:

I built this plugin for Linux, I really like how it allows you to configure which buddies to hide! I had a few questions about it: First, I had to add "#define PURPLE_PLUGINS" at the beginning of the plugin to get it to work correctly, otherwise it would complain about it not calling purple_init_plugin, was this intended to be in there in the first place? Second, Is there a reason that it does not hide the buddies all right away? it hides them all as soon as the arrow indicating they signed on goes away (i noticed this immediately when it initially showed all of the mobile buddies on my list, then removed them all one by one as the arrow cleared), is that intended?

It doesn't have #define cause on my linux machine, I didn't see any such warning/error message. Second one was intended. I think that is better. I mean cases where you are watching buddy list or something, its better to know who is going away/buddy/offline etc. Think inactive plugin as adding a control over who would you treat as offline.

comment:45 Changed 10 years ago by adk

The error occurred while trying to load the plugin in the debugging info for me, the reason i added the #define PURPLE_PLUGINS macro was because of this page http://developer.pidgin.im/wiki/CHowTo/BasicPluginHowto where it mentions "a point to be well aware of. ALL C plugins must define PURPLE_PLUGINS by using the #define preprocessor directive. This definition must occur before including any libpurple, Pidgin, or Finch header files. Failure to have #define PURPLE_PLUGINS in your source file leads to very strange errors that are difficult to diagnose. Just don't forget to do it! " and adding it removed the problem for me, so that is my rationale there.

comment:46 Changed 10 years ago by rekkanoryo

  • Milestone changed from Patches Needing Review to 2.6.0

Accepting, rejecting, or requesting improvement of this patch is a blocker for the release of version 2.6.0.

comment:47 Changed 10 years ago by rekkanoryo

  • Milestone changed from 2.6.0 to Patches Needing Improvement
(18:36:50) deryni: rekkanoryo: The patch for #5876 is broken, it still uses a "show_always"
blist node setting in a couple places. It also looks much more complicated than I would
think it should need to be

comment:48 Changed 10 years ago by AaronCompNetSys

sumitk's 2.5.5 build http://code.google.com/p/pidgin-plugins/downloads/list with his patch has the Yahoo bug, here is the DLL one from 2.5.8: http://aaroncompnetsys.googlepages.com/libyahoo.dll

comment:49 Changed 10 years ago by MarkDoliner

Is this feature definitely something we want to add to Pidgin? It's not something I've ever had a use for myself.

comment:50 Changed 10 years ago by hackel

MarkDoliner, do you really think that comment was helpful in any way? You simply need to look at all of the people who have commented on this bug and requested the feature to know that at least some users want this option. Whether it's built-in or a plugin is irrelevant, we just want the functionality.

comment:51 Changed 10 years ago by MarkDoliner

hackel: Yes, I really think my comment was helpful. I'm interested in only adding features to Pidgin that the majority of people will use. See "Simpler is Better" at http://developer.pidgin.im/wiki/DesignGuidelines for my reasoning. I of course have no problem with this functionality being added as a plugin, I'm just not convinced it should be in Pidgin proper.

comment:52 Changed 10 years ago by AaronCompNetSys

I agree that it is irrelevant to getting this functionality completed, its not our decision but yours as a developer, hackel, as to if this is a plugin or built-in. I trust whatever you decide it should be as long as it gets done. But to answer your question because it is still important, there are a lot more people that would use this feature than can be represented here. I can tell you corporate IM is clouded with "Away" users and that finding someone that is able to respond (*ahem*) "instantly" is part of what appeals us to use IM in our business. Away users are useless to IM, email then prevails. I hope this was a bit more useful to you. I personally believe removing "Away" users from my view vastly simplifies my Pidgin experience and I vote for it being in the core product.

comment:53 Changed 10 years ago by AaronCompNetSys

Sorry, I meant to address that previous comment to MarkDoliner, not hackel.

comment:54 Changed 10 years ago by cphuntington97

I want to chime in with support for what an excellent feature this is. It saves me an enormous amount of tedious scrolling and buddy finding. Ninety percent of my buddies are often "mobile" and not truly "online." Also on a netbook with limited screen resolution, controlling what information is visible and what is hidden is a critical usability feature. If that's not simplicity then I don't know what is.

comment:55 Changed 10 years ago by deryni

  • Owner set to deryni

I fully believe that supporting a NO_DISPLAY flag for blist nodes is something that we should support and intend to accept at least that part of this patch. I don't believe pidgin should support (by default) setting this flag on buddies and I'm unsure whether 'Show Offline' should become 'Show All'. I think 'Show All' is less obvious in what it does to people who don't know about this new flag/feature and that people who are setting the flag (with the plugin that will need to be written) will likely be aware enough (or can be made aware enough) to understand that 'Show Offline' will display them again.

The request in #9809, for example, will be made possible with this patch.

comment:56 Changed 10 years ago by deryni

As a specific response to AaronCompNetSys? Buddies->Sort->By Status exists for that sort of thing, clustering the "available" buddies at the top of each group. Granted, that doesn't help with shortening the overall buddy list but it does help with locating the active buddies in any given group.

comment:57 Changed 9 years ago by AaronCompNetSys

Can anyone please update this patch and merge this to trunk? My company needs this feature more than we did a year ago.

comment:58 follow-up: Changed 9 years ago by hackel

AaronCompNetSys?, I would suggest you have your company contact one of the developers of the Pidgin project and arrange for payment terms to have your requested feature implemented.

For-profit entities don't get to make requests of open-source software unless they put their money where their mouth is.

comment:59 in reply to: ↑ 58 ; follow-up: Changed 9 years ago by cphuntington97

Replying to hackel:

AaronCompNetSys?, I would suggest you have your company contact one of the developers of the Pidgin project and arrange for payment terms to have your requested feature implemented.

For-profit entities don't get to make requests of open-source software unless they put their money where their mouth is.

I've tried to offer the developers money before but they haven't accepted. Maybe times have changed? I'd be glad to chip in to have this feature implemented.

comment:60 in reply to: ↑ 59 Changed 9 years ago by AaronCompNetSys

Replying to cphuntington97> I'd be glad to chip in to have this feature implemented. Sure, I will some too, just send me a message if you can work on it.

comment:61 Changed 9 years ago by AaronCompNetSys

sumitk's 2.5.5 build http://code.google.com/p/pidgin-plugins/downloads/list with his patch has an XMPP bug which prevents Facebook XMPP, which is only fixable with a rebuild. I don't know how to do that :(

comment:62 Changed 9 years ago by jviggiano

I've been getting emails about this ticket for almost two year. A couple of months after submitting the ticket, I gave up on Pidgin and started using digsby.

comment:63 Changed 8 years ago by AaronCompNetSys

Any updates?

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!