status-desktop/ui/app/AppLayouts/Chat/ChatLayout.qml

109 lines
2.9 KiB
QML
Raw Normal View History

2020-06-17 19:18:31 +00:00
import QtQuick 2.13
import QtQuick.Controls 2.13
import Qt.labs.settings 1.0
feat: layouts for the Profile screens 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.
2020-05-19 19:44:45 +00:00
import "../../../imports"
import "../../../shared"
import "../../../shared/status"
import "."
2020-10-02 13:02:56 +00:00
import "components"
SplitView {
id: chatView
handle: SplitViewHandle {}
2020-05-27 17:10:50 +00:00
property alias chatColumn: chatColumn
property bool stickersLoaded: false
fix(Chat): disable HoverHandler when profile popup or context menu are open 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
2021-03-23 09:44:56 +00:00
property bool profilePopupOpened: false
Connections {
target: chatsModel.stickers
onStickerPacksLoaded: {
stickersLoaded = true;
}
}
property var onActivated: function () {
chatsModel.restorePreviousActiveChannel()
chatColumn.onActivated()
}
2020-12-11 20:29:46 +00:00
Loader {
id: contactColumnLoader
SplitView.preferredWidth: Style.current.leftTabPreferredSize
sourceComponent: appSettings.communitiesEnabled && chatsModel.communities.activeCommunity.active ? communtiyColumnComponent : contactsColumnComponent
2020-12-11 20:29:46 +00:00
}
Component {
id: contactsColumnComponent
ContactsColumn {
}
}
Component {
id: communtiyColumnComponent
CommunityColumn {}
}
Component {
id: groupInfoPopupComponent
GroupInfoPopup {}
}
ChatColumn {
id: chatColumn
2020-12-11 20:29:46 +00:00
chatGroupsListViewCount: contactColumnLoader.item.chatGroupsListViewCount
}
2020-10-02 13:02:56 +00:00
Component {
id: statusStickerPackClickPopup
StatusStickerPackClickPopup{
onClosed: {
destroy();
}
}
}
2020-10-02 13:02:56 +00:00
function openProfilePopup(userNameParam, fromAuthorParam, identiconParam, textParam, nicknameParam, parentPopup){
var popup = profilePopupComponent.createObject(chatView);
if(parentPopup){
popup.parentPopup = parentPopup;
}
popup.openPopup(profileModel.profile.pubKey !== fromAuthorParam, userNameParam, fromAuthorParam, identiconParam, textParam, nicknameParam);
fix(Chat): disable HoverHandler when profile popup or context menu are open 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
2021-03-23 09:44:56 +00:00
profilePopupOpened = true
2020-10-02 13:02:56 +00:00
}
property Component profilePopupComponent: ProfilePopup {
id: profilePopup
height: 504
2020-10-02 13:02:56 +00:00
onClosed: {
if(profilePopup.parentPopup){
profilePopup.parentPopup.close();
}
fix(Chat): disable HoverHandler when profile popup or context menu are open 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
2021-03-23 09:44:56 +00:00
profilePopupOpened = false
2020-10-02 13:02:56 +00:00
destroy()
}
}
ConfirmationDialog {
id: removeContactConfirmationDialog
// % "Remove contact"
title: qsTrId("remove-contact")
//% "Are you sure you want to remove this contact?"
confirmationText: qsTrId("are-you-sure-you-want-to-remove-this-contact-")
onConfirmButtonClicked: {
2020-12-06 22:15:51 +00:00
if (profileModel.contacts.isAdded(chatColumn.contactToRemove)) {
profileModel.contacts.removeContact(chatColumn.contactToRemove)
2020-10-02 13:02:56 +00:00
}
removeContactConfirmationDialog.parentPopup.close();
removeContactConfirmationDialog.close();
}
}
}
/*##^##
Designer {
D{i:0;formeditorColor:"#ffffff";formeditorZoom:1.25;height:770;width:1152}
}
##^##*/