Previous code didn't set the textDirection for the status content, so
the first para of RTL text might be rendered incorrectly.
In addition, mentions and tags weren't BIDI wrapped, so would appear as
"foo@" and "foo#" in RTL statuses, instead of "@foo" and "#foo".
Fix both of these issues.
Fixes#870
Two problems with the previous code when search filters were visible:
1. The link icon overrode the tint, so didn't appear correctly in dark
and black mode.
2. The horizontal scroll view had the wrong background colour in black
mode.
Fix both, by updating the icon and adding a new style for the scroll
view.
While I'm here remove an obsolete comment and tighten up visibility.
Fixes#875
Clean up the notification handling code and fix a lot of bugs, hopefully
without introducing new ones in the process.
Specific bugs discovered and fixed:
- The code that tried to sync notification filtering state between the
server and Pachli could fail, leaving things in an inconsistent state,
resulting in dropped notifications. Remove that code, do filtering
client-side.
- Logging out of an account would disable push notifications for all
accounts.
- If any account did not support push notifications then push
notifications were disabled for all accounts.
- If any account did not support push notifications the user was
prompted to log out of all accounts. Drop that entirely.
- The UnifiedPush library could get to a state where configuring the
notification mechanism would silently fail,
The preferences UI now has a section for notifications, showing:
- The Unified Push distributor in use (if any)
- A mechanism to change the distributor
- Per-account configuration and notification fetch details
- Battery optimisation state
General changes:
- Update to UnifiedPush library 2.4.0.
- NotificationFetcher.fetchAndShow() can now fetch a single account's
notifications, or all accounts, depending on data passed to the worker.
- Use ApiResult for `push/subscription` responses.
- Drop the "needs migration" terminology for the more specific "has push
scope", to make it clear what the issue with the account is.
Add a new set of preferences, "Lab experiments", to control features
that are under investigation and may never make it into the mainstream.
Add the first experimental feature, which reverses the order of the home
timeline, so posts are shown oldest first instead of newest first.
Byline changes inadvertently changed how the preview image is laid out,
breaking the "Image at start, info at end" variant.
Previous code did not always show the card description if the text was
present, fix that.
Previous code set a min-height, which is no longer necessary after the
other layout changes. But it meant that a preview card with a one-line
title, no synopsis, and a URL, was taking up too much vertical space.
Previous code displayed a large placeholder icon if there was no preview
image for a preview card.
This reduces the amount of space available for the actual preview text
(i.e., title and description) and did not convey additional information
in the limited space available on the timeline.
So remove it.
While I'm here simplify the PreviewCard layout and migrate to
ConstraintLayout.
The `canFilter()` implementation could crash if `server` (marked
`lateinit`) hadn't been initialised at the point of use.
Fix this by removing it and adjusting the two callers to use the
`filters` flow and take appropriate action on error.
Default to hiding the search operators, and provide a new toolbar icon
(always visible) to show them.
The toolbar icon is displayed with a badge if any operators are present.
Adjust the operator display to three horizontal scrolling rows, to
further limit the maximum amount of vertical space the operators use.
Previously re-binding the tag's text wouldn't re-measure the layout when
the text changed. So scrolling down a longer tag could be placed in a
textview that previously held a shorter tag.
Then it was cut off and the user couldn't see what the tag was. Use
`wrap_content` so size is measured when the content changes.
Mastodon supports in-query search operators, such as `has:image`,
`language:en`, or `in:library`. Previously the user had to enter them in
to the query directly.
This provides a chip-based UI that allows the user to set values for
these operators.
## Server
- Add new search capabilities to record the faceted search features the
server reports.
- Update definitions for Mastodon, Friendica, and GoToSocial to specify
which versions of the operations they support.
## SearchOperator / SearchOperatorViewData
- Represents each supported operator and associated viewdata.
## SearchActivity / activity_search.xml
- Conditionally display a chip for each facet depending on the server's
level of support.
- Implement the UI for each chip. They display dialogs of varying levels
of complexity depending on the underlying operation.
## FragmentSearch
- Display the progress as a LinearProgressIndicator instead of an
indeterminate ProgressBar. This makes it more visible under the search
facets.
Previously, if a status was filtered with "WARN" and was shown in the
timeline with the name of the filter, and the user then decided to
change
that filter, they had to:
1. Open the left navigation menu
2. Navigate to "Account preferences"
3. Open "Filters"
4. Find the filter they want to edit, tap it
5. Make the change, and save
6. "Back" to the list of filters
7. "Back" to "Account preferences"
8. "Back" to the timeline
That's a lot of clicks for a simple action.
Change this. Now the filtered status includes an "Edit filter" button
that takes the user directly to step 5, and when they press "Back" they
return directly to the timeline.
To do this create a new filter action, `onEditFilterById`. Update the
listeners to launch `EditFilterActivity` if appropriate.
Modify `item_status_filtered.xml` to show the new button.
Update the accessibility delegate to show just the "Show anyway" and
"Edit filter" actions. Modify `FilterableStatusViewHolder` to expose
the information it needs to do this.
Previous code always focused the search query. This meant that if the
user:
1. Searched for something
2. Opened a result (post, hashtag, account)
3. Navigated back to the search results
then because the query was focused the soft-keyboard would open,
obscuring the list of results. The user had to press "Back" again to
dismiss the keyboard.
New code only focuses the search query view if it is empty. This allows
the user to come back to the list of results and immediately open a new
result.
Previous code set `doOnTextChanged` listener for the content warning
*after* the initial value had been set. This meant the initial content
warning text was not included when calculating the status' initial
length.
Fix that by setting the listener before the text is set.
Fixes#815
The previous code had a number of problems, including:
- Calls to the filters API were scattered through UI and viewmodel code.
- Repeated places where the differences between the v1 and v2 Mastodon
filters API had to be handled.
- UI and viewmodel code using the network filter classes, which tied
them to the API implementation.
- Error handling was inconsistent.
Fix this.
## FiltersRepository
- All filter management now goes through `FiltersRepository`.
- `FiltersRepository` exposes the current set of filters as a
`StateFlow`, and automatically updates it when the current server
changes or any changes to filters are made. This makes
`FilterChangeEvent` obsolete.
- Other operations on filters are exposed through `FiltersRepository` as
functions for viewmodels to call.
- Within the bulk of the app a new `Filter` class is used to represent a
filter; handling the differences between the v1 and v2 APIs is
encapsulated in `FiltersRepository`.
- Represent errors when handling filters as subclasses of `PachliError`,
and use `Result<V, E>` throughout, including using `ApiResult` for all
filter API results.
- Provide different types to distinguish between new-and-unsaved
filters, new-and-unsaved keywords, and in-progress edits to filters.
## Editing filters
- Accept an optional complete filter, or filter ID, as parameters in the
intent that launches `EditFilterActivity`. Pass those to the viewmodel
using assisted injection so the viewmodel has the info immediately.
- In the viewmodel use a new `FilterViewData` type to model the data
used to display and edit the filter.
- Start using the UiSuccess/UiError model. Refrain from cutting over to
full the action implementation as that would be a much larger change.
- Use `FiltersRepository` instead of making any API calls directly.
## Listing filters
- Use `FiltersRepository` instead of making any API calls directly.
## EventHub
- Remove `FilterChangedEvent`. Update everywhere that used it to use the
flow from `FiltersRepository`.
Previous code blindly inserted commas and semi-colons as separators
between the components of a content description. If some of those
components were null you could have a content description that looked
like "... , , , ..." or similar, and the repeated reading of "comma" by
screen readers was jarring and reduced accessibility.
Fix this by inserting punctuation only where necessary, building up the
string piece by piece instead of using a string resource with hardcoded
punctuation.
Fixes#791.
When autocompleting hashtags while composing a status the previous code
showed the hashtags in the same order they're returned by the server,
with no additional information.
This doesn't allow the user to make an informed choice about which
hashtag might be better to use. For example, trying to choose between
"#nivenly" and "#NivenlyFoundation".
To fix that, include the hashtag's usage when receiving data from the
server. Sum that, and show it to the user in the hashtag list. Sort the
hashtags by popularity, most popular first.
Nik Clayton
josé m
Kalle Kniivilä
renovate[bot]
sunniva
Juan M Sevilla
Miles Krell
Ricky From Hong Kong
Aindriú Mac Giolla Eoin
