Before, the item_added signal was emitted *after* an item was added, which
means the on_history_item_added slot always assumed the item already is in the
history.
Before, we initialized the completions once for every window spawned, which was
a waste of CPU-time and RAM.
Now we only initialize them once, when the user uses the completion for the
first time.
This makes qutebrowser.config.websettings much easier to understand, and saves
all defaults so it can restore them properly when a setting is set to an empty
string.
Before, when we set the fonts to empty strings instead of the true default, in
some cases anti-aliasing was broken.
Fixes#549.
Otherwise we would construct a QStandardItem with the
QStandardItem(int rows, int columns = 1) constructor, which will most likely
not do what we want.
- HistoryItem.atime now always should be an int/float.
- The data for the sort role should also be an int, not a string.
A float would also work, but maybe be slower for no real benefit.
Two things here. One is to use `WebHistory._new_history` only as a to-save
queue, so we now add entries to `_old_urls` when they are first created and
can now no longer iterate of `_new_history` in `__iter__()`.
Second is to stop blindly tacking new history entries on the end of the
history completion model. It does involve iterating over the model to find the
existing entry but we only do that if we know the duplicate is there, which is
fast to check.
This also ads another point of mutation to the history completion model which
may prove problematic if it leads to more segfaults.
Each new HistoryEntry is emitted after being added to the global history
store. Current members of the HistoryEntry are `url` and `atime`. `title`
should be coming soon.
Adds a basic completion model implementation around the global browser
history and registers that for the open command.
Modifies WebHistory to add an __iter__ method and to use a dict instead of a
set to store an entire HistoryEntry for each archived item instead of just the
URL. Brief tests showed that the lookup time for set and dict are very
similar. They are at least on the same order of magnitude. Testing membership
of a list on the other hand, as was the case before a set was used, was four
orders of magnitude slower on my machine.
This makes it possible to use Qt's QSortFilterProxyModel::lessThan option for
completions where it doesn't make sense to priorize matches starting with the
entered string, e.g. for URLs. In return, we get a *much* better performance
(several seconds when opening the completion).
See #531.
