Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#7389 closed defect (worksforme)

Status when changing to Available

Reported by: alongfield Owned by: lschiere
Milestone: Component: unclassified
Version: 2.5.2 Keywords: status change


Pidgin 2.5.2 now maintains the Away/DND/etc status when changing between status states. This is applied even when changing to the Available status. The result is that the user is forced to manually clear the status message when becoming Available from an Away state.

Pidgin should probably clear the status message when changing to Available. This would provide the expected behavior for most users and decrease extra steps required for typical use.

A side effect of this is that the status history become quickly cluttered with status messages when changing Away->Available, seriously diminishing its utility. By clearing the Available status message, it would not be added to the history, allowing for more true Away messages to be saved.

Example: Away w/ message: I am not home right now -Change to Available- Available w/ message: I am not home right now

Change History (4)

comment:1 Changed 10 years ago by deryni

If there is one thing the debate about this feature showed me/us it is that it is all but impossible to satisfy 'most' users when it comes to this feature.

The way pidgin used to work caused people who like to keep the same message in use at all times, or even just for long(er) periods of time (regardless of status type) a relatively large amount of effort to make pidgin work the way they wanted it to.

The current mechanism causes the people who don't do that or who have largely single-use messages to expend a relatively small amount of effort (a single press of the backspace key) to get pidgin to do what they want it to do.

It seems reasonable to me that there are likely a fair number of people who might want to keep a status message when going away but not want to keep it when coming back from away, but I think it likely overstates the number to claim that it is a clear majority. Likewise, I couldn't say with any amount of certainty that either of the other types of user represents a clear majority. Given all of the above, and the numerous discussions that occurred about this topic the current mechanism was decided on as a compromise which served as many users of as many types as possible with as little cost to those whom it doesn't serve perfectly.

We are always open to further refinement of the idea, I'm just not sure the proposed solution actually helps in any significant way.

comment:2 Changed 10 years ago by blk

I hadn't realized what a controversial feature this was until reading the above comment, as I, like the original submitter, had always considered keeping the status by default to definitely be a bug.

I think the part that feels awkward to me is that while I can select from a list of previously saved away status messages with a click and a scroll, in order to have no message, I have to click -and- type. Which I constantly forget to do, because almost nothing else on the buddy list requires keyboard input. Maybe I need the "Available with no message" option to be part of my "frequently used statuses" list, so I can just click once and select it.

comment:3 Changed 10 years ago by rekkanoryo

  • Resolution set to worksforme
  • Status changed from new to closed

An easy solution to this problem is to create a saved available status ("Saved statuses..." from the status selector menu) that has no message. For clarity's sake we'll call it "Available - no message." Now, let's assume you selected Away from the status selector and typed in "I'm at work. Call me if you need me." It's now a few hours later and you're back home, and want to go back to "Available" with no message. Use the saved status. Problem solved.

I personally would create saved custom statuses for frequently used messages. For example, I have three distinct Available statuses saved with messages, and a few common Away statuses such as "sleeping" and "at work." I switch between these statuses in the exact same manner--select the status from the middle section of the status selector menu--and never have to worry about clearing a transient message or seeing the ugly text box.

comment:4 Changed 10 years ago by deryni

Controversial is too strong a word, complicated and subjective are better.

To explain a bit of history here, just for clarity's sake. When the status selector was first added it didn't save the message. Early on some people decided for their usages they thought it should, and it was changed to do so. After a short time using that a number of other people decided they didn't like it (as it didn't fit their usage of status messages) and it was removed. It stayed removed for a decently long time, but was brought up by various people here and there along the way.

A little while ago, a long series of mailing list threads re-awoke in which this issue was finally actually boiled down to the real at-heart issue here. That issue is the one about how people perceive of and use the status message.

The two main camps (there may be others, but they mostly are gradations of these two) are the people who use status messages related to the status type (and which tend to be time sensitive) and those who use them as a more general mood/status message (think Twitter or Facebook status).

It became clear, during this latest round of discussions, that the people (who were likely growing in numbers) who wanted to use the status message as a mood were hard pressed to make pidgin behave the way they wanted to (involving copying and pasting the status text around each status change). Whereas the people who used status type tied messages had things largely Just Work. As I indicated in my last comment, the current mechanism was chosen because it greatly simplifies the usage pattern for the mood message users and only slightly inconveniences the status-tied message users. Which felt like general progress to us. (Especially given that saving message-less statuses is easy, though this brings up the other issue of getting to saved messages more than the most common/recent six, but of that another ticket.)

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!