Home | Blog | Software | Reviews and Features | Forum | Help | Donate | About us
topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • December 10, 2016, 04:16:51 PM
  • Proudly celebrating 10 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: [feature request] show me score break-down for item  (Read 2039 times)

mackal

  • Member
  • Joined in 2007
  • **
  • Posts: 25
    • View Profile
    • Donate to Member
[feature request] show me score break-down for item
« on: August 23, 2007, 08:01:02 PM »
This would be really cool, would help with tweaking the heuristics.  Is there such a function?  If not, then pretty please please please!  :D  Occasionally I don't like the sorting that comes out and I'd love to know why it came out the way it did...  Seems technically simple, and could be simply a new option in the context menu that you get when you right click on a result item.

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 36,435
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: [feature request] show me score break-down for item
« Reply #1 on: August 23, 2007, 09:07:30 PM »
it's a fun idea for sure, i've thought of it myself. unfortunately it's not so trivial to add and not suffer a performance penalty.  not something i can add for now.

mackal

  • Member
  • Joined in 2007
  • **
  • Posts: 25
    • View Profile
    • Donate to Member
Re: [feature request] show me score break-down for item
« Reply #2 on: August 23, 2007, 09:14:33 PM »
Really?  Too bad, would have been useful.  I assume that by overhead you mean the need to store for each result item the full scouring source information and such.  But perhaps when "show score break-down" is clicked, the search can be *rerun*, and as it progresses this time around the more expensive code path is chosen, the one which notes all the details.  That way things would be fast and lean during normal operation, as usual, and the extra load is only incurred on an introspective run through the search...  Just a thought; in all likelihood this approach is not even viable, I don't really know what the control flow of FARR is during its searches.  But hey, I can wish. :)