This was lost during the refactor to use StatusQ components because it wasn't
clear to me that community channel descriptions should be rendered there.
Fixes#2982
Fixes#2434. Modals that were affected by this issue were
- RegisterENSModal (for registeing an ens username)
- SetPubKeyModal (for changing the contact code of an already owned ens)
- StatusStickerPackPurchaseModal (for acquiring a sticker pack)
When right-clicking a community from the navbar and selecting "View community", Status Desktop
opens `CommunityMembersPopup` which looks like it was either never really finished or more of an
intermediate solution until a proper community profile popup was created.
That's why this commit replaces it with a `CommunityProfilePopup` instead.
In fact, this lead to changes in `CommunityProfilePopup` where the `activeCommunity` dependency
is entirely removed, which allows us to use this popup in various places given that it's hydrated
with proper data.
Because we're no longer relying on `activeCommunity` inside that popup, all of its children and
connected popups needed that same refactor as well, hence this PR introduces a few more changes.
Closes#2890
This replaces the modal popup with `StatusModal` in the `CreateCommunityPopup`
and also ensures that it adheres to the design.
There are still things to be refactored in here, primarily form control components.
Those will be tackled in future commits once they have been built in StatusQ
Closes#2882
There was a change in StatusQ that introduced dividers for modal footers
and headers, so we don't need to put them in the content manually anymore.
This commit removes the no longer needed ones.
Toast message is added when user access an existing community using community's private key. Toast
message with message that importing community is in progress is displayed while community is being
imported and once it is imported toast is closed and new one, which will be closed in 4 seconds,
with message that community is imported is displayed.
Fixes: #2467
* Text copied from clipboard that included images
and other rich content was not visible in text
box when pasted, modified to keep only plain
text instead and removed unnecessary funtions
* Also removed unecessary Rectangle in Input
Closes#2650
The reason for this issue is a message where recipient accepted to share his address with sender.
In that message recipient's public key is set as a "from" property of a "Message" object and we
cannot determine which of two users has initiated transaction actually.
This is fixed checking if the "from" address from the "commandParameters" object of the "Message"
is contained as an address in the wallet of logged in user. If yes, means that currently logged in
user has initiated a transaction (he is a sender), otherwise currently logged in user is a
recipient.
We were just sending a transaction, without notifying message about that. Now we call
callPrivateRPC("acceptRequestTransaction".prefix, %* [transactionHash, messageId, signature])
and that notifies message about the change, but only on the sender side. Appropriate message
on the recipient side was not notified about the change. That need to be checked.
This commit refactors the `CommunityProfilePopup` to use `StatusModal`. Since it's made of
various popup content components, it also updates the memberlist, the overview and the
invite friends view, so it doesn't break the UI along the way.
Closes: #2885, #2887, #2888
There are two regressions introduced in 080767c338 where
the `CreateChannelPopup` isn't properly centered when triggered in edit mode,
and that the channel name field isn't hydrated with channel data.
This commits fixes both bugs.
This bug is happening if you have more than one private chat in the contacts column. How many chats
you have that many same notifications you will get. That's happening cause connection is made
between chatsModel.messageView and ChatsMessages component for each private chat, and for each of
them ChatsMessages component is maintained in StackLayout component what means all of them are
exist but only selected instance is visible. When new messageNotificationPushed signal is emitted
each qml component triggers its slot (regardless component is not currently visible it exists in
the background, it's not deleted) and that's why we see more than one OS' notification bubble for
the same notification.
That is fixed moving slot from ChatMessage component to ChatColumn component.
Fixes: #2551
The chat navbar tab button renders an indicator when there's unread messages
in any of the chats. It also renders a message count, which prior to this commit
equals to the number of total unread messages.
This however is not the desired behaviour. Instead, the count should be the total
number of unread one on one messages (DMs), plus the total number of mentions in any
chats the user is participating in.
This commiit ensures the correct message count is rendered. It also adds an "unread messages"
indicator to community buttons.
Closes#2869
Also fixes a bug where if the search was cleared, messages would after that appear all on top of each other.
Also leaves the popup live after closing so the search can be gone back to
The issue is happening randomly. I managed to catch it few times and hopefully fix it. Problem was
in leave proc in src/status/chat.nim cause we were sending activeChannelChanged signal from it what
started setting activeChannel to the value of the backToFirstChat variable, and while that process
was in progress setActiveChannelByIndex was called from activeChannel what caused another emit of
activeChannelChanged signal while the previous one was not completed. That caused new setting of
activeChannel with active channel index 0, what caused an app crash.
This is fixed by setting active channel to the first one from the list when we get a signal that
any channel from the list is removed. This way activeChannelChanged is broadcasted to the other
parts correctly.
Fixes: #2825
This issue is being happened randomly, no general rule, in my case it happens often when you accept
first contact from the list immediately after the app start, but the ticket says that it happens
when you click accept while context menu is opened.
Two places were threat for this crash and both are fixed here:
- getChannel proc, direct access by index to Chat element of the chats sequence,
- setChatItem proc, where we actually were setting chatItem and accessing its property without
checking if it is an empty object.
Fixes: #2837
A crash is happening not only when you click on a notification bubble with mentions, but on any
chat notification displayed in macOS' notification center. Discussion and details how we can
overcome this may be seen on zenhub, in issue 2819. So far this commit is just a simple solution
to avoid an app crash.
Fixes: #2819
This commit replaces the `TopBar` components with StatusQ's `StatusChatToolBar`
and touches a few other things as part of this refactoring, namely:
1. `ChannelContextMenu` has been renamed to `ChatContextMenu` and is now a `StatusPopupMenu`
2. Leftover components have been removed: `StatusChatInfo`, `StatusChatInfoButton` and `TopBar`
3 `ActivityCenter` has been moved into `ChatColumn.qml` because `StatusChatToolBar` doesn't provide it
4. `Share chat` option in `ChatContextMenu` has been removed as it wasn't doing anything.
Closes#2746
This commit replaces `CategoryList` and `ChannelList` with `StatusChatListAndCategories`,
`StatusPopupMenu` etc. provided by StatusQ.
It also removes components that lived inside Status Desktop but are no longer used
anywhere after the refactor.
Since StatusQ components are decoupled from UI model logic, we also needed to introduce
a new API retrieve a community category from within QML.
Closes#2805
A reason why the crash is happening is actually previous step, when an user who is about to receive
a transaction clicks "confirm and share address" button. In that moment instead of his address an
empty js object is shared. After that clicking on the "sign and send" button, by sender, causes an
app crash because transaction cannot be made using invalid address of the recipient.
Fixes: #2718
Mark all mention notifications as read is fixed. Also mark as read one by one notification removes "@" from the appropriate channel along with the marking as read last mention notification for that channel. hasMention field which was bool is switched with mentionsCount field which is int, so we have evidention how many mentions were for each channel.
Fixes: #2788
Fixes: #2725.
When clicking on the History tab for a wallet account, there was a QML error for `qrc:/app/AppLayouts/Wallet/WalletLayout.qml:113: TypeError: Property 'checkIfHistoryIsBeingFetched' of object HistoryTab_QMLTYPE_503(0x7fed35da2710) is not a function`. This must have been reintroduced when StatusQ objects were introduced. It has now been removed.
chore: change log level to warn for non-archival node
Previously, there was an error being logged for non-archival infura nodes being used (typically in dev). This log level has been reduced to a warning as the application still functions with non-archival nodes.
Validation check is updated, so user cannot enter zero or less than zero value for "gas amount limit" or "per-gas overall limit".
In gas.nim a crash prevention check is added.
Fixes: #2753
Validation check is updated, so user cannot enter zero or less than zero value in amount input field.
Also in utils.nim a crash prevention check is added so if we try to convert a less than zero float number to an unsigned number, app won't crash any more, but that casting will return a zero as unsigned int number.
Fixes: #2755
This first step in leveraging StatusQ components. This sets up the overall
app layout, allowing us to use other sub view layouts provided by StatusQ,
such as `StatusAppTwoPanelLayout`.
This commit primarily touches the application navbar, leaving layout changes
in dedicated views for future commits.
Partially closes#2688
This integrates the StatusQ Theming system and updates the selected
theme based on existing APIs, allowing it to live side by side next
to the legacy theming system.
Closes#2687
Fixes: #2649.
Upon receipt of status-go signals which included communities that have been left (`joined: false`), those communities were being rejoined automatically when they should not have been.
fix(communities): Invitation bubble button state updates
The community state inside of the invitation bubble was not reactive to any community actions (such as joining, leaving, updating). In addition, requesting to join a community changed the button’s text to “Pending”, but upon approval, the button’s state was not updating.
The component was setting an observed community in the Component.onCompleted event, which was occurring for all invitation bubbles, but because the community wasn’t bound correctly to the bubble, once a bubble with a different community was encountered, the community in context of the bubble wasn’t updated and instead used a local copy. Once the community was bound correctly (to be reactive), the states started working correctly.
The invitation bubble has been simplied so that it has states instead of using lots of if/else statements inside of the property bindings. This simplified the component’s logic for things like onClick action and made it a lot easier to read and modify.
add getSettings methods to src/status
fix issue with calling getSettings; document issue
remove most direct references to libstatus; document some common issues
remove most references to libstatus wallet
add mailserver layer to status lib; remove references to libstatus mailservers
remove libstatus accounts references
move types out of libstatus; remove libstatus types references
remove libstatus browser references
refactor libstatus utils references
remove more references to libstatus stickers
remove references to libstatus constants from src/app
remove more libstatus references from src/app
refactor token_list usage of libstatus
refactor stickers usage of libstatus
refactor chat usage of libstatus
remove libstatus references from the wallet view
remove logic from ens manager view
fix issue with import & namespace conflict
remove unnecessary imports
refactor provider view to not depend on libstatus
refactor provider view
refactor: move accounts specific code to its own section
fix account selection
move collectibles to their own module
update references to wallet transactions
refactor: move gas methods to their own file
refactor: extract tokens into their own file
refactor: extract ens to its own file
refactor: extract dappbrowser code to its own file
refactor: extract history related code to its own file
refactor: extract balance to its own file
refactor: extract utils to its own file
clean up wallet imports
fix: identicon for transaction commands
Fixes#2533
Fixes: #2486.
In the community member managment popup, for the current user, remove the “more actions” menu that allows kicking of the user and viewing of their profile.
Fixes: #2601.
Kicking a user and re-inviting them now correctly redisplays the join/decline options. Other combinations of User B leaving or declining an invitation are not handled. Please see the notes below for clarification.
Additionally, the group invite popup (that shows the list of members belonging to the group) correctly shows when a user is kicked or when a user leaves the group in real time. Previously, the popup needed to be reopened to display this.
fix: decline invitation crash
Declining a group invitation was crashing the app. This has been fixed.
### NOTES
1. In the case where User A invites User B to a group, but User B declines (or User B joins, then leaves), then from a status-go standpoint, User B is still part of the group, but the chat is marked as `active: false` for User B. This creates a situation where User B cannot re-join the group once s/he has declined the invitation. @cammellos mentioned there possibly will need to be a refactor of cab6281dc5/protocol/messenger.go (L1710) (which, by retaining User B as a member, effectively prevents the re-invitation) once “swipe to delete” is implemented on mobile. There is an activity center notification received for User B that is meant to allow re-joining of the group when the notification is accepted. The activity center notification received from status-go looks like the following:
```json
"activityCenterNotifications": [
{
"id": "0x0e342d33",
"chatId": "e342d33f-dd05-4d7b-b14e-b5335e1a3ee9-0x043bf46aa874c377a34946eab67a32cf36c15907b328216dfce375d169fed7d81c21cada3229db1fd37c762d2c02702111a646657feca6621e2e948febcf378fb4",
"name": "test-22",
"type": 2,
"lastMessage": null,
"message": null,
"timestamp": 1623305612000,
"read": false,
"dismissed": false,
"accepted": false
}
]
```
Fixes: #2539.
Transaction history is now correctly being fetched from status-go as per mobile. Firstly, when accounts are added (ie as watch accounts), `wallet_checkRecentHistory` must be called first so that the status-go db is populated. After that, `wallet_getTransfersByAddress` can be called. On app load, when we run the `initBalance` logic, we are calling `wallet_getTransfersByAddress`, asking for the last 20 transactions with the `loadMore` parameter set to false. When the user navigates to the Wallet > History tab, they can then click “Load More” to fetch more transactions from status-go. Once the number of transactions returns false below the expected amount, the remaining transactions to fetch have been exhausted and the “Load More” button is disabled.
feat: add non-archival node warning to the UI to indicate to the user that they may not have complete results
feat: set active account to the added account
Once an account is added to the wallet, that newly added account is selected as the active account.
1. The “load more” button is active when new transactions that aren’t already displayed are returned from `wallet_getTransfersByAddress`. This is the only way to enable or disable the “Load more” button as status-go is not able to return information regarding whether or not there are more transactions to be fetched. The downside to this is that lets say the last page of transactions is returned, but there are no more pages left. These returned txs are not currently displayed, so the “load more” button will still be enabled. However, the next click of the button will return 0 results, thus disabling it. It’s effectively an extra click to get to the disabled state.
2. For more information on how the `toBlock` parameter operates for the `wallet_getTransfersForAddress` RPC call, see https://notes.status.im/XmENTrVRRaqhwE4gK0m8Mg?view.
Closes#2344.
Add ability to edit name, description, and private fields of a community channel.
feat: Display community channel description
Ensure the width of the description does not surpass the context menu and instead wraps to the next line.
feat: After channel is created, set it as the active channel
For new and existing communities, force the `require approval` membership requirement in the create/edit community popup.
### NOTE
This will not affect the membership requirement value already-created communities.
When inviting contacts to a community, Status Desktop suggests a list of
all contacts, even if contacts of that list are already members of the community.
This commit introduces a new flag to `ExistingContacts` component that
allows for configuring whether community members should be hidden or not
Fixes#2502
Due to historic reasons, conditionally assign a font size for the letter
identicon, based on whether or not the app's compact mode is active.
Compact mode has become the new default a while back and the component's
`isCompact` property isn't set anywhere in throughout the application,
resulting in `letterSize` to always be `21`, which is too big.
This commit removes the condition, defaulting to always having a letter size
of 15 pixels as designed.
Fixes: #2365.
Previously, suggestions for mentions were showing profile pics even for users who were not contacts. Now, profile pics are only shown for those users who are contacts. The user’s identicon is shown otherwise.
fix: user thumbnail not shown when no profile pic
When a user was a contact, but didn’t have a profile pic, an image would not be loaded and a ‘reload’ image would be shown instead. With this PR, if the user is a contact and they do not have a profile pic, their identicon will be shown instead.
Fixes#2448.
Currently, if a wrong password is entered when generating a wallet account, the app will crash due to attempting to decode a `GeneratedAccount ` from an rpc response containing only an error.
With this PR, we are detecting if an error is returned in the response, and if so, raising a StatusGoException. This exception is caught in the call chain, and translated in to a `StatusGoError` which is serialised and sent to the QML view, where it is parsed and displayed as an invalid password error in the input box.
refactor: remove string return values as error messages in wallet model
In the wallet model, we were passing back empty strings for no error, or an error as a string. This is not only confusing, but does not benefit from leaning on the compiler and strong types. One has to read the entire code to understand if a string result is returned when there is no error instead of implicitly being able to understand there is no return type.
To alleviate this, account creation fundtions that do not need to return a value have been changed to a void return type, and raise `StatusGoException` if there is an error encountered. This can be caught in the call chain and used as necessary (ie to pass to QML).
refactor: move invalid password string detection to Utils
Currently, we are reading returned view model values and checking to see if they include a known string from Status Go that means there was an invalid password used. This string was placed in the codebased in mulitple locations.
This PR moves the string check to a Utils function and updates all the references to use the function in Utils.
This commit does a couple of things:
- add StatusQ as a dependency (https://github.com/status-im/StatusQ)
our emerging component library
- updates the rcc generation script to follow symlinks as well
- add qrc:/./StatusQ/src as import path
At the time of creating this commit `StatusQ` provides only the StatusIcon
component, but more will be added in the future.
Fixes#2419
Makes it so the private key is elided by default so you can see it all from the get-go. If you focus the field, the key will "unfurl" and you can copy it manually.
Otherwise. the Copy button will always copy the whole key
Fixes: #2364
The Send Message button click event was erroring due to a refactor that had been done to allow for changing app sections.
This has been updated to follow the current way to change app sections.
fix: “Send Message” button crash in communities
This required switching from communities to normal view.
fix: crash when clicking channel link in community message
When a message in communities contains a link to another channel (ie #otherchannel), the search for this channel needed to be updated to also search for the channel by name, allowing for switching between channels within a community by message link. Additionally, when in a community, if the channel was located in a normal chat, it will switch the view to the normal chat after being found.
Fixes: #2257.
If a user had selected a watch-only address in the wallet, the backend `walletModel.currentAccount` property would also change. When loading a transaction modal, this property was used to set the `selectedAccount` value for the “from” `AccountSelector`, regardless if the account was a watch-only address.
This PR updates the logic for `selectedAccount` such that it will only allow the account to be selected if it is not a watch-only account.
A `StatusIcon` that rotates infinitely and can be used for indicating
pending states.
Usage:
```
StatusLoadingIndicator {
width: 24 // default: 17
height: 24 // default: 17
color: "red" // default: loading asset color
}
```
This also removes `LoadingImage` component from `ui/shared`.
Closes#2360
This introduces a new `StatusIcon` component to the component library,
including various icon assets.
The component can be used to render icons in different colors and rotations.
It's also one of the atomic components that can be used to build other
more complex components like icon buttons.
Usage:
```
StatusIcon {
icon: "arrow-right" // name of asset file in `ui/shared/status/assets/img/icons
width: 24 // default: 24
height 24 // default: 24
color: "red" // default: asset file color
rotation: 0 // default: 0
}
```
Closes#2330
Fixes: #2248.
Add a close button to the seed backup warning banner in the wallet. The banner will reappear upon application restart as long as the seed hasn’t already been backed up (`profileModel.mnemonic.isBackedUp`).
A new .svg with a white outline needed to be added as well because the original “close.svg” had a purple outline, which would show up when the ColorOverlay applied to the close button had an opacity less than 1.0.
The popup to invite friends to communities has so far always been a brand new
popup that's opened on top of possible existing popups.
The design however, expects that the same section should be shown as part
of a wizard-like process inside of the existing community profile overview
popup, when entered from there.
This commit extracts the invite friends popup section into component that
can be reused as stack view, as well as modal content, to implement both
scenarios.
This commit changes a bunch of things related to ui bugs in the community
profile popup. Fixes include:
- Removing the `Delete Community` option since this functionality isn't implemented yet
- Changing the color of the menu item's icons in dark mode to be blue
- Doing the same in the memberlist popup
There's a regression in the application where kicking members from communities
doesn't work anymore. This was due to UI logic being moved to a different model
without updating the corresponding view action.
Fixes#2274
Prior to this commit, only admins of a community could open up the community
profile popup from inside the community. However, normal members should be able
to do so too.
Normal members shouldn't be able to create channels, nor should "leave
channel" be an option of the context menu provided inside of a community.
This commit removes these.
As discussed in https://github.com/status-im/status-desktop/issues/2144#issuecomment-817791172 and https://github.com/status-im/status-desktop/discussions/2145, it's no longer desired
to have different appearance settings across multiple accounts.
Instead, the appearance setting should apply globally to all accounts,
essentially bypassing the individual setting stored in status-go.
This commit introduces a new global setting called `theme` which,
at the time of introducing this commit, can be either:
0 => Light
1 => Dark
2 => System
Because those enum values matches the `AppearanceContainer.Theme` enum,
this commit removes it completely and simply relies on QML's built-in
`Universal.[Light|Dark|System] variants respectively.
Closes#2144
This commit introces global settings that apply across accounts used
inside the application. This is useful when settings like the selected
locale should b the same across all accounts.
Closes#2144
Fixes#2050.
This PR contains changes to fix the name validation for new communities and new channels in communities. In the process of updating this, better validation was also added to both popups (create community and create channel), including the prevention of the "Create" button from being enabled until all form fields were valid.
During this process, it was noticed that the community image cropper was not actually cropping the image *in the preview*. Once the community was created, status-go was successfully cropping the image as the user intended. However, the preview thumbnail prior to creation was not accurately showing the cropped image preview and showing the entire image centred instead. *This is still yet to be fixed.* One solution is to upgrade Qt to `5.15` to take advantage of Image QML's `sourceClipRect`.
There was a bad merge in PR #2225 that caused the QML propery `activeMailserver` in `SyncContainer` to be stripped out. This was causing an error in the console: `qrc:/app/AppLayouts/Profile/Sections/SyncContainer.qml:16: Error: Cannot assign to non-existent property "activeMailserver”`.
This PR adds the property back in and resolves the issue.
Fixes#2143.
Methuselah is the a task manager for long-running tasks. It allows fo registration of workers that will each run in their own thead. Each worker can pass messages to and recieve messages from the main thread.
MailserverWoker was also introduced which moves all mailserver model logic to a MethuselahWorker. All communication to/from the model is done via a MethuselahTask. Results of the task are returned to the main thread by way of `signal_handler`, which calls the QtObject slot specified in the task.
Mailsever also provides a way for the model to emit events inside of the worker. These events are forwarded to the main thread via the `receiveEvent` slot of the `MailserverController`.
Co-authored-by: Michael Bradley, Jr <michaelsbradleyjr@gmail.com>
When the profile popup is opened inside the contacts list, it doesn't have
a surrounding window context (`Popup` types should usually be used within `ApplicationWindow`
or `Window` components as per https://doc.qt.io/qt-5/qml-qtquick-controls2-popup.html).
This is problematic when popup are nested, like it's the case with the
nickname popup that will be instantiated by the profile popup.
With no window context, such nested popup can't be opened by the application.
This commit ensures the profile popup is created with a proper context,
fixing the issue that the nickname popup won't open when visting via
contacts list.
Fixes#2216
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.
There was a UI bug in the StatusChatInput where, only in the timeline view,
the scrollview wrapping the textarea would have a weird behaviour in which
it would render the visible text(placeholder) *lower* than how it's actually
positioned. Once the textarea is clicked, it would re-adjust with a smooth
scroll.
Obviously this is undesired behaviour as the text should always render in the
correct position.
This commit finally fixes this weird behaviour by moving the dynamic height
calculation to the wrapping Rectangle and changing the textarea's top- and
bottom paddings dynamically.
Fixes#2018
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).
There were cases in which this component was used and its `checked` state wasn't
properly emitted to the underlying component.
This commit fixes that by ensuring the `MouseArea` only alters the radio button's
`checked` state and let the radio button handle the event propagation.
This was a regression introduced in https://github.com/status-im/status-desktop/pull/2065.
The new wrapping Rectangle would get the color that is possibily passed down
to Separator. Instead it should get properly bound to the actual separator.
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
We've been implementing such a button in various ways throughout the
application. Sometimes using SVG icons and rectangles, sometimes highjacking
`StyledText` components (which was clever though).
Obviously this resulted in inconsistencies, so this commit introduces
a new dedicated component to render the three-dots button for context menus.
Sometimes, `Separator` is used inside context menus to separate groups
of actions that belong together. The separator in itself doesn't have any
padding or margins in this case because the just gets transcluded as is
in the context menu, between menu items.
There are cases in the design where a padding/margin is desired though.
This change makes that possible by wrapping the separator `Rectangle` with
another `Rectangle` which controls a custom height (if desired). The inner
rectangle is then just always vertically center.
In practice this means, existing usages of `Separator` behave exactly the same,
they don't break. In addtion one can set `Separator { height: x }` while maintaining
a 1px separator line.
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
In the recent past we've improved our `ModalPopup` to allow for a bit more control
when it comes to rendering a modal footer section with call-to-action items.
The footer section is rendered when there's `footerContent` and when the height
of the footer content is > 0. This means it's possible to also hide the footer content
section from the modal, even when there's footer content children.
However, there's a separator rendered whenver the footer is visible, regardless of its
height. This results in undesired behaviour when rendering footer children of height 0.
To avoid this, this commit adjust the condition so that the separator is only rendered
when the footer visible AND the height of it is > 0.
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 checks on bootstrap what the currently configured theme
of the user is and loads the system tray icon in its corresponding
variation.
Unfortunately, MacOS doesn't seem to automatically swap out the icons
based on the system's theme, so we have to do it manually with two
different SVG files.
Another gotcha here is that, it doesn't seem to be possible to change
the system tray icon at runtime. When trying to reassign the `icon.source`
based on a newly selected theme, the icon disappears altogether.
The application also doesn't get notified when a user switches the theme
inside the operating system, requiring her to switch to the same theme
manually unless restarted.
Last but not least, using SVG files instead of PNG doesn't seem to solve
the problem that the icon is rendered blurry. I've looked in the docs
but there doesn't seem to be an option to have any influence on that...
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.
Due to how `StatusButton` has evolved, the send button in the Status
timeline no longer looked and behaved the way it was supposed to.
This commit patches that by introducing new properties to `StatusButton`
and making use of them in the Status timline, so that existing buttons
don't break.
It also fixes a bug in the StatusButton where the hovered background
color was wrongly calculated.
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`
StatusButton has a lot of issues when it comes to consistent behaviour
and look & feel. This includes things like calculating incorrect
hover colors as well as not being flexible enough to be used in various
scenarios
This commit changes StatusButton so that it's able to handle outlined
versions of warn buttons, calculates proper colors and more.
Many of these changes introduce heuristics to make things work.
In the long run, we should revisit the different variants that exists
(primary, secondary, outlined, warn etc) to encode them properly
in the API.
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.
The `StatusRoundButton` was missing the `hoverEnabled` flag, causing it
to not turn the cursor into a pointer when the component is hovered.
It's also not rendering the proper hover color.
This commit fixes that to improve usability and look & feel.
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
With the recent addition of the `muted` property in this component,
the `width` is no longer reliably calculated. Sometimes it can happen
that the muted bell icon jumps out of the component. This is very apparent
inside of a `StatusChatInfoButton`.
This commit ensure that the width of this component always includes all
of its children, fixing the ui bug mentioned above.
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
It was requested to change the tooltip to black an white and white on
black in dark and light themes respectively.
This commit changes the colors accordingly.
The background color of the component was hard coded to grey.
This commit changes it to `backgroundHover` so it looks consistent
in dark and light themes.
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.
Richard Ramos
Pascal Precht
Jonathan Rainville
Andrei Smirnov
Iuri Matias
Anthony Laibe
Alexandra Betouni
Sale Djenic
Eric Mastro
B.Melnik
--replace-all
ace-smart
staked-smart-ace
Malik Al-Jabr