- CommunitiesPortalLayout was the last piece still unconditionally loaded
on startup -> fixed
- extract the `communitiesStore` into AppMain to be able to reuse it from
other components
- move the import/create community dialogs to `Popups` (reusability)
- cleanup and remove some dead code, fix warnings
Iterates #6204
There's a bug that all requests to join a community require the user to
authenticate themselves. This should only be needed for community that
are token permissioned.
This commit fixes it by only performing auth when requesting from the
tokengated community view.
Fixes#10010
Users that request access to community that are token permissioned
need to authenticate and enter their password, so they can reveal
their wallet addresses
Also add handlers to JoinCommunityView for requesting and cancelling
requests. These will be extended in follow up commits to included
authentication modals
- Refactored minting components store access, since some panels were accessing stores directly. Now `CommunitySettingsView` is the single place where stores are accessed.
- Renamed store `CommunitesStore` to `CommunityTokensStore` for handling minting / airdrop actions / request models.
- `NetworkFilter` refactored to prevent direct access to store inside the component.
Closes#9663
This does a few things:
- It integrates with the latest `CommunityTokensMetadata` to access
community specific ERC721 token
- It changes `ChatLayout` such that it conditionally loads either
`ChatView` or `JoinCommunityView`. `JoinCommunityView` has been
specifically designed for token-gated communities
Here's what works (in terms of token permissions):
1. If a community has token permissions and the the current users is not
a member of that community, we show `JoinCommunityView` instead of
`ChatView`
2. Any community token permissions of type "Become member" are listed in
the `JoinCommunityView`
3. There are different types of token critera a permission can have:
ERC20 token, ERC721 token, or ENS (which is also ERC721 but we have
a type for that nonetheless)
Only ERC20 token balances are checked for the known wallet accounts.
This happens every time the known token list has been updated (every
10 min atm).
We still need to add balance checks for any ERC721 tokens and ENS.
4. If token permissions are created, updated or deleted by the community
owner, the `JoinCommunityView` will update in real-time.
You'll also notice that the `Reveal my address and request access`
button will be enabled if any of the token permissions are fulfilled
(only ERC20 at the time being). Clicking that button will not yet send
a request.
This will be done in the next step as part of https://github.com/status-im/status-desktop/issues/9761
Prior to this change `ChatLayout` exposed `chatView` which let other
components access it, its properties and signals.
This is problematic as we need to be able to swap out the `ChatView`
with the `JoinCommunityView` for token gated communities, in which case
there won't be an instance of `chatView`.
This commit ensures that we rely purely on inputs and outputs of the
component, without exposing the component instance itself.
... doesn't work in the community section
Extract the `Chat.RootStore` as a toplevel/shared property and pass it
down to ChatLayouts, instead of cross referencing it between different
components. This was also problematic since the ChatLayouts now live
inside a Loader, so it's more appropriate to refer to the
`Chat.RootStore` directly, instead of
`personalChatLayoutLoader.item.rootStore`, since the
`personalChatLayoutLoader.item` might not be visible (due to it being
inside a Loader and a StackLayout) or it might even be a different
component (`loadingStateComponent` or `errorStateComponent`).
This also caused similar problems for other components, such as
ActivityCenterPopup or StatusStickersPopup.
Fixes#9513
- all remaining global popup components moved into a separate Popups
entity
- removed some static objects from the Global singleton (appMain,
pinnedMessagesPopup, communityProfilePopup, sounds); rationale:
singletons should not contain any state
- fixed support for popups in storybook
- fixed some warnings (most of them broke the popups in one way or the other)
Don't show members in public chat
Show members in communities by default
Enable Gif Widget by default and remove settings entry
Enable Online users by default and remove settings entry
fixes#4906
- admin flag exposed to qml for chat/channel
- `CreateChannelPopup` updated
- `createPopup` function added to the `Global` singleton
- `PinnedMessagesPopup` component moved to `AppMain` and shared
among components beneath
- `chatType` added to `Constants` to group chat type related values
- `messageContentType` added to `Constants` to group message content type related
values
- `MessageStore` maintained per message list now
- added new `ChatContentView` component used to display chat/channel content
- components updated to display messages from the new backend
- `StatusChatToolBar` appropriately updated
- mute/unmute feature added to chat/channel list as well as to `StatusChatToolBar`
Changes done on the backend side related to the new chat/channel/categories model
are applied here. Necessary changes done on the `statusq` may be seen in PR-486.
Parts of the code which are not refactored yet are commented out.
Displayed chats/categories/channels since now are using refactored backend.
Changes done on the backend side related to the new chat/channel/categories model
are applied here. Necessary changes done on the `statusq` may be seen in PR-486.
Parts of the code which are not refactored yet are commented out.
Displayed chats/categories/channels since now are using refactored backend.
Fixes#4061
Most of the contact request code was already moved, but it wasn't hooked to the QML yet and also there were missing events and some code to improve.
- 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.
Moved Message component & dependencies to shared
for usage import shared.views.chat 1.0 and accordingly
import shared.controls/panels.chat 1.0
Closes#3927
Initial structure for MainModule containing ChatSectionModule and
CommunitySectionModule is added, as well as initial structure for
StartupModule containing OnboardingModule and LoginModule.
Order of execution is updated and adapted to the current app state.
Main module gets loaded once a user is successfully logged in.
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
* The userlist toggle made persistent between restarts
* Members is enabled by default for communities
* Public channels changed title to "last seen"
instead of "Members"
Closes#3502
As requested by design popup search added for the left side, click on a search
field (above channels list).
Refers to the changes requested by the issue-2934
Fixes: #2934
Updated from PopupMenu to StatusPopMenu. Removed buttons not in design.
Also added left and right button functionalXity on memeber list
fixes#2956, #3162
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
Boris Melnik
Lukáš Tinkl
Alex Jbanca
Pascal Precht
mprakhov
Noelia
Michał Cieślak
Michal Iskierko
Alexandra Betouni
Sale Djenic
Patryk Osmaczko
Stefan Dunca
Richard Ramos
Jonathan Rainville
Stefan D
Sale Djenic
Pascal Precht
Alexandra Betouni
Khushboo Mehta
Iuri Matias