emptyNode() renders nothing at all, which is fine for a placeholder that is left
within a few frames, but makes the application look frozen when the wait can
last, or never end.
Add a delayBeforeShowingContent parameter to emptyNode(): when it is finite, a
progress indicator and a "Loading…" label fade in after that delay, reusing the
existing DelayedVisibility helper. It defaults to Duration.INFINITE, so the
splash screen keeps rendering an empty canvas.
Use a one second delay on the two placeholders which are not guaranteed to be
left: the FTUE one, rendered while waiting for the session verified status, and
the LoggedInFlowNode one, rendered while the FTUE state is unknown.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Make sure `enforce_element_pro` is taken into account in FOSS
* Make sure we crate `RustTemporaryMatrixClient` instances with a proper `serverName` value
* Expose the timeline item gestures as TalkBack actions
Long pressing a timeline item opens the action list, and swiping it
starts a reply. Neither gesture is reachable with a screen reader
enabled, so those two actions were unavailable to TalkBack users.
Publish them as accessibility custom actions on the event row, reusing
the existing "Message actions" and "Reply" strings. The reply action is
only offered when the user is allowed to reply, matching the swipe.
* Update screenshots
---------
Co-authored-by: ElementBot <android@element.io>
Deciding whether a text message is emoji only compares the formatted body to
the plain one and runs a grapheme scan over the whole message. Nothing was
remembered, so both ran again on every recomposition of every visible message.
Remember the decision against the body and the formatted body. The preview
branch moves into the same computation, so the composable wrapper around
containsOnlyEmojis, which had a single caller and existed only to read
LocalInspectionMode, is no longer needed.
Add an interface `io.element.android.features.enterprise.api.AppStartupHook`,
which can be implemented in the enterprise build to perform certain actions on
startup.
It's a bit of a kludge for now since it doesn't block the rest of the app from
proceeding, but it will serve our purposes for now.
The raw push rules returned by the SDK are a single long line of json, which is
hard to read on a phone. Re-encode the content with a pretty printer using a two
space indentation before handing it to the file viewer.
Parsing to a JsonElement and re-encoding preserves the order of the keys, so the
rules are still listed in the order the server returned them. Content which
cannot be parsed is passed through unchanged, so that a malformed payload remains
viewable.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Add a "Push rules" item in the Notifications section of the developer options,
above "Push history". It displays the raw push rules of the account, which were
only available as a rageshake attachment so far.
The content is read using NotificationSettingsService.getRawPushRules(), then
rendered by the new FileViewerEntryPoint, so that the screen looks like the media
viewer rendering a file, with Share and Download actions on a
push_rules<userId>.json file. The user id contains a colon, which is not a valid
file name character on all the file systems, so it is replaced by an underscore.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Editing the caption of a media message dropped all of its formatting: bold,
links and the rest came back as plain text, and saving wrote that plain text
over the formatted caption.
The composer was being opened on the plain caption. Editing a message body
already starts from its HTML when rich text editing is on, and the caption
path was the only one that did not - it read `captionOrNull()` and never had
the caption's HTML to read, because the timeline content only kept the
already-parsed `formattedCaption`.
Media contents now carry the caption's HTML alongside the parsed one, the
same way text contents carry `htmlBody`, and editing a caption starts from it
when rich text editing is on. The save path already sent the composer's HTML,
so nothing changes there.
Part of #6730
Deleting a message that headed a thread took the thread with it: the "N
replies" summary under the message disappeared and there was no way back to
the replies, which are still there.
Every branch of the timeline content mapper passes `MsgLikeContent`'s thread
information on except the redacted one, which returned a bare
`RedactedContent` and dropped it. The thread summary lives on
`MsgLikeContent` next to `kind`, so it survives the redaction; only the app
was throwing it away. `RedactedContent` now carries the thread info like the
other contents do, and `EventTimelineItem.threadInfo()` reads it.
A deleted message that still heads a thread is also left out of the "N
removed messages" group, which would otherwise hide the summary again as soon
as three deletions ended up next to each other.
Part of #7397
Benoit Marty
ganfra
ElementBot
Jorge Martin Espinosa
Benoit Marty
hayyaksi
jmartinesp
Timo K.
Richard van der Hoff
bxdxnn