Implement `completion-item-focus next-category` and
`completion-item-focus prev-category` to jump through completions by
category rather than by item.
Resolves#1567.
This moves creating the HintManager to AbstractTab, and lets
TabData (which is now a QObject) handle the start_hinting/end_hinting
signal.
For the mouse_event signal of HintManager, we now have a slot in
AbstractTab too, though that might actually be moved to
WebKitTab/WebEngineTab later when needed.
This moves various stuff around and out of QtWebKit code:
- open_target and hint_target are now in TabData, not on the WebPage
- As much as possible got extracted from WebPage.acceptNavigationRequest
to AbstractTab._on_link_clicked, with a new link_clicked signal added
to WebPage. However, we need to decide whether to handle the request
in this tab or not inside acceptNavigationRequest, so we have some
code duplicated there and in WebEnginePage.acceptNavigationRequest.
- _mousepress_opentarget (i.e., setting the open_target) is now handled
in MouseEventFilter, not in WebView.
It seems with document.documentElement.client{Height,Width} we
sometimes (e.g. without <!DOCTYPE html)...) get the full element height
instead of the viewport height.
Fixes#1821.
For some reason, when e.g. visiting duckduckgo and then heise.de,
QtWebEngine suddenly gets a new QOpenGLWidget as focusProxy.
We install an extra eventFilter observing the ChildAdded event and
re-adding the MouseEventFilter when that happens.
I usually use my browser with a one-window-per-workspace flow. If I
click on a URL anywhere, I personally would prefer it to go to the
browser instance that's on the same workspace.
To this end, the easiest way to accomplish this is to simply track when
windows are made visible and register them as the last visible object.
(To get finer control for when you have multiple windows on the same
workspace, focus changes also update the last visible object - the
implication being here that focusing something also means you're looking
at it)
Not all users may like this behavior, so I consider it strictly optional.
Command completions for `:bind` and `:` will now show bindings for
aliases. The binding is only included if it is bound to that alias, not
if it is bound to the command the alias points to.
Returning a defaultdict made the caller's code look confusing, as it
wasn't clear why there wouldn't be a Keyerror in some cases. Instead,
let the caller explicitly use `get`.
Consolidate the logic used to generate the command completion category
into one place. This is shared by CommandCompletionModel,
HelpCompletionModel, and BindCompletionModel.
Hidden commands are not shown in command completion as they typically
would not be run directly. However, a user might still might like to see
help for them if, for example, they are writing a script or creating a
binding.
Addresses #1707.
Various code (like src2asciidoc.py) relies on all @cmdutils.register
decorators being called when qutebrowser.app is imported.
Moving the keyconf import to _init_key_config broke that assumption, as
keyconf isn't imported anywhere anymore - which caused :bind and :unbind
to vanish from the generated documentation.
In the long run we should perhaps use venusian:
http://docs.pylonsproject.org/projects/venusian/
But for now, this is the easiest solution.
Wire up the config change event to update command completion on
changing aliases, so the new aliases will be included.
Fixes#1814.
Currently we do not have tests at a high enough level to test whether
signals are wired up correctly to update completions.
This adds the ability to open new tabs in the last-focused window
instead, which fixes#1801.
Right now the only other option is probably not that useful for human
users but it's required to make tests behave deterministically and
consistently. (But with #881 on the roadmap, I would implement this as
another choice)
To this end, also make the test framework set this option to preserve
the invariant against which existing tests are written: that spawning a
new window would effectively also focus it.
This was currently almost completely broken, yet nobody complained. The
new behavior (in the previous commit) makes this always hide the mouse
cursor, even when an input field has focus.
Since the only two easy options to implement are "never hide" and
"always hide", combined with the fact that both are sort of useless to
an end-user, just remove the option until somebody wants it back.
Right now, get('last-focused-main-window') essentially returns the same
as qApp.activeWindow(), since it's None when no window is focused. This
seems somewhat contrary to its original intent, so I've changed it to
only ever update the object.
This actually fixes another bug as well: on_focus_changed's new is not
always a MainWindow - in fact it's a WebView on my end. To fix this,
directly use the QApplication.activeWindow() to find the current focus.
That second bit in particular actually some related bugs that probably
nobody ever noticed or bothered reporting:
* _maybe_hide_mouse_cursor currently pretty much never gets called
* :adblock-update doesn't actually show any downloads
* ... probably more
