This is analogue to `profileClickable` available on `StatusMessage`,
preventing users to activate a reply-to-message's profile avatar.
At the time of this commit, this is only the case for imported messages.
So we can derive that, if `StatusMessage.profileClickable` is false, then
`StatusMessageReply.profileClickable` is also false.
Hence, we don't need to expose this property to higher level APIs.
- fix the control's width (don't have to be explicit, the QQC2 Control
takes care of calculating the implicitWidth/Height automatically based on
contents)
- while at it, fix the metrics to be able to support RTL
languages too (it was off for Arabic)
- some smaller cleanups too
- Created StatusMainLayout to be used as the apps' main
layout
- Created StatusSectionLayout to be used for all sections as
their base
- Created StatusToolBar as part of StatusAppLayout with
standard component the ActivityButton and posibility to
add custom implementation components
Needed for https://github.com/status-im/status-desktop/issues/6635
This property allows for enabling/disabling whether or not the profile
picture and display name of a message is clickable and also dictates the
cursor type accordingly.
The reason this is being introduced is that, with imported messages from
other systems (e.g. discord, telegram etc), we don't want the user to
trigger the popup menu for more profile information because we don't
know any profile information of messages coming from such systems.
Such messages are signed by the community.
Closes https://github.com/status-im/status-desktop/issues/6680
This is a property that allows for adding information about the origin
of a message (e.g. "Imported from discord").
This will most likely be only useful for messages that have been
imported from any other platform.
Because importing from other platforms requires those message to be
signed by a Status Account, it's undesirable to render the public key of
the account that signed imported messages.
Hence, when there's a `messageOriginInfo`, we don't render the elided
public key.
The culprit here is at the very bottom, in StatusListItem: the toplevel
item was a MouseArea handling the clicks and this causes problems as any
extra buttons placed on top of it get their mouseClick events delivered
in wrong order (after StatusListItem). Fix this by having a MouseArea
handling click events behind the actual toplevel item as a last resort,
catch all handler plus the actual "sensor" being just a MouseArea that
handles merely the hover events
- drop unneeded onPressed/onReleased handlers in StatusChatListCategoryItem
- fix some warnings (typos, unreachable code, shadowed variables)
Fixes: #6733
Scope was to validate why StatusChatListCategoryItem miss behaves when
used in StatusChatListCategory.
On its own all the events works fine, as it can be seen by monitoring
the click events for each item (title, item and buttons).
However, inside StatusChatListCategory the mouse events are overlapped and
button events trigger also for the item. Tried obvious fiexes like
disabling steal of mouse events from buttons but this break the hovering
effect.
Updates: #6733
Pascal Precht
Stefan
Patryk Osmaczko
Lukáš Tinkl
Alexandra Betouni
PavelS
Michał
MishkaRogachev
Noelia
Igor Sirotin
Jonathan Rainville
Michal Iskierko
Sale Djenic
Anthony Laibe
Khushboo-dev-cpp