- Selecting `currentIndex` based on the children placed in the `StackLayout`
component with id `appView` is sorted out since we were referring to the wrong
indexes there in case of walletv2, node and community sections.
- Places which call `Utils.getAppSectionIndex` are updated since we don't have
that method any more.
- Some parts which are not refactored yet are commented.
This does a couple of things:
- It remove StatusRadioButton row from ui/shared/status
- Introduces RadioButtonSelector in ui/shared/controls instead
- That component is then built with StatusQ
Introduced Style.svg() Style.png() Style.emoji() and
Style.icon() in Style.qml. Those should be used to
set the source in Images instead of using relative
paths. Usage:
Image {
source: Style.svg("check)
....
Also moved all Singletons inside a new "utils"
folder and made it a QML module, to use
import utils 1.0 instead of relative paths
Closes#3678
Fixes: #3564.
Several UI bug fixes have been made for the gif widget:
1. Star now only appears once the gif is hovered
2. Default hover star colour is “grey”
3. Once the star is hovered, the star turns yellow
4. If the gif is favourited, the star fills in yellow
5. Removed square border around the gif
6. Added invisible padding around the star to increase the mouse surface area for hover/click
7. Added tooltip to the star for adding/removing from favourites
NOTE:
1. An initial attempt at changing star state based on gif thumb hover and star hover proved unsuccessful. Changing visibility of the star had to depend on both the hover state of the thumb AND the star — relying on only the thumb hover caused a flicker.
2. Relying on the local hover state of the star and the thumb hover state caused inconsistencies where the hover state of the star would become true after not being hovered. I’m still unsure as to why this was happening. A workaround was to create a signal to a HOC as to the last hovered gif id. From there, we could rely on matching `model.id` to the last hovered gif id in the HOC.
This feature works for MacOs only, for now.
On login, whether new or already created user may select between options:
"Store" - store password to the Keychain
"Not now" - don't store it now, but ask next time again
"Never" - don't store them ever and don't ask again
Selected preference may be changed later in:
`ProfileSettings > Privacy and security > Store pass to Keychain`
On the next app run, if `Store` was selected, a user will be asked to confirm
his identity using Touch Id in order to log in the app. If any error happens
he will be able to login using password.
Fixes: #2675