Direct binding was causing problems with height calculation in some
environments (qt 5.15) and lack of binding in other (5.14). This is
a solution which seems to work in both cases.
Closes: #7703
Created new `suite_messaging` where all related chat tests will be migrated to.
- `tst_ChatFlow` has been moved to new `suite_messaging`. It still contains some broken tests.
- `tst_groupChat` has been moved to new `suite_messaging`. It is now working (but it relies on the mailserver so could fail sometimes).
- `tst_statusLoginPassword` has been moved to new `suite_onboarding`.
- It has been needed to move some object definitions from `chat_names.py` to `global_names.py` since they are shared between different suites.
- Some other minor object and steps definitions have been moved to fit with the new structure.
Closes#7624
The create a group chat related objects have been updated according to new qml changes.
Now these tests are working (if they don't work it is bc of mailserver reliability).
"the user lands on the signed in app" step incorporates the following verifications (main screen is ready):
- Splash screen animation is loaded and ended.
- Banners that appear in the main screen are closed before starting other actions (secure seed phrase, connection information and update app information banners).
Additionally:
- communities grid made scrollable
- filtering done using SortFilterProxyModel
- various adjustments to the design
- clear input button added to the search input
Closes: #6360
Actually this is not a signing transaction, but rather authenticating logged in
user when he wants to send a transaction. An authentication is done by entering
password(regular user) or pin(keycard user).
A real signing transaction feature will be (hopefully) added in a near future where
we're going to sign a transaction on a keycard which corresponds to a certain
account, a user wants to send a transaction from.
To sum up... this change just removes password from the send modal and introduces
`Authenticate` flow instead.
Fixes: #7510
The RootStore was calling checkRecentHistory on the wallet section View
instead of the transaction View.
Still the workflow is broken due to the 20 minutes timer that calls
the checkRecentHistory and hangs the the main thread (UI) for a long time
Fixes: #7266
- don't display identicon rings for contacts with an ENS name
- prefer the at-form (@foo-user) whenever possible, and don't display their
username or pubkey unless they are locally given a nickname
- show compressed keys everywhere instead of the regular ones
Fixes: #7319Fixes: #7515
Two new props exposed so we can sed an extra spacing for every N-th item.
- `additionalSpacingOnEveryNItems` - determines for which item to add an extra space
- `additionalSpacing` - determines the value of extra space which will be added
Prior to this commit, a `StatusMessage` can hold only a single
`messageImage`.
There will be scenarios where messages can have multiple attachments.
This is the case when importing messages from discord.
Hence, this commit introduces a new `messageAttachments` property which
is a whitespace separated list of attachment URLs (very analogous to the
already existing `linkUrls` property).
For now, we can safely assume these URLs will resolve to image content.
In future versions however, we might want to support additional content
types to handle any byte stream.
We will then change `messageAttachments` from `string` to a list model
that holds `attachment`s where we also have access to its `contentType`.
This will allow us to decide at runtime which component should be used
to view/play the attachment.
- fix evaluating "Today" and "Yesterday"; can't just compare the two Date
objects, the timestamp will always differ so need to compare
year/month/day only
- best attempt to have the month translated, and year added if they
differ (until Qt6 at least, left a TODO)
Closes#843
`StatusBaseButton` comes with a `MouseArea` that is disabled when the
button is set to being disabled. Prior to this commit it's *also* disabled
when the button is in `loading` state.
This makes sense because a button that is in `loading` state shouldn't
not emit any click signals or trigger hover indications.
There's a scenario though in which we want render a tooltip on top of
the button which is in `loading` state. For the tooltip to show, the
`MouseArea` of the button needs to be enabled.
Hence, this commit adjust `StatusBaseButton`'s behaviour to *not*
disable the `MouseArea` when it's `loading`. Mouse events are already
prevented via the `loading` flag. So the only thing left to do is to
ensure the button doesn't trigger any hover indication when in `loading`
state.
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
Lukáš Tinkl
Igor Sirotin
MishkaRogachev
Alexandra Betouni
Michał Cieślak
Noelia
Khushboo Mehta
Sale Djenic
Stefan
PavelS
Michal Iskierko
Khushboo-dev-cpp
Alexandra Betouni
Patryk Osmaczko
PavelS
Pascal Precht
Jonathan Rainville
Anthony Laibe