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.
The Glitch fork reports the same version number as stock Mastodon and is
supposed to have the same baseline capabilities as stock Mastodon at
that version number.
RadioButton and CheckBox color the selected radio button or check box
using `colorPrimary`. For some reason Material dialogs don't, and use
`colorSecondary` for this (and only this), which leads to visual
inconstencices through the app.
Fix this by setting `colorSecondary` to `colorPrimary` to force it.
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.