Merge lp:~uriboni/webbrowser-app/bookmarks-in-suggestions into lp:webbrowser-app
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Olivier Tilloy on 2015-04-22 | ||||
| Approved revision: | 995 | ||||
| Merged at revision: | 973 | ||||
| Proposed branch: | lp:~uriboni/webbrowser-app/bookmarks-in-suggestions | ||||
| Merge into: | lp:webbrowser-app | ||||
| Diff against target: |
1185 lines (+555/-335) 14 files modified
src/app/webbrowser/Browser.qml (+29/-5) src/app/webbrowser/CMakeLists.txt (+1/-1) src/app/webbrowser/Suggestion.qml (+81/-0) src/app/webbrowser/Suggestions.qml (+57/-85) src/app/webbrowser/history-matches-model.cpp (+0/-92) src/app/webbrowser/history-matches-model.h (+0/-62) src/app/webbrowser/suggestions-filter-model.cpp (+135/-0) src/app/webbrowser/suggestions-filter-model.h (+72/-0) src/app/webbrowser/webbrowser-app.cpp (+2/-2) tests/autopilot/webbrowser_app/emulators/browser.py (+3/-5) tests/autopilot/webbrowser_app/tests/test_suggestions.py (+93/-28) tests/unittests/CMakeLists.txt (+1/-1) tests/unittests/suggestions-filter-model/CMakeLists.txt (+2/-2) tests/unittests/suggestions-filter-model/tst_SuggestionsFilterModelTests.cpp (+79/-52) |
||||
| To merge this branch: | bzr merge lp:~uriboni/webbrowser-app/bookmarks-in-suggestions | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Olivier Tilloy | 2015-04-16 | Approve on 2015-04-17 | |
| PS Jenkins bot | continuous-integration | Approve on 2015-04-16 | |
|
Review via email:
|
|||
Commit Message
Include bookmark results in the suggestions list
Description of the Change
Include bookmark results in the suggestions list.
Some notes:
- the design document specifies 8 max total suggestions, of which essentially 2 history, 2 bookmarks and 4 search results. since we don't do search results yet for now i set the limits to 4 history and 4 bookmarks.
- we had discussed not using LimitProxyModel, however it ends up being actually useful for this use case and working well. the alternative would have been to hand pick the items from the results to build a new list, but it proved very non-declarative and clunky. we might remove it in a further iteration by creating a c++ model that merges and limits the various results from suggestion sources (which would also solve the Suggestions.count property being slightly hackish), but I would leave that for later when we get the search engine suggestions as well.
| Ugo Riboni (uriboni) wrote : | # |
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:981
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Olivier Tilloy (osomon) wrote : | # |
I haven’t reviewed the code yet, but I’m seeing one functional issue here (it looks good and works well otherwise): testing on desktop, if I decrease the height of the window, then start typing in the address bar so that I have more results than fit of the screen, I can’t scroll them into view (I can see that they are there by dragging the list view, but when releasing they spring back out of sight).
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:982
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Olivier Tilloy (osomon) wrote : | # |
In src/app/
- updateSearchRoles is not reimplemented from QSortFilterProx
In src/app/
- In SuggestionsFilt
- In SuggestionsFilt
In tests/autopilot
- In get_ordered_
In tests/unittests
- In shouldMatch, there’s a leftover qDebug()
In src/app/
- Can’t you simply make models a var? If it was a javascript array instead of being a QML list, you could use the Array.reduce() function to compute the total count, thus inlining the function (and potentially making it faster to run)
In src/app/
- The call to highlightTerms() breaks encapsulation. The definition of the function should probably be moved to this file.
| Ugo Riboni (uriboni) wrote : | # |
Everything else not included in this reply has been fixed as requested
> - In SuggestionsFilt
> entries for which not all terms match in at least one of the roles, but I
> think it should be more tolerant, and match an entry if all the terms are
> found in at least one of the roles (i.e. for two search terms, if the first
> one matches only the first role and the second one matches only the second
> role, the entry should be included)
Ok, the previous implementation was restrictive so I did not change it. Fixed as you request now.
> In src/app/
>
> - Can’t you simply make models a var? If it was a javascript array instead of
> being a QML list, you could use the Array.reduce() function to compute the
> total count, thus inlining the function (and potentially making it faster to
> run)
No, if I make the model a var, and keep the same assignment code in Browser.qml, I get this: "Cannot assign multiple values to a singular property" when trying to assign a list to it.
To use a var, and thus a JS array as the list of models, with all the functional programming goodies it comes with, you have to use a slightly more cumbersome syntax on the assignment, but I think it is worth it.
Judge by yourself with the change I proposed.
> In src/app/
>
> - The call to highlightTerms() breaks encapsulation. The definition of the
> function should probably be moved to this file.
Actually it was a mistake to call it from inside the Suggestion item itself, as it was already called in Suggestions.qml
| Olivier Tilloy (osomon) wrote : | # |
615 + if (foundTerms.count() == m_terms.count()) {
I can see one possible corner case where this will fail: if m_terms contains doublons (e.g. if for whatever reason I typed in the address bar "ubuntu ubuntu"). This is arguably not a very important use case, but I think it’s easy enough to fix regardless, by comparing to QSet<QString>
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:984
http://
Executed test runs:
FAILURE: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Olivier Tilloy (osomon) wrote : | # |
A suggestion (pun intended):
In tests/autopilot
Care to remove it, and rename get_ordered_
| Olivier Tilloy (osomon) wrote : | # |
I ran a coverage report on this branch, and there’s a couple of things that are not covered by the unit tests (but it’s easy to fix):
- in SuggestionsFilt
- SuggestionsFilt
With the above fixed, coverage for SuggestionsFilt
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:990
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
None: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:993
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Olivier Tilloy (osomon) wrote : | # |
When merging the latest trunk (lp:webbrowser-app) into this branch, it fails to build because includes were re-ordered in webbrowser-app.cpp, and when merging history-

Included a bunch of inline comments to clarify on pieces of the patch.