GNOME Bugzilla – Bug 671503
Use "frecency" to sort the history and bookmarks in the entry completion
Last modified: 2018-08-03 19:40:59 UTC
Right now we just use a very simple 'most visited' sorting. See: https://developer.mozilla.org/en/The_Places_frecency_algorithm
*** Bug 675851 has been marked as a duplicate of this bug. ***
Hi, the bookmarks code has been rewritten from scratch. When you have a convenient opportunity to test the new version of the code (which will be present in Epiphany 3.23.1) please check to see if your issue is still a problem, and reply here. Thanks!
Hi, this is a mass close of all bugs in the NEEDINFO state. If you think this bug was closed improperly, just leave a comment, thanks!
Closed in error (I believe). Bug has potential fix, just requires testing using 3.23.1 which won't be released for a couple of weeks yet.
(In reply to erusan from comment #4) > Closed in error (I believe). > > Bug has potential fix, just requires testing using 3.23.1 which won't be > released for a couple of weeks yet. Really? I dunno if there were any changes to the sorting. We used to have ephy-frecency-store, a couple years ago, but it doesn't exist anymore.
Perhaps I'm not understanding. You posted a comment Sept 28 2016: >Hi, the bookmarks code has been rewritten from scratch. When you have a >convenient opportunity to test the new version of the code (which will be >present in Epiphany 3.23.1) please check to see if your issue is still a >problem, and reply here.
(In reply to erusan from comment #6) > Perhaps I'm not understanding. You posted a comment Sept 28 2016: Ah, that was a mass bug update, I posted it in every bookmarks bug. :)
By the way, there is a FIXME for this in ephy-location-completion.c, so it should be clear where the code to modify is.
Is this bug still existing ? I could not find any ephy-location-completion.c file.
(In reply to cedlemo from comment #9) > Is this bug still existing ? Yeah! > I could not find any ephy-location-completion.c file. It would help if I got the filename right! It is src/ephy-completion-model.c. (The -model suffix means it's the M in MVC.) The FIXME is here: static int get_relevance (const char *location, int visit_count, gboolean is_bookmark) { /* FIXME: use frecency. */ int relevance = 0; /* We have three ordered groups: history's base addresses, bookmarks, deep history addresses. */ if (is_bookmark) relevance = 1 << 5; else { visit_count = MIN (visit_count, (1 << 5) - 1); if (is_base_address (location)) relevance = visit_count << 10; else relevance = visit_count; } return relevance; } frecency is just a smarter algorithm for ordering the results (see the first comment) instead of always putting bookmarks on top. Note: visit type is saved in the history service.
Created attachment 343090 [details] [review] implement ephy_search_service_find_visits This is the first step before implementing the "frecency" method. This function will allow to get the visit type for an url. I will just have to modify the definition of add_to_potential_rows (ephy-completion-model.c:358). add_to_potential_rows function is used in the function query_completed_cb (ephy-completion-model.c:404) l.432 ------------------------------------ if (!ephy_bookmark_is_smart (bookmark) && should_add_bookmark_to_model (model, user_data->search_string, title, url)) { list = add_to_potential_rows (list, title, url, NULL, 0, TRUE, FALSE); } } /* History */ page_visits = (GList *)result_data; for (p = page_visits; p != NULL; p = p->next) { EphyHistoryPageVisit *page_visit = (EphyHistoryPageVisit *)p->data; EphyHistoryURL *url = page_visit->url; list = add_to_potential_rows (list, url->title, url->url, NULL, url->visit_count, FALSE, TRUE); } l.446 ------------------------------------ After that I will be able (I guess) to modify the function get_relevance in order to compute the frecency.
Review of attachment 343090 [details] [review]: OK, looks good, just a couple of nits. Looking forward to part two. :) ::: lib/history/ephy-history-service.c @@ +1339,3 @@ +void +ephy_history_service_find_visits (EphyHistoryService *self, + gint64 from, gint64 to, OK, I see that this file does not follow GNOME style for parameter declarations. So it's fine here, but something we can change in the future.... @@ +1362,3 @@ + + ephy_history_service_query_visits (self, + query, cancellable, Looks like the whitespace is messed up here. The s in self should be aligned with the q in query and the c in callback. ::: src/ephy-completion-model.c @@ +408,3 @@ { EphyCompletionModel *model = user_data->model; + GList *p, *page_visits; Same feedback as in the other bug: declare this on two lines, please. @@ +583,1 @@ 0, 0, Be sure to realign the parameters here as well, since _find_visits is longer than _find_urls.
Created attachment 343096 [details] [review] implements ephy_history_service_find_visits >> Looking forward to part two. :) So for you it looks like a reasonable approach for the problem, great! >> OK, I see that this file does not follow GNOME style for parameter declarations. So it's fine here, but something we can change in the future Maybe add it as a bug, it could be good for me to format this file in order to learn the GNOME style.
Review of attachment 343096 [details] [review]: Forgot about this! It looks good, I would just add some justification to the commit message regarding why the new function is needed (to get the visit type).
Could we agree on an algorithm for Epiphany ? The EphyHistoryPageVisitType values come from Chromium and the algorithm I have to adapt comes from Mozilla. Frequency calculation process : bonus for type : EPHY_PAGE_VISIT_LINK, --> 120 EPHY_PAGE_VISIT_BOOKMARK, --> 140 EPHY_PAGE_VISIT_TYPED, --> 200 EPHY_PAGE_VISIT_NONE, --> 0 EPHY_PAGE_VISIT_MANUAL_SUBFRAME,--> 0 EPHY_PAGE_VISIT_AUTO_SUBFRAME, --> 0 EPHY_PAGE_VISIT_STARTUP, --> 0 EPHY_PAGE_VISIT_FORM_SUBMISSION,--> 0 EPHY_PAGE_VISIT_FORM_RELOAD, --> 0 EPHY_PAGE_VISIT_HOMEPAGE --> 0 weight based on how recent the url have been visited 0 < r <= 4 days --> 100 4 < r <= 14 days --> 70 14 < r <= 31 days --> 50 31 < r <= 90 days --> 30 r > 90 days --> 10 points (for each visit) = (bonus / 100) * weight After that, the frecency will be calculed like this : for an url, get all the visit count : full_count It seems that we need to specify a parameter : the sample size (10 max for example) The sample is the 10 most recent visit for an url. For each element in the sample, an url we compute the points Then the frecency will be : full_count *((somme of points for the sample)/sample size)
Sounds good to me, at least for now. We can always tweak it later. I might want to weight bookmarks more than Firefox does, for instance, but let's see how well this works first. Note: some of those EphyHistoryPageVisitType values are completely unused, but we can't remove them without breaking the history database. :/
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/epiphany/issues/161.