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 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.
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.
default views for when there is no chat opened + chat links
add channel component
update other layouts
fix problem with alias
add test channels
fix merge conflict
add mouse hand pointer to chat list; add simple FAQ (testing QT urls)
refactor wallet to use asset model
move some of wallet logic away from the controller
move ChatMessage to model
move chatItem model
organize models folder
simplify chat message and chat item
rename messageList to message_list
simply addresses in the controller
rename mailservers list
refactor how profile is set
refactor/simplify profile view
refactor/simplify adding mailservers
rename wallet view
simplify wallet assets
rename nodeView to view
extract channel list view
extract channel list view
refactor channel list / chats view
move signals out of app folder
simplify callRPC
add raw rpc method and make node section use it
add node model
move accounts model inside onboard controller (for now)
make events usage consistent among models and controllers; separate model events from app events
make mouse show hand cursor when hovering over chat list
add FAQ url
simplify controllers and views, make everything more consistent
refactor wallet to use asset model
move some of wallet logic away from the controller
move ChatMessage to model
move chatItem model
organize models folder
simplify chat message and chat item
rename messageList to message_list
simply addresses in the controller
rename mailservers list
refactor how profile is set
refactor/simplify profile view
refactor/simplify adding mailservers
rename wallet view
simplify wallet assets
rename nodeView to view
extract channel list view
extract channel list view
refactor channel list / chats view
move signals out of app folder
address code reviews
Work on this PR started before the build system was updated and at one point I
upgraded `nim_status_client.nimble` to use NimScript so the nimble command
would stop warning that the old format was being used. In team chat it was
discussed that since we're no longer using nimble for package management we
could simply delete `nim_status_client.nimble` to avoid confusion, which can be
done in another PR.
Introduce a BrowserLayout stub so the index will be calcualted correctly re:
the active tab.
Reorganize ChatLayout and NodeLayout into subdirs `Chat` and `Node`,
respectively.
Introduce ProfileLayout which uses a "LeftTab" approach similar to that of
WalletLayout. There remains quite a bit of styling work to be done in
ProfileLayout and its LeftTab. Also, it may be better to start over using a
SplitView like the ChatLayout, I'm not really sure.
It wasn't clear what should be the default view for the right-pane when Profile
is selected in the left-most TabBar. In this PR, it defaults to showing the
view corresponding to the ENS usernames button.
In the archived Figma for the desktop design, it seemed a picture could be set,
e.g. there is a headshot of a woman used in the Profile screen. To that end I
explored how to take a square image and clip/mask it so it appears round and I
included a larger placeholder image for that purpose. In the new design, and
with respect to mobile, it may not be possible to set a profile picture so the
code that rounds the image can maybe be dropped.
Pascal Precht
Iuri Matias
Richard Ramos
Jonathan Rainville
Michael Bradley, Jr