Also modify `package.json` so that npm version must be >= 7 and node version
must be >= 10 (same as npm v7). This will avoid `package-lock.json` churn if
someone builds with npm version < 7.
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.
fixes#3659
Wallet2 needs its own event otherwise they wallet1/2 mixes
and as not everything is implemented in wallet2, it crashes
In this particular case, the account is added into wallet1 but trigger
an event intercepted by wallet2, wallet2 doesn't have the new account
and crash
Moved the statusChatInput to the repeater in stackview so that each conversation has its own separate textInput area which maintains its own state
fixes#1351
formattedPlainTextFilter was not reset when suggestion
box was closed causing the insertMention function to be
called again even thought there was no mention in the
chat input
Closes#3535
Fixes#3606.
The “retry” link for failed messages was not aligned correctly in the light theme. This was due to setting the `verticalCenter` as well as `anchors.top` in some situations. `verticalCenter` has been removed in favour of setting the top and bottom anchors.
Fixes: #3473.
Sometimes when blocking users and changes channels, blocked user messages would still appear.
This PR fixes the issue by toggling a `hide` property on messages from a contact when that contact is blocked or unblocked. Previously, the messages were only removed from the view when the contact was blocked, but when the view was reloaded, that state was not tracked correctly.
In case clicked channel:
- exists in a community -> the app will switch you to it
- doesn't exist in a community, but exists in the public chat list -> the app
will switch to `Chat` section and also to the appropriate channel there
- doesn't exist in a community and doesn't exist in the public chat list -> the app
will switch to `Chat` section and join new channel
Fixes: #3489
With these changes it will be easier to maintain, i.e. to add/remove bottles
just modify the `BOTTLES :=` list.
`brew update` is removed from `scripts/fetch-brew-bottle.sh` and instead done
in an [order-only
prerequisite](https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html). This
allows multiple bottles to be fetched in parallel (e.g. `make -j16`) without
overlapping invocations of `brew update` (which causes script failure).
When StatusQ switched to using `DelegateModel` in `StatusChatList` to enable drag and drop,
we lost the API `itemAt` which was previously exposed via the `Repeater` that was aliased as
`chatListItems`.
StatusQ now exposes `statusChatListItems` additionally so we can still access `model.itemAt`
which is used in this commit.
The only reason this is done here though, is because we need to update the profile picture of
contacts when we get a contact changed signal. Ideally, we handle contact changes including the
profile picture entirely in the backend and have it then just rerender the screen (instead of
using a `Connection`).
Fixes#3328
There were two issues why mentions didn't work in communities:
1. The function that replaces mentions with pubkey looked in the wrong place
2. The same function always prepented `userName` with `@` which isn't always necessary
This commit fix this by ensuring the replacement function looks in the community memberlist
instead of a messageList and also by checking if a `userName` already starts with a `@`
and only prepends it if not.
Fixes#3492
Sale Djenic
Michael Bradley, Jr
Iuri Matias
Eric Mastro
Anthony Laibe
Khushboo Mehta
Alexandra Betouni
Andrei Smirnov
Pascal Precht