Opened 12 years ago

Closed 12 years ago

Last modified 10 years ago

#301 closed enhancement (worksforme)

Make number of saved popular statuses configurable

Reported by: gagern Owned by: seanegan
Milestone: Component: pidgin (gtk)
Version: 2.0 Keywords:
Cc: mark@…, royce

Description

Currently the six most popular statuses are used to populate the statusbox dropdown menu and the docklet context menu. It would be nice to have this number configurable to take into account the number of often used statuses and the amount of screen real estate you are willing to use. It is pretty annoying if you use seven or eight statuses in a somewhat cyclic manner so that the one you want to use next is always the one not available right now.

To implement this, look for gaim_savedstatuses_get_popular especially in [source:pidgin/gtkdocklet.c] and [source:pidgin/gtkstatusbox.c].

Change History (11)

comment:1 Changed 12 years ago by lschiere

  • Owner set to MarkDoliner

comment:2 follow-up: Changed 12 years ago by MarkDoliner

  • Cc mark@… added
  • Owner MarkDoliner deleted

I'm against this idea for the reasons outlined at http://www106.pair.com/rhp/free-software-ui.html, specifically the section titled "The Question of Preferences"

comment:3 Changed 12 years ago by lschiere

  • Owner set to seanegan

While I tend to agree that a preference for this seems rather pointless/silly, I also understand the frustration here.

We chose 6 arbitrarily, and should be considering the need to adjust that number.

comment:4 in reply to: ↑ 2 Changed 12 years ago by gagern

Replying to MarkDoliner:

I see your point. Still I deem the issue annoying enough to warrant some action.

How about a config file entry without any UI connected?
Would make the thing pretty much hardcoded to the common user, but people annoyed enough to search for it can find a way to modify the behaviour without recompiling (with is troublesome on Win) or applying this modification over again to every new release.

Other solutions might be to simply increase the number (twice the current number should be OK even on 800x600, I think), or do some magic calculation based on the current screen resolution and the number of fairly often used items. But the latter one is way more complicated and feels like serious overkill, while the former will probably crowd the menu too much for many users.

As there are many things that might be done, would it be feasible to have plugins affect this setting? Or even the whole generation of the list? I haven't yet understood how plugins work in pidgin, how much of an impact this would have on plugins that don't use it.

As a last resort: how about enclosing the number 6 in some kind of array of magic numbers, which you can find and modify in a hex editor if you are really desperate?

comment:5 Changed 12 years ago by elb

Some sort of strategy which looks at the LRUed-ness of the entries, and tries to find a large variance in the derivative (or uses a standard deviation, or etc.) with a fallback on some essentially arbitrary fixed constant might help. Something like "Show 6 ± 3 entries", where the exact cutoff is the first entry which has a standard deviation fewer references within the past 100 status changes.

Hex editing the constant is simply unacceptable on every level. Hidden preferences are undesirable, but not to the same extent.

comment:6 follow-up: Changed 12 years ago by gagern

We don't have the distribution of the last 100 status changes. We only have the abolute usage counts and the timestamps of creation and last usage. At least that's what I see here on my beta6. And collecting more seems excessive to me.

Using the usage count instead of the timestamp would help avoid the cyclic usage problem described in my initial description. However it would also make the sorting slower to respond to changed behaviour.

If you were to use usage_count / time_since_created as an estimate of usage frequency, you could then apply the scheme you outlined, and try tweak it until it seems satisfactory. An alternative would be to simply examine the possible cutoff positions and take the one with the largest difference in estimated usage frequency. Saves a lot of math, and is best for all scenarios I can think of right now.

I'd rather have 9 ± 3 entries instead of 6 ± 3. :-)

comment:7 Changed 12 years ago by MarkDoliner

We currently use both the usage count and the last-used timestamp. From the comments on saved_statuses_sort_func() in libpurple/savedstatuses.c:

"A magic number is calculated for each status, and then the statuses are ordered by the magic number. The magic number is the date the status was last used offset by one day for each time the status has been used (but only by 10 days at the most).

The goal is to have recently used statuses at the top of the list, but to also keep frequently used statuses near the top."

I'd rather not have a hidden preference for this. I'd be ok with changing the number from 6 to something else, but I think 6 is the ideal number for most people.

comment:8 in reply to: ↑ 6 Changed 12 years ago by elb

Replying to gagern:

We don't have the distribution of the last 100 status changes. We only have the abolute usage counts and the timestamps of creation and last usage. At least that's what I see here on my beta6. And collecting more seems excessive to me.

The nice thing about open source software, is that we can collect whatever we want, however we want. Keeping the distribution of the last hundred status changes is basically free, if done in a heuristic rather than absolute fashion (that is, store counts only for the statuses which actually "survive", and discount those which do not.

If you were to use usage_count / time_since_created as an estimate of usage frequency, you could then apply the scheme you outlined, and try tweak it until it seems satisfactory. An alternative would be to simply examine the possible cutoff positions and take the one with the largest difference in estimated usage frequency. Saves a lot of math, and is best for all scenarios I can think of right now.

A problem here is that it could (and, I think, would) develop an undesirable amount of hysteresis. In situations like this, you generally want to (as Mark's comment indicates we do currently) lend some extra weight to more recent decisions than long distant decisions. Your division by time_since_created helps this, but I think still gives too much credence to old statuses which were popular at one time, but are no longer.

That said, this is all optimization when we don't have a product to optimize, yet. We get enough questions and suggestions about the current fixed value of 6 to warrant further discussion, at any rate. My suggestion for the discussion is some sort of fixed-window (time or event, which one is better is not clear to me) calculation, or at the very least, a moving average of some sort.

Keep in mind that the only status I ever use is 'Available'. ;-)

comment:9 Changed 12 years ago by gagern

To keep information about the last hundred changes, counts simply won't do. You have to keep track of the order in which counts expire, which means that you have to keep a log of those hundred changes. Whether you remove nonsurvivers doesn't really make much of a difference imo, and would further comlicate matters. Therefore sliding windows require quite a few lines of storage, and I don't know how this would interact with backwards compatibility. The same goes for moving average.

An alternative would be some form of decaying usage count, like at every change, multiply all counters by 0.98, then increment the one you changed to by 1. This can be done with only a single real-valued additional attribute per saved status. After 35 changes of status, your usage count would have lost half its weight if it was not used any more.

The only way to avoid problems with hysteresis would be to remember past decisions. Otherwise, no matter how quick or slow your comparison function responds to changed user behaviour, you can always get users circling around the critical cutoff.

I had a look at saved_statuses_sort_func in [source:libpurple/savedstatuses.c]. I fear it is also a cause of the cyclic use problem I described initially, as the limit of 10 is easily reached, and after that only timestamps count. So while this function is not bad, there is some space for improvement.

To extend my own idea of frequency estimations, you could use the inverse of the time since last use as another estimate. This would by itself lead to the same order as the simple comparison of last usage times, but as a kind of frequency it would be on the same scale as the frequency estimate suggested above. You could then clip those if needed and weight them against one another, to balance overall against recent behaviour. Of course you could do all this in the inverse as well, i.e. time_since_created / use_count gives you the mean time between uses, which can be combined with the time since last use. This is nearer to what is there right now, and yields exactly the same results as the dual frequency approach.

Talking of the product we don't have, if you mean Pidgin 2.0.0, I agree this should have precedence. If you however mean a change to the fixed choice of six, then I believe this modification to be closely related to a good choice function, so those two should perhaps be implemented together.

I guess I'll have to get myself a monotone tree of pidgin, to experiment a bit, although the size of the bootstrap database worries me already.

comment:10 follow-up: Changed 12 years ago by seanegan

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

While totally arbitrary, 6 seems like a pretty good value. I don't think it's worth going crazy to come up with a better value.

comment:11 in reply to: ↑ 10 Changed 10 years ago by royce

I have taken a slightly different tack to this issue in #8726.

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!