KeepassXC tries to load the theme icon first and then falls back to the internal icon unless the check is explicitely disabled. Remove the check from most icons
Fixes#756
* Replace Google with DuckDuckGo for optional fallback favicon fetch URL
Modify the work initially done in #36, and most recently modified in #1786,
to use DuckDuckGo's https://icons.duckduckgo.com/ip3/www.example.com.ico
favicon endpoint.
Fixes#2258
* Close failed favicon fetch progress bars
Name the UrlFetchProgressDialog() with the corresponding URL in order to
be identified by name by its parent when the failed request is handeled
in EditWidgetIcons::fetchFinished(). fetchFinished() retrieves the
relevant UrlFetchProgressDialog() and calls close() on it.
Fixes: #2265
* Eliminate TOTP logic from GUI elements
* Consolidate TOTP functionality under the Totp namespace
* Eliminate guessing about state and encoders
* Increased test cases
* Add entry view column for TOTP [#2132]
* General code cleanup, reduction of unnecessary steps, separation of concerns
* Rename SetupTotpDialog to TotpSetupDialog for consistency
* Added Patreon contributors
* Added real names to project maintainers
* Cleaned up layout
* Added settings button to main toolbar
* Added actions for "Donate" and "Report a Bug" to help menu
Qt 5.11 cleanes up the internal headers and so consumers could fail by
missing includes.
See: https://bugs.gentoo.org/655844
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
* Eliminate dependency on libcurl in favor of Qt5Network code
* Supports older Qt versions without QNetworkRequest::FollowRedirectsAttribute
* Show a progress dialog when downloading the favicon. The main utility
of this is giving the user the option to cancel a download attempt
(e.g. if it's taking too long). Canceling will try the next fallback URL in the list.
* Try three different ways to obtain the favicon, in this order:
1) Direct to fully-qualified domain (e.g. https://foo.bar.example.com/favicon.ico)
2) Direct to 2nd-level domain (e.g. https://example.com/favicon.ico)
3) Google lookup for 2nd-level domain name (if enabled in settings)
I changed the Google lookup, because a match is more likely to be found
for the 2nd level domain than for the fully-qualified name.
Google's error behavior is strange. If it doesn't find a match, it
doesn't return an error. Instead, it returns a generic default icon,
which is not really the desired result. This also means that unless we
have some way to detect that we've received the generic icon, we can't
fall back to any alternatives.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Resolves#1313
What this commit does:
* Whenever the Apply button is pressed, and if the save was successful, then the Apply button is disabled.
* Each subwidget used by EditEntryWidget has now a signal called `widgetUpdated` that is emitted when the widgets' internal content changes. The EditEntryWidget subscribes to that signal to know when to enable the Apply button (by calling `entryUpdated()`).
* There are some views that are not isolated in their own widgets (`m_advancedUi`, for example) so in those cases I invoked `entryUpdated()` directly whenever I detected an update:
* some updates occur directly in a Qt widget like when editing the text of a QLineItem, so in that case I connected the widget's signals directly to the `entryUpdated()` slot.
* some updates occur in EditEntryWidget, so in those cases the invocation to `entryUpdated()` is made as soon as the change is detected (for example when the user has confirmed an action in a dialog).
A known problem: there are some situations when the Apply button will get enabled even if there are no changes, this is because the app changes the value of a field by itself so it's considered an update (for example, clicking on the "Reveal" button changes the text shown in a text field).
The solution to this can be a bit complicated: disabling temporarily the `entryUpdated()` whenever the app is going to do an action with such side-effects.
So I preferred to let the Apply button get enabled in those cases.
