Prior to this commit, we would only set the translation package for the
application's engine when `appSettings.locale !== "en"`.
This is problematic because it seems that `engine` is already provided with
a system default that may not be `en`. In practice, this means that, initially,
engine is loaded with, say `de`. `appSettings.locale` might be `en` but because
we're only loading the correct translation package when it's **not** `en`,
the application will stay in `de`.
Changing the language to `en` at runtime is fine, however once the application
is restarted, `engine` is again initialized with some other possible system default.
It seems that we should *always* load the translation packge when `appSettings` are
loaded.
When contract addresses that are not ERC-20 or ERC-721 were input, the token would be allowed to be added and would crash the app.
In addition, when an ERC-20 contract was deployed without a name and symbol, “Invalid ERC-20 address” would appear.
This PR adds error checking from the token detail lookup and reports the error back to the user in the modal. This prevents non-ERC-20/721 contracts from being able to be added to the app and prevents a crash.
Alright, this is an interesting one:
As described in #1829, when the profile popup is opened within the chat view,
users are still able to click *through* the popup on message, which then puts them in
an active state.
I've done a bunch of debugging as described [here](https://github.com/status-im/status-desktop/issues/1829#issuecomment-804748148) and after doing some
further debugging, I found out that `isMessageActive` isn't really the culprit here.
What causes this effect is the `HoverHandler` that's attached to the `CompactMessage` item.
`HoverHandler` is a standard QML type that emits `hoverChanged` signals so one can do things like
applying hover effects on elements, which is exactly what we do:
```
HoverHandler {
onHoverChanged: {
root.isHovered = hovered // `root` being the message item
}
}
```
I assume we went with this handler because putting a `MouseArea` in there instead, which fills
the entire message component pretty much eliminates all existing mouse handlers attached to
other child components, such as the profile image or the username of the message, which also
open a message context menu.
It turns out that, having a `HoverHandler` as described above, actually activates it when the
user clicks with the left mouse button as well (not just on hover). That's what causes the "click-through"
effect. This can be verified by setting `acceptedButtons` to `Qt.RightButton`, basically telling
the handler that only right clicks will activate it.
I then tried using `Qt.NoButtons` instead so that no button clicks and only hovers will activate
the handler, but that didn't seem to have any effect at all. It still defaults to `Qt.LeftButton`.
So the last resort was to disable the `HoverHandler` altogether, whenever either the profile popup,
or the message context menu (for emojis etc) is open.
Unfortunately, we don't have access to the profile popup in the compact message component, because it's
detached from the component tree. Therefore, I've introduced a new property `profilePopupOpened` on
the chat layout, which we can read from instead.
Fixes#1829
This commit introduces a `reset()` function so that search results inside
the application can be easily reset. It also introduces a `resultClickable`
flag which allows consumers of this component to decide whether a search result
is clickable and emits a dedicated event.
This is useful when UIs should only allow actions via the result icon button
(as it's the case with the new add-to-contact modal).
This change aligns the member list's look & feel of the community profile popup
with the designs by implementing the proper member list items styles, hover effects
and fine-tuning the context menu.
This commit also comments some of the actions provided by the context menu,
which aren't implemented yet. There's no point in having UI components that don't or
can't function.
Those will be re-introduced once they are actually implemented.
Closes#1959
Since https://github.com/status-im/status-desktop/commit/93668ff75
we're hiding the setting to change appearance for compact normal mode
of the UI. For now, compact mode is the new default (reasoning is unclear
at this point).
Prior to this change, most likely many users are still using the
normal mode configuration, so we have to enforce compact mode for
those.
The designs for the membership request button look different now, so this
commit makes use of the `StatusSettingsLineButton` to implement that new
look & feel.
Prior to this commit, the community memberlist was represented in a nested modal
which doesn't adhere to the designs. Rather, the section should render inside the
existing modal, requiring it to be refactored using a `StackView`.
This commit refactors the community profile popup so that the different content
sections ("Overview" and "MemberList") are rendered inside of the popup and can
be pushed onto and popped off a stack view.
The content components (newly introduced in this commit) `CommunityProfilePopupMembersList`
and `CommunityProfilePopupOverview` need to define a `headerTitle`, `headerDescription` and
if needed `imageSource` so they can alter the modal's header.
The same pattern might be used in other places of the modal if required.
Partially fixes#1959
Allow up to 5 images to be dragged and dropped in to one-on-one chats and in the timeline. Can be combined with the existing upload button. The upload file dialog has been changed to allow multiple selections. Drag and dropped images adhere to the following rules, with corresponding validations messages:
- Max 5 image
- Image size must be 0.5 MB or less
- File extension must be one of [".png", ".jpg", ".jpeg", ".heif", "tif", ".tiff"]
Drag and drop and uploaded images are now also deduplicated.
This was hardcoded into `isAdmin` for some reason. It also seems that the
property isn't actually used anywhere in the profile popup, so we might
as well get rid off it.
The `communityProfilePopup` relies on the currently `activeCommunity` to
get its data. Unfortunately, once read, even when `chatsModel.setActiveCommunity()`
is called which triggers `activeCommunityChanged`, the data in the popup
won't be updated. The next time one would open a community profile page,
it'd have the data that was previously received from the model.
This commit ensures that the popup is hydrated with the most recent data
by explicitly updating its properties right before it's opened.
Prior to this commit there was a scenario where the application would
crash due a memory bug when attempting to (re)join a community.
The scenario is as follows:
1. User creates or has been invited to community with `ON_REQUEST` permissions
2. User leaves community
3. User decides to rejoin, so she selects the community she's been part
of and hits the "Join" button
At this point Status Desktop would send a new `RequestToJoin` request, as the
community has a corresponding permissions setting.
This would then result in an `already a member` error in status-go, because
status-go checks whether the requestee is already part of the members list of
the community. The error isn't handled inside Status Desktop which causes
a crash because we're trying to access data in memory that doesn't exist.
Why is this happening?
While this might be unexpected, when leaving a community (as done on step 2 of
the mentioned scenario), users don't actually lose membership but simply
"unsubscribe" from all channels in the community in question and their `joined`
flag is set to `false`.
From that point on, re-joininng a community is done by sending a `JoinCommunity`
request (instead of `RequestToJoin`), which will then set the `joined` flag to
`true` and doesn't actually check the membership in the database.
This commit ensures we're calling the right API by checking whether not only
whether the community is needs `ON _REQUEST` permissions, but also whether the
user isn't already a member of it.
Fixes#2017
In https://github.com/status-im/status-desktop/commit/a90a30af1 we've introduced the functionality to import
communities through the UI via a community private key.
That private key is being validated before it gets imported.
For some reason, validation has been removed in another refactor
later on in https://github.com/status-im/status-desktop/commit/534cb23e1, rendering the import
functionality broken.
This commit re-introduces the `validate()` method to make importing
communities work again.
Prior to this commit, communities without an image would render invisible
in the navigation bar of the application. To avoid this, we're now falling
back to our StatusLetterIdenticon component, which renders the first letter
of the community name with the color of the community.
When a user is part of a community, write access to any channel of
that community is granted. When the permission allows for it, a community's
channel `canPost` property is `true`, which should be relied on to
render the necessary component for writing into a channel.
This commit makes sure community members with proper access get the
chat input rendered so they can write to channels.
Fixes#1985
Very similar to #1986, we're trying to access the `activeCommunity`
property on the `chatsModel` object, which doesn't have such a property
anymore every since we've moved communities into its own view.
This causes errors when trying to create channels.
This commit fixes this bug by ensuring `activeCommunity` is accessed
from `chatsModel.communities` instead.
When the communities code was moved into its own view in https://github.com/status-im/status-desktop/commit/b38d1df59
it broke the functionality to join communities again.
Qt complains that the Nim API in use `chatsModel.communities.joinCommunity`
expects two parameters, when it's call with just one.
This is unexpected because the API in question set a default value
for its second parameter.
To make this work again, we have to make sure the `setActive`
parameter is supplied every time we call the API from
within QML.
Also, worth noting that this is not the first time we're running into
a scenario like this.
Turns out in https://github.com/status-im/status-desktop/commit/81bb7fcc6 we've introduced a regression where
leaving a communities isn't possible anymore because we're trying
to call an API that doesn't exist on the `chatsModel`.
This commit fixes it by ensuring the API is called from `chatsModel.communities`.
Updated community popup menu btn style. Fixes#1961
Updated community popup menu btn style. Fixes#1961
Updated community popup menu btn style. Fixes#1961
Updated community popup menu btn style. Fixes#1961
For an unknown reason, when the `chatLogView` ListView uses
a `verticalLayoutDirection: BottomToTop`, it prevents the application
from successfully rendering during login and crashes.
From debugging this, we know that this only happens when the above
condition applies *and* when a `DelegateModel` is used.
The delegate doesn't even need proper data, it application would still
crash.
We found out that the crash can be avoided when another `ListView` exists
in this component (however it's unclear why).
For now this commit adds such a placeholder `ListView` until it
we know more about what's going on.
In some cases inside of 1-on-1 chats, the fake messages added to
the beginning of the message list, wouldn't determine the correct
username of the contact in question.
This commit explicitly calls `chatsModel.userNameOrAlias()` instead
of relying on `activeChannel.name` which tries to do the same.
This commit adds a menu item to the message context menu to
copy links that may exist inside of a message.
There are three possible scenarios:
1. There's no link in the message, which causes the menu to not
render the dedicated menu item at all
2. There's one link in the message, which renders an additional
`Action` with a copy-to-clipboard functionality
3. There are multiple links in a single message. This adds a
nested `PopupMenu` in the existing menu with menu items for each
link extracted from the message
To make this work there were some changes in the `PopupMenu` component
needed, as it wasn't take the sub menu's `enabled` state into account
properly. This makde it always render nested menus even when they
should've been invisible.
Closes: #1733
Having the Timeline component loaded eagerly made switching
between channels rather slow because it always tries to read
the current message list from the chats model.
This commit changes the layout so that the timeline layout container
is only loaded conditionally when indeed activated.
This commit introduces the new design and behaviour of the modal
that opens up when starting a new 1-on-1 chat.
Main changes include:
- New search UI/UX functionality of users and ENS resolutions
- Composed view of existing contacts and contacts to be searched
- Ability to add contacts from within the modal
Closes: #1747
This was missing in one of our previous PRs and causes the
channel context menu to not function properly e.g. when deleting
chats, it currently always deletes the first chat in the channel list
instead of the active channel.
There's a bug in the `SetCurrencyModal` where it runs into a callstack size
exceeded error because we're calling it's `open()` API to open itself.
That function happens to call itself again and again.
The reason that API was introduced in the first place, was to ensure that
the configured default currency is reflected currectly.
This commit fixes that issue by getting rid off the `open()` and `close()`
APIs which cause the mentioned error, and rely on `openPopup`'s parameters
configuration instead.
There's a bug in the profile popup where we're calling an API that
actually doesn't exist. This commit fixes it by calling into the
correct `profileModel` member, to make unblocking users work.
There are some inconcistencies in the application when it comes to
button UI elements because we're using `StatusButton` in some places,
in other we use `StyledButton`. The latter is the original
component we've created when we started out building Status
Desktop, but is planned to be removed entirely in favour of
`StatusButton`.
This commit replaces the usages of `StyledButton` with `StatusButton`
There are some places in the application where a custom round
button has been implemented, which essentially can be realized
using our `StatusRoundButton`. This commit addresses those cases.
There's a but in the app's profile section where the link to
invite friends is never rendered, even if the currently logged-in
user has no added contacts.
This is because the UI refers to the count of *all* contacts the
user has (even removed ones - remember that, once added, removing
a contact is only done by removing a tag).
This commit ensures that the invitation link is rendered by
relying on the *added* contacts list. It also prevents the
"blocked contacts" button from rendered when there's no blocked
contacts.
redesigns the compact mode to have a nice hover, easier replying and adding reactions and more
Missing parts are aligning chat command, images and unfurlings, redesigning mentions and the channel list and also trying to find a way to re-enable link hovers in the text
This commit does a bunch of things:
- First and foremost, it removes the active channel dependency.
This is needed to have it operate on the correct channel object,
without forcing us to change the active channel (e.g. right-clicking
on a channel item that's not active, will make it active eventually)
- To make that work, this commit changes the `ChannelContextMenu`
to receive a `ChatItemView`, so it can be used for things like determining
what menu options are shown, what members are in a group, whether
someone is admin of a group etc.
- This also required a new `QtProperty` called `contextChannel`.
The reason this is required, is because in some cases, like receiving
members count of groups, we need a complete `ChatItemView` object
as we don't have access to certain APIs otherwise.
- Unfortunately, we can't pass down `activeChannel` every where for that
because sometimes the context menu should not actually operate on
the active channel.
Fixes: #1755
This commit introduces a new `ChannelContextMenu` component that can be reused
in different places, such as the channel list, as well as the chat bar.
At the moment we use two different pop up menus that also show two different
set of menu options. By using `ChanelContextMenu` in both of these places,
we get the same menu and same experience.
Closes#1711
This is a new form control component to select colors for wallet
accounts. It will replace the currently used `ColorSelect` in the
Status Desktop application so it aligns with the new designs.
Closes#1497
This introduces a new component to render Addresses that can be
expanded as well as copied using `CopyToClipBoardButton`.
While there's already an `Address` component that allows for expansion,
it doesn't give us control over it's look and feel and, should rather
be a `Button` anyways.
There's also cases in the application where we render a collapsed address
and don't allow for expanding it. In such cases, we might not want/need
a button at all.
Might make sense to introduce a separate address component that just shows
a collapsed address without any behaviour, which can then be used inside
`StatusExapandableAddress`.
Closes#1633
fixes#935
A bug occurs when someone requests a large amount of funds from you since the gas estimation will fail and there isn't a way of handling errors in the source yet.
This PR handles the error appropriatley for both `estimateGas` and `estimateTokenGas` where the response is only converted from hex to int if the RPC call was successful. Otherwise return the error message as the response and let the UI decide how to display it.
Currently the error for gas estimation in transaction bubbles is displayed in a popup however, ive come to realize that 2 popups open instead of one. This is a new bug of which I can't pinpoint the root cause at the moment and have opted to file a separate issue for it.
Adding a contact through the Add Contact Modal isn't working because the
function being called to add a contact doesn't actually exist.
This was most likely a mistake as the change was just to call that function
in question from a different property.
This commit does exactly that.
Fixes#1660
Setting the default currency through the UI doesn't work because of a `MouseArea` that
is masking the an underlying `StatusRadioButton` which will tricker the default currency
change.
This commit enhances the `MouseArea` to trigger the default currency change and it
also ensures the UI is responding accordingly. Namely that the new default currency
is correcly selected in the list of currencies.
There's also a little change in the background hover color so it works well across
light and dark themes.
Fixes#1632
This commit does a couple of things:
- It changes a label in the wallet menu from "Add/remove Token" to "Manage Assets"
as it has been designed
- It changes the asset list so a hover state could be introduced. Previously there
was no visual effect or response to mouse hover on asset items
- It improves usability of the asset list by making an entire asset item
clickable to toggle the asset in the wallet. This was not possible before.
Users had to click the checkbox achieve this effect
Closes#1631
This commit makes reactions in the status timeline work.
There are two things prior to this commit that are broken:
1. The logic that opens the reaction context menu always expects
and instance of `chatsView` because it tries to calculate a users
nickname. Such an instance isn't always available in that context, so
the nickname logic has been moved to `appMain` for now, removing that
dependency and therefore making it work in both, the chat view as well
as the status view.
2. While 1) makes the context menu work, it turns out that adding and
removing reactions inside the status timeline is still not working.
The reason for that is, that the reactions component maintains its own
`messageList`, which isn't aware of the fact that reactions for messages
coming from chats of `ChatType.Profile`, need to go into a dedicated
message list for `ChatType.Timeline`.
In other words, reactions are sent and removed from message in messagelists
that don't actually exist.
This commit fixes both of these things by ensuring the message lists
maintained by reactions are timeline aware. Also ensuring updates are
done correctly.
`StyledButton` is considered obsolete and by using `StatusButton` we're getting
the expected and correct look & feel of buttons by default.
Closes#1627
The contact list was taking the entire width of its surrounding element,
making it grow too wide to be usable (see #1589).
In fact, it's not following the designs made for this part of the application,
so this commit changes the max layout width to align with the intended
design and should also fix some of the usability issues mentioned in #1589Fixes#1589
The "more actions" button in the contacts list had some hard coded colors
for its hover effect which break the experience in dark mode.
This commit makes changes those so that they work universally.
Prior to this commit, the function was expected on a `chatView` QML object.
This has worked out so far because the places where the API is used were always
living inside `ChatLayout`.
With the new timeline however, this is no longer the case so we have to make sure
that the API is available to other views as well.
This commit introduces some `MouseArea`s so components inside the
`StatusUpdate` component cancel it out by having a higher `z`.
Also, in some cases we need to conditionally set the `root.hovered` property
to ensure the values get inverted correctly, otherwise it causes undesired
flicker effects.
Fixes#1377.
Fixes#1479.
Two sites have been added to the whitelist: giphy.com and tenor.com.
`imageUrls` in its entirety has been removed and instead all links are being handle through the message `linkUrls`. This prevents double-handling of urls that may or may not be images.
The logic to automatically show links previews works like this:
1. If the setting "display chat images" is enabled, all links that *contain* ".png", ".jpg", ".jpeg", ".svg", ".gif" will be automatically shown. If the URL doesn't contain the extension, we are not downloading it. This was meant to be somewhat of a security compromise as we do not want to download each and every link posted in a message just to find out its true content type.
2. If the above setting is *disabled*, then we follow the whitelist settings for tenor and giphy. This allows us to preview gifs that do not have a file extension in their url.
feat: bump status-go to the commit that supports the new whitelist (https://github.com/status-im/status-go/pull/2094), and also lets us get link preview data from urls in the whitelist. NOTE: this commit was branched off status-go `develop`, so once it is merged, and we update this PR to the new commit, we will effectively be getting status-go develop changes. We *could* base that status-go PR off of master if it makes things easier.
fix: height on settings update issue
feat: move date/time of message below links
fix: layout issues when changing setting `neverAskAboutUnfurlingAgain`
feat: Add MessageBorder component to aid in showing rounded corners with different radius
This is needed when accessing the context menu from the timeline status updates.
Previously, it'd only change the active channel because it assumed the user is already
in the chat view. This is no longer the case when in timeline view, so we need to make sure
we first navigate to the chat view.
YouTube link unfurling was not working for a couple reasons.
There were two main parts fixed:
1. QML context for messages pertaining to linkUrls and imageUrls was changed from implicit to explicit. By this, I mean that any time we referenced linkUrls/imageUrls, we were relying on the knowledge that those values would be populated by some parent context several levels up. Now, we are referring to properties that have been explicitly defined on the components. This offers the ability to reuse components, and makes reading the code and debugging much easier.
2. Error handling has been added to getting link preview data. An unhandled "error" was thrown each time a link that wasn't whitelisted was passed in, causing the app to crash. For example, when a link to a tenor gif was posted in the chat, that URL was not whitelisted, causing the app to crash.
In timeline status update messages we want to render the ENS name next to a
local nickname in case it exists. This commit extends the `UsernameLabel` to do
just that.
Closes#1488
StatusChatInput was relying on the suggestions ListModel, even though there was
no guarantee that it would exist. This is more apparent when using the component
in different context (e.g. Timeline/Status Updates). QML will throw a reference
error in this case.
`StatusChatInput` ideally shouldn't rely on chatsModel and other global
objects at all. Also, when using the component in different places, it can cause
accidental sending of message when testing the component (because all the logic is already
wired up)
Jonathan Rainville
Iuri Matias
--replace-all
Pascal Precht
Eric Mastro
Richard Ramos
ace-smart
staked-smart-ace
Malik Al-Jabr
Michael Bradley, Jr