This will make tests that need it easier.
- Rename from AccountPreferenceHandler
- Inject its dependencies
- Create an injectable CoroutineScope it can use for launching coroutines
- Use it in AccountPreferences
Currently translated at 100.0% (601 of 601 strings)
Translated using Weblate (Persian)
Currently translated at 100.0% (601 of 601 strings)
Translated using Weblate (Icelandic)
Currently translated at 100.0% (601 of 601 strings)
Co-authored-by: Nik Clayton <nik@ngo.org.uk>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/fa/
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/is/
Translation: Tusky/Tusky
Currently translated at 100.0% (601 of 601 strings)
Translated using Weblate (Icelandic)
Currently translated at 99.8% (600 of 601 strings)
Co-authored-by: Sveinn í Felli <sv1@fellsnet.is>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/is/
Translation: Tusky/Tusky
In the previous code any errors that occured *before* a subscriber was
listening to `uiError` would be dropped, so the user would be unware
of them.
By implementing as a channel these errors will be shown to the user,
with an opportunity to retry the operation or report the error.
Introduce Flow<T>.throttleFirst(). In a flow this emits the first value,
and each value afterwards that is > some timeout after the previous
value.
This prevents accidental double-taps on UI elements from generating
multiple-actions.
The previous code used debounce(). That has a similar effect, but with
debounce() the code has to wait until after the timeout period has
elapsed before it can process the action, leading to an unnecessary
UI delay.
With throttleFirst a value is emitted immediately, there's no need
to wait. It's subsequent values that are potentially throttled.
- Extend what was `NotificationWorkerFactory` to `WorkerFactory`. This
can construct arbitrary Workers as long as they provide their own
Factory for construction.
The per-Worker factory contains any injected components just for that
worker type, keeping `WorkerFactory` clean.
- Move `NotificationWorkerFactory` to the new model.
- Implement `PruneCacheWorker`, and remove the code from
`CachedTimelineViewModel`.
- Create the periodic worker in `TuskyApplication`, ensuring that the
database is only pruned when the device is idle.
formatNumber() was existing code to show numbers with suffixes like K, M, etc, so re-use that code and delete shortNumber().
Update the tests to (a) test formatNumber(), and (b) be parameterised.
* Fetch all outstanding Mastodon notifications when creating Android notifications
Previous code fetched the oldest page of unfetched Mastodon notifications.
If you had more than a page of Mastodon notifications you'd get Android notifications for that page, then ~ 15 minutes later Android notifications for the next page, and so on.
This code fetches all the outstanding notifications at once.
If this results in more than 40 total notifications the list is still trimmed so that a maximum of 40 Android notifications is displayed.
Fixes https://github.com/tuskyapp/Tusky/issues/3648
* Build the list using buildList
Don't use `accountManager.activeAccount` throughout the code.
Instead, get the active account once, and use that over the life of the viewmodel.
As shown in https://github.com/tuskyapp/Tusky/issues/3689#issuecomment-1567219338 the active account can change before the view model is destroyed, and if that happens account information for the account will be written to the wrong account.
Fix a bug where the active account can be overwritten.
1. Have two accounts logged in to Tusky, A and B
2. Open Tusky as account A
3. Send a DM to account B (doesn't have to be a DM, just anything that creates a notification for account B)
4. Restart Tusky so the Android notification for the DM is displayed immediately. You are still acting as account A.
5. Drag down the Android notification, you should see two options, "Quick reply" and "Compose"
6. Tap "Compose"
7. ComposeActivity will start. You are now acting as account B. Compose and send a reply
8. You'll be returned to the "Home" tab.
The UI will show you are still account A (i.e., it's account A's avatar at the top of the screen, if you have the "Show username in toolbars" option turned on it will be account A's username in the toolbar).
But you are now seeing the home timeline for account B.
Fix this.
ComposeViewModel
- Do not rely on the active account in sendStatus(), receive the account ID as a parameter
ComposeActivity
- Use either the account ID from the intent, or the current active account. **Do not** change the active account
- Pass the account ID to use in the sendStatus() call
The previous code gets the user's reading position *once*, when the
viewmodel is created, and uses that whenever it needs to be restored.
This is a problem. Suppose the user is a few days behind on their
notifications, and opens the app.
The reading position is restored, as expected. They scroll up to start
reading newer notifications.
Then they change their notification filters. This causes the
notifications list to change, and when it does their reading position
is set back to what it was when they first switched to the Notifications
tab.
Fix this by:
NotificationsFragment:
- Save the reading position whenever the user stops scrolling.
NotificationsViewModel:
- Use the saved reading position whenever the list of notifications
can change, not just when the view model is created.
Not all servers support the marker API. If they don't the user will
potentially get duplicate Android notifications.
To resolve this, store a copy of the notification marker ID locally as
well. Defer to the remote marker if it exists (and is newer than the
local marker).
Fixes https://github.com/tuskyapp/Tusky/issues/3671
When fetching:
- Maintain a marker with the position of the newest fetched notification
- Use the marker to determine which notifications to fetch
- Fetch notifications with min_id to ensure that none are lost
- Update the marker as necessary
- Perform a one-time immediate fetch of notifications on startup
When creating notifications:
- Identify each notification with tag=${MastodonNotificationId}, id=${account.id}
- Remove activeNotifications field, it's no longer necessary
- Use the tag/id tuple to reliably identify existing notifications and avoid creating duplicates
- Cancelling notifications for an account must iterate over all the notifications, and individually remove the notifications that exist for that account.
- Limit notifications to a maximum of 40 (excluding summary notifications)
- Remove notifications (oldest first) to get under this limit
- Rate limit notification creation to 1 per second, so the OS won't drop them
Adjust the summary notification:
- Ensure the summary notification and the child notifications have the same group key
- Dismiss the summary notification if there is only one child notification
NotificationClearBroadcastReceiver is no longer needed, so remove it, and the need for deletePendingIntent.
Fixes#3625, #3539
Currently translated at 98.0% (589 of 601 strings)
Translated using Weblate (Belarusian)
Currently translated at 95.0% (571 of 601 strings)
Co-authored-by: xzFantom <xzfantom@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
Currently translated at 100.0% (601 of 601 strings)
Translated using Weblate (French)
Currently translated at 97.8% (588 of 601 strings)
Translated using Weblate (French)
Currently translated at 89.5% (538 of 601 strings)
Translated using Weblate (French)
Currently translated at 79.5% (478 of 601 strings)
Co-authored-by: codl <codl@codl.fr>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/fr/
Translation: Tusky/Tusky
- Add a field to AccountEntity to hold the reading position
- Provide a method to save in the viewmodel to save the position
- Save the position when TimelineFragment pauses
Does not restore the position yet.
Requesting a non-existent notification ID will cause the fall-back requests to succeed but return empty lists which stops pagination.
Check for this, and in the worst case, fall back to returning the most recent notifications.
On Account preferences > Filters
With the list hidden on an empty view the FAB is erroneouly placed on the top left of the screen.
(Introduced with #3430)
Add additional 6dp margin to the top of the username view, to provide more space after the "X <performed an action>" view, consistent with item_follow.xml.
The pageSize is large enough that there's no need for the default 3 x pageSize initialLoadSize value, and this improves performance.
Fixes https://github.com/tuskyapp/Tusky/issues/3578
This makes the notification view for a follow request contain more info about the new follower, and makes the layout (of their name / username) consistent with other notifications that show names/usernames.
Previous code would discard the image alt-text if the user finished writing the text before the image had finished uploading.
This code ensures the text is set after the image has completed uploading.
* Disable lint checks for unused resource IDs
The check doesn't catch some instances where resources are used through viewbinding, and has too many false positives to be useful.
* Regenerate lint baseline
Delete the existing file, then regenerated with `.\gradlew lintBlueDebug -Dlint.baselines.continue=true`
* 3503: SwipeRefreshLayout must be higher level
* 3503: Fix notifications view a bit
* 3503: Wrap recycler views and message views in the swipe-to-refresh if all are present
* 3416: Call the list activity when empty; show failure on loading
* 3416: Revert include grouping
* 3416: Remove faulty include after merge
* 3416: Added a list loading progress
* 3416: Add proper padding to progress
* 3416: Show a text if there are no lists, do not change dialog title
* 3416: Center things in layout
* 3416: Appease linter (?)
* 3416: Do not hide manage lists button
* 3416: Use ThemeUtils
Currently translated at 100.0% (600 of 600 strings)
Translated using Weblate (Galician)
Currently translated at 94.0% (564 of 600 strings)
Co-authored-by: XoseM <xosem@disroot.org>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/gl/
Translation: Tusky/Tusky
Currently translated at 95.5% (573 of 600 strings)
Translated using Weblate (Spanish)
Currently translated at 95.1% (571 of 600 strings)
Co-authored-by: Paul Sanz <registro@polkillas.net>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/es/
Translation: Tusky/Tusky
* 3434: Make description dialog (text field) more usable
* 3434: Close dialog on back button
* 3434: Use a TextInputLayout
* 3434: Adapt German plurals text
* 3434: Remove unused id
* 3434: Disable counter officially
Currently translated at 100.0% (598 of 598 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (598 of 598 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (597 of 597 strings)
Co-authored-by: Ihor Hordiichuk <igor_ck@outlook.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/uk/
Translation: Tusky/Tusky
Currently translated at 100.0% (598 of 598 strings)
Translated using Weblate (Vietnamese)
Currently translated at 100.0% (598 of 598 strings)
Translated using Weblate (Vietnamese)
Currently translated at 100.0% (597 of 597 strings)
Co-authored-by: Hồ Nhất Duy <mastoduy@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/vi/
Translation: Tusky/Tusky
Currently translated at 100.0% (597 of 597 strings)
Translated using Weblate (Icelandic)
Currently translated at 95.8% (572 of 597 strings)
Co-authored-by: Sveinn í Felli <sv1@fellsnet.is>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/is/
Translation: Tusky/Tusky
Currently translated at 100.0% (598 of 598 strings)
Translated using Weblate (Persian)
Currently translated at 100.0% (597 of 597 strings)
Co-authored-by: Danial Behzadi <dani.behzi@ubuntu.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/fa/
Translation: Tusky/Tusky
* 3408: First draft of help message on empty home timeline
* 3408: Move image spanning to utils; tweak gui a bit (looks like status)
* 3408: Use proper R again; appease linter
* 3408: Add doc; remove narrow comment
* 3408: null is default
* 3408: Add German text
* 3408: Stack refresh animation on top of help message (reorder)
Currently translated at 100.0% (597 of 597 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (597 of 597 strings)
Co-authored-by: Eric <alchemillatruth@purelymail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/zh_Hans/
Translation: Tusky/Tusky
Currently translated at 91.1% (543 of 596 strings)
Translated using Weblate (Latvian)
Currently translated at 90.7% (541 of 596 strings)
Co-authored-by: Mārtiņš Bruņenieks <martinsb@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/lv/
Translation: Tusky/Tusky
* Show better errors with notification loading fails
The errors are returned as a JSON object, parse it, and show the error
message it contains.
Handle the cases where there might be no error message, or the JSON may be
malformed.
Add tests.
Fixes#3445
* Lint
* Show reblog/favourite confirmations as menus not dialogs
The previous code used dialogs and displayed the text of the status when
reblogging or favouriting.
This didn't work when the post just contained images, and other material
from the status (content warning, polls) was not shown either.
Fix this by displaying a popup menu instead. The status remains visible so
the user can clearly see what they're acting on.
In addition, this lays the groundwork for supporting a long-press menu
in the future to allow the user to reblog/favourite from a different
account.
Fixes https://github.com/tuskyapp/Tusky/issues/3308
* Revert the change that puts the menu immediately over the icon
Although this behavious is consistent with how the option menu works, I
decided that the risk of someone inadvertently double-tapping in the same
location, and the first tap opens the menu and the second tap confirms the
action was too great.
So now the menu appears either above or below the icon depending on space,
and the user has to tap in two slightly different spaces.
This is also consistent with the previous behaviour, where it's highly
unlikely that the confirm button on the dialog would have been directly
under the user's finger if they double-tapped.
Clickable spans in textviews do not normally meet the Android accessibility
guidelines of a minimum 48dp square touch target.
This can't be fixed with a `TouchDelegate`, as the span is not a separate
view to which the delegate can be attached.
Add `ClickableSpanTextView`. If used instead of a `TextView`, any spans
from `ClickableSpan` will have their touchable area extended to meet the
48dp minimum.
The touchable area is still bounded by the size of the view.
If two spans are closer together than 48dp then the closest span to the
touch wins.
Co-authored-by: Konrad Pozniak <connyduck@users.noreply.github.com>
* Show toot stat inline
* Correct elements position
* Format stats and show it according to setting
* inline toot statistics setting
* Code formatting
* Use kotlin functions
* Change the statistics setting description
* Use capital letters for all variants
* increase the statistics margin
* Merge fixes
* Code review fixes
* move setReblogsCount and setFavouritedCount to StatusViewHolder
* code cleaning
* code cleaning
* import lexicographical order
---------
Co-authored-by: Grigorii Ioffe <zikasaks@gmail.com>
Co-authored-by: grigoriiioffe <zikasaks@icloud.com>
Currently translated at 93.2% (556 of 596 strings)
Co-authored-by: ButterflyOfFire <butterflyoffire@protonmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/ar/
Translation: Tusky/Tusky
Currently translated at 100.0% (596 of 596 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (579 of 579 strings)
Co-authored-by: Ihor Hordiichuk <igor_ck@outlook.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/uk/
Translation: Tusky/Tusky
Currently translated at 96.1% (573 of 596 strings)
Translated using Weblate (Catalan)
Currently translated at 100.0% (567 of 567 strings)
Co-authored-by: Ricard Torres <ricard@ricard.dev>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/ca/
Translation: Tusky/Tusky
Currently translated at 100.0% (596 of 596 strings)
Translated using Weblate (Vietnamese)
Currently translated at 100.0% (579 of 579 strings)
Translated using Weblate (Vietnamese)
Currently translated at 100.0% (567 of 567 strings)
Co-authored-by: Hồ Nhất Duy <mastoduy@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/vi/
Translation: Tusky/Tusky
Currently translated at 100.0% (596 of 596 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (579 of 579 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (567 of 567 strings)
Co-authored-by: Eric <alchemillatruth@purelymail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/zh_Hans/
Translation: Tusky/Tusky
Currently translated at 100.0% (596 of 596 strings)
Translated using Weblate (Persian)
Currently translated at 100.0% (579 of 579 strings)
Translated using Weblate (Persian)
Currently translated at 100.0% (567 of 567 strings)
Co-authored-by: Danial Behzadi <dani.behzi@ubuntu.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/fa/
Translation: Tusky/Tusky
* Enforce lint cleanliness when building
The volume of lintable issues is growing. To stem the tide:
1. Add `app/lint-baseline.xml`, which contains the current set of lint issues.
Any issue appearing here will not cause the build to fail.
2. Move lint configuration settings in to `lint.xml`.
3. Update the lint configuration so that any issue (i.e., any issue not
in lint-baseline.xml) causes a build failure.
4. Add the lint tasks as depedency when assembling an APK, to ensure the
lint checks are run.
* lint: Convert launcher images to webp
* Move lint.xml location
* Don't lint when assembling
* Update baseline
* Move compose.* tests to own namespace
* Ignore "@instance..." part of username when computing status length
In a status with a mention ("@foo@example.org") only the "@foo" part should
be included in the calculated status length. It wasn't, so the app was
prevening people from posting statuses that should have been allowed.
Fix this.
- Lift the length calculation code in to a separate static function (easier
and faster to test)
- Add a `MentionSpan` type, to reuse existing code for detecting mentions
- Fix a bug in `FakeSpannable.getSpans()` (it was returning the outer type,
not the wrapped inner span)
- Add additional fast tests
The tests made sense under the `components.compose.ComposeActivity` package,
so I also created that and moved the existing ComposeActivity tests there.
Fixes https://github.com/tuskyapp/Tusky/issues/3339
* Static import assertEquals
The previous code returned the text representation of the error body type, which resulted in errors appearing in the UI as:
```
okhttp3.ResponseBody$Companion$asResponseBody$1@...
```
This code actually converts the *body* of the error response to a string, so the error is displayed correctly.
* Replace "warn"-filtered posts in timelines and thread view with placeholders
* Adapt hashtag muting interface
* Rework filter UI
* Add icon for account preferences
* Clean up UI
* WIP: Use chips instead of a list. Adjust padding
* Scroll the filter edit activity
Nested scrolling views (e.g., an activity that scrolls with an embedded list
that also scrolls) can be difficult UI.
Since the list of contexts is fixed, replace it with a fixed collection of
switches, so there's no need to scroll the list.
Since the list of actions is only two (warn, hide), and are mutually
exclusive, replace the spinner with two radio buttons.
Use the accent colour and title styles on the different heading titles in
the layout, to match the presentation in Preferences.
Add an explicit "Cancel" button.
The layout is a straightforward LinearLayout, so use that instead of
ConstraintLayout, and remove some unncessary IDs.
Update EditFilterActivity to handle the new layout.
* Cleanup
* Add more information to the filter list view
* First pass on code review comments
* Add view model to filters activity
* Add view model to edit filters activity
* Only use the status wrapper for filtered statuses
* Relint
---------
Co-authored-by: Nik Clayton <nik@ngo.org.uk>
* Show the difference between edited statuses
Diff each status against the previous version, comparing the different
HTML as XML to produce a structured diff.
Mark new content with `<ins>`, deleted content with `<del>`.
Convert these to styled spans in `ViewEditsAdapter`.
* Update diffx to 1.1.1
Fixes issue with diffs splitting on accented characters
* Style edited strings with Android spans
Don't use HTML spans and try and format them, create real Android spans.
Do this with a custom tag handler that can add custom spans that set the
text paint appropriately.
* Lint
* Move colors in to theme_colors.xml
* Draw a roundrect for the backoround, add start/end padding
Make the background slightlysofter by drawing it as a roundrect.
Make the spans easier to understand by padding the start/end of each one with
the width of a " " character. This is visual only, the underlying text is not
changed.
* Catch exceptions when parsing XML
* Move sorting in to Dispatchers.Default coroutine
* Scope the loader type
* Remove alpha
* Replace DefaultTextWatcher with extensions in core-ktx
* Fix positiveButton.isEnabled
* editable!! for highlightSpans
* Fix style
* Put noteWatcher back
* Use more Sequences to reduce collection processing
https://kotlinlang.org/docs/sequences.html
* Use joinToString
* Fix style
* Revert "Use more Sequences to reduce collection processing"
This reverts commit acf8071d9e62af1366b40dc6cb0ce43b4b355ec2.
* Fix
* Unmodified output from "Convert Java to Kotlin" on NotificationsFragment.java
* Bare minimum changes to get this to compile and run
- Use `lateinit` for `eventhub`, `adapter`, `preferences`, and `scrolllistener`
- Removed override for accountManager, it can be used from the superclass
- Add `?.` where non-nullity could not (yet) be guaranteed
- Remove `?` from type lists where non-nullity is guaranteed
- Explicitly convert lists to mutable where necessary
- Delete unused function `findReplyPosition`
* Remove all unnecessary non-null (!!) assertions
The previous change meant some values are no longer nullable. Remove the
non-null assertions.
* Lint ListStatusAccessibilityDelegate call
- Remove redundant constructor
- Move block outside of `()`
* Use `let` when handling compose button visibility on scroll
* Replace a `requireNonNull` with `!!`
* Remove redundant return values
* Remove or rename unused lambda parameters
* Remove unnecessary type parameters
* Remove unnecessary null checks
* Replace cascading-if statement with `when`
* Simplify calculation of `topId`
* Use more appropriate list properties and methods
- Access the last value with `.last()`
- Access the last index with `.lastIndex`
- Replace logical-chain with `asRightOrNull` and `?.`
- `.isNotEmpty()`, not `!...isEmpty()`
* Inline unnecessary variable
* Use PrefKeys constants instead of bare strings
* Use `requireContext()` instead of `context!!`
* Replace deprecated `onActivityCreated()` with `onViewCreated()`
* Remove unnecessary variable setting
* Replace `size == 0` check with `isEmpty()`
* Format with ktlint, no functionality changes
* Convert NotifcationsAdapter to Kotlin
Does not compile, this is the unchanged output of the "Convert to Kotlin"
function
* Minimum changes to get NotificationsAdapter to compile
* Remove unnecessary visibility modifiers
* Use `isNotEmpty()`
* Remove unused lambda parameters
* Convert cascading-if to `when`
* Simplifiy assignment op
* Use explicit argument names with `copy()`
* Use `.firstOrNull()` instead of `if`
* Mark as lateinit to avoid unnecessary null checks
* Format with ktlint, whitespace changes only
* Bare minimum necessary to demonstrate paging in notifications
Create `NotificationsPagingSource`. This uses a new `notifications2()` API
call, which will exist until all the code has been adapted. Instead of
using placeholders,
Create `NotificationsPagingAdapter` (will replace `NotificationsAdapater`)
to consume this data.
Expose the paging source view a new `NotificationsViewModel` `flow`, and
submit new pages to the adapter as they are available in
`NotificationsFragment`.
Comment out any other code in `NotificationsFragment` that deals with
loading data from the network. This will be updated as necessary, either
here, or in the view model.
Lots of functionality is missing, including:
- Different views for different notification types
- Starting at the remembered notification position
- Interacting with notifications
- Adjusting the UI state to match the loading state
These will be added incrementally.
* Migrate StatusNotificationViewHolder impl. to NotificationsPagingAdapter
With this change `NotificationsPagingAdapter` shows notifications about a
status correctly.
- Introduce a `ViewHolder` abstract class that all Notification view holders
derive from. Modify the fallback view holder to use this.
- Implement `StatusNotificationViewHolder`. Much of the code is from the
existing implementation in the `NotificationAdapater`.
- The original code split the code that binds values to views between the
adapter's `bindViewHolder` method and the view holder's methods.
In this code, all of the binding code is in the view holder, in a `bind`
method. This is called by the adapter's `bindViewHolder` method. This keeps
all the binding logic in the view holder, where it belongs.
- The new `StatusNotificationViewHolder` uses view binding to access its views
instead of `findViewById`.
- Logically, information about whether to show sensitive media, or open
content warnings should be part of the `StatusDisplayOptions`. So add those
as fields, and populate them appropriately.
This affects code outside notification handling, which will be adjusted
later.
* Note some TODOs to complete before the PR is finished
* Extract StatusNotificationViewHolder to a new file
* Add TODO for NotificationViewData.Concrete
* Convert the adapter to take NotificationViewData.Concrete
* Add a view holder for regular status notifications
* Migrate Follow and FollowRequest notifications
* Migrate report notifications
* Convert onViewThread to use the adapter data
* Convert onViewMedia to use the adapter data
* Convert onMore to use the adapter data
* Convert onReply to use the adapter data
* Convert NotificationViewData to Kotlin
* Re-implement the reblog functionality
- Move reblogging in to the view model
- Update the UI via the adapter's `snapshot()` and `notifyItemChanged()`
methods
* Re-implement the favourite functionality
Same approach as reblog
* Re-implement the bookmark functionality
Same approach as reblog
* Add TODO re StatusActionListener interface
* Add TODO re event handling
* Re-implementing the voting functionality
* Re-implement viewing hidden content
- Hidden media
- Content behind a content warning
* Add a TODO re pinning
* Re-implement "Show more" / "Show less"
* Delete unused updateStatus() function
* Comment out the scroll listener for the moment
* Re-implement applying filters to notifications
Introduce `NotificationsRepository`, to provide access to the notifications
stream.
When changing the filters the flow is as follows:
- User clicks "Apply" in the fragment.
- Fragment calls `viewModel.accept()` with a `UiAction.ApplyFilter` (new
class).
- View model maintains a private flow of incoming UI actions. The new action
is emitted to that flow.
- In view model, `notificationFilter` waits for `.ApplyFilter` actions, and
ensures the filter is saved, then emits it.
- In view model, `pagingDataFlow` waits for new items from
`notificationsFilter` and fetches the notifications from the repository in
response. The repository provides `Notification`, so the model maps them to
`NotificationViewData.Concrete` for display by the adapter.
- In view model the UI state also waits for new items from
`notificationsFilter` and emits a new `UiState` every time the filter is
changed.
When opening the fragment for the first time:
- All of the above machinery, but `notificationFilter` also fetches the filter
from the active account and emits that first. This triggers the first fetch
and the first update of `uiState`.
Also:
- Add TODOs for functionality that is not implemented yet
- Delete a lot of dead code from NotificationsFragment
* Include important preference values in `uiState`
Listen to the flow of eventHub events, filtered to preference changes that
are relevant to the notification view.
When preferences change (or when the view model starts), fetch the current
values, and include them in `uiState`.
Remove preference handling from `NotificationsFragment`, and just use
the values from `uiState`.
Adjust how the `useAbsoluteTime` preference is handled. The previous code
loaded new content (via a diffutil) in to the adapter, which would trigger
a re-binding of the timestamp.
As the adapter content is immutable, the new code simply triggers a
re-binding of the views that are currently visible on screen.
* Update UI in response to different load states
Notifications can be loaded at the top and bottom of the timeline. Add a
new layout to show the progress of these loads, and any errors that can
occur.
Catch network errors in `NotificationsPagingSource` and convert to
`LoadState.Error`.
Add a header/footer to the notifications list to show the load state.
Collect the load state from the adapter, use this to drive the visibility
of different views.
* Save and restore the last read notification ID
Use this when fetching notifications, to centre the list around the
notification that was last read.
* Call notifyItemRangeChanged with the correct parameters
* Don't try and save list position if there are no items in the list
* Show/hide the "Nothing to see" view appropriately
* Update comments
* Handle the case where the notification key no longer exists
* Re-implement support for showMediaPreview and other settings
* Re-implement "hide FAB when scrolling" preference
* Delete dead code
* Delete Notifications Adapater and Placeholder types
* Remove NotificationViewData.Concrete subclass
Now there's no Placeholder, everything is a NotificationViewData.
* Improve how notification pages are loaded if the first notification is missing or filtered
* Re-implement clear notifications, show errors
* s/default/from/
* Add missing headers
* Don't process bookmarking via EventHub
- Initiating a bookmark is triggered by the fragment sending a
StatusUiAction.Bookmark
- View model receives this, makes API call, waits for response, emits either
a success or failure state
- Fragment collects success/failure states, updates the UI accordingly
* Don't process favourites via EventHub
* Don't process reblog via EventHub
* Don't process poll votes with EventHub
This removes EventHub from the fragment
* Respond to follow requests via the view model
* Docs and cleanup
* Typo and editing pass
* Minor edits for clarity
* Remove newline in diagram
* Reorder sequence diagram
* s/authorize/accept/
* s/pagingDataFlow/pagingData/
* Add brief KDoc
* Try and fetch a full first page of notifications
* Call the API method `notifications` again
* Log UI errors at the point of handling
* Remove unused variable
* Replace String.format() with interpolation
* Convert NotificationViewData to data class
* Rename copy() to make(), to avoid confusion with default copy() method
* Lint
* Update app/src/main/res/layout/simple_list_item_1.xml
* Update app/src/main/java/com/keylesspalace/tusky/components/notifications/NotificationsPagingAdapter.kt
* Update app/src/main/java/com/keylesspalace/tusky/components/notifications/NotificationsViewModel.kt
* Update app/src/main/java/com/keylesspalace/tusky/fragment/NotificationsFragment.kt
* Update app/src/main/java/com/keylesspalace/tusky/viewdata/NotificationViewData.kt
* Initial NotificationsViewModel tests
* Add missing import
* More tests, some cleanup
* Comments, re-order some code
* Set StateRestorationPolicy.PREVENT_WHEN_EMPTY
* Mark clearNotifications() as "suspend"
* Catch exceptions from clearNotifications and emit
* Update TODOs with explanations
* Ensure initial fetch uses a null ID
* Stop/start collecting pagingData based on the lifecycle
* Don't hide the list while refreshing
* Refresh notifications on mutes and blocks
* Update tests now clearNotifications is a suspend fun
* Add "Refresh" menu to NotificationsFragment
* Use account.name over account.displayName
* Update app/src/main/java/com/keylesspalace/tusky/fragment/NotificationsFragment.kt
Co-authored-by: Konrad Pozniak <connyduck@users.noreply.github.com>
* Mark layoutmanager as lateinit
* Mark layoutmanager as lateinit
* Refactor generating UI text
* Add Copyright header
* Correctly apply notification filters
* Show follow request header in notifications
* Wait for follow request actions to complete, so the reqeuest is sent
* Remove duplicate copyright header
* Revert copyright change in unmodified file
* Null check response body
* Move NotificationsFragment to component.notifications
* Use viewlifecycleowner.lifecyclescope
* Show notification filter as a dialog rather than a popup window
The popup window:
- Is inconsistent UI
- Requires a custom layout
- Didn't play nicely with viewbinding
* Refresh adapter on block/mute
* Scroll up slightly when new content is loaded
* Restore progressbar
* Lint
* Update app/src/main/res/layout/simple_list_item_1.xml
---------
Co-authored-by: Konrad Pozniak <connyduck@users.noreply.github.com>
`activity_account` sets the root text direction to `anyRtl`.
This is OK for UI elements, but can be a problem for user generated content
(UGC) that may contain bidirectional text.
Fix this by explicitly restoring the default behaviour, `firstStrong`, on
views in `activity_account` that can show UGC.
Fixes https://github.com/tuskyapp/Tusky/issues/3294
* Add "Refresh" accessibility menu to TimelineFragment
Per https://developer.android.com/reference/androidx/swiperefreshlayout/widget/SwipeRefreshLayout
the layout does not provide accessibility events, and a menu item should be
provided as an alternative method for refreshing the content.
In `TimelineFragment`:
- Implement the `MenuProvider` interface so it can populate the action bar
menu in activities that host the fragment
- Create a "Refresh" menu item, and refresh the state when it is selected
`MainActivity` has to change how the menu is created, so that fragments
can add items to it.
In `MainActivity`:
- Call `setSupportActionBar` so `mainToolbar` participates in menus
- Implement the `MenuProvider` interface, and move menu creation there
- Set the title via supportActionBar
* Never show the refresh item as a menubar action
Per guidelines in https://developer.android.com/develop/ui/views/touch-and-input/swipe/add-swipe-interface#AddRefreshAction
* Add "Refresh" menu item for AccountMediaFragment
Also, fix the colour of the refresh progress indicator
* Implement "Refresh" for AnnouncementsActivity
* Add "Refresh" menu for ConversationsFragment
* Keep the tabs adapter over the life of the viewpager
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
* Add "Refresh" menu for ScheduledStatusActivity
* Lint
* Add "Refresh" menu for SearchFragment / SearchActivity
* Explicitly set the searchview width
Using "collapseActionView" requires the user to press "Back" twice to exit
the activity, which is not acceptable.
* Move toolbar handling in to ViewThreadActivity
Previous code had the toolbar in the fragment's layout. Refactor to make
consistent with other activities, and move the toolbar in to the activity
layout.
Implement MenuProvider in ViewThreadFragment to adjust the menu in the
activity.
* Add "Refresh" menu to ViewThreadFragment
* Implement "Refresh" for ViewEditsFragment
* Lint
* Add "Refresh" menu to ReportStatusesFragment
* Add "Refresh" menu to NotificationsFragment
* Rename menu resource files
Be consistent with the layout resource files, which have an activity/fragment
prefix, then the lower_snake_case name of the activity or fragment it's for.
* Only enable refresh menu if swiptorefresh is enabled
Some timelines don't have swipetorefresh enabled (e.g., those shown on
AccountActivity). In those cases don't add the refresh menu, rely on the
hosting activity to provide it.
Update AccountActivity to provide the refresh menu item.
Not all Robolectric tests interact with activities, so lazy loading the activity can speed them up.
I benchmarked the impact with gradle-profiler. Each test run performed 6 warmup runs, and then 10 benchmarked runs with and without this change.
Without this change (all values rounded to nearest second):
Mean: 151
Median: 149
P75: 157
StdDev: 10
With this change:
Mean: 127
Median: 125
P75: 130
StdDev: 7
So a ~ 18% reduction in median and P75 times,
* 3204: Add an account based preference store
* 3204: (related) reformat a bit, add todo
* 3204: Use the preference data store for all three account settings
* 3204: Move event handling to account settings handler
* 3204: Correct includes
* 3204: Appease linter
* 3204: Appease linter again
* 3204: Add an account based preference store
* 3204: Use the preference data store for all three account settings
* 3204: Move event handling to account settings handler
* 3204: Correct includes
* 3204: Add general "preference upgrade loop stepper"; use it for removing obsolete account settings (in shared)
* 3204: Add missing spaces
* 3204: Key is non-nullable
* 3204: Upgrade to new settings migration code
* 3204: Remove (commented) DI code
* 3311: Add a zig-zag line to top and bottom of "load more"
* 3311: Remove unneeded extensions
* 3311: Use a simple gradient instead of zigzag line
* 3311: Use a simple gradient drawable (remove custom view)
* 3311: Remove gradient lines
* Ignore clicks outside the start/end of a line
`LinkMovementMethod` has a bug in its calculation of the clickable width of a span on a line. If the span is the last thing on the line the clickable area extends to the end of the view. So the user can tap what appears to be whitespace and open a link.
Previous code tried to fix this by adding a zero-width space after the link so that `LinkMovementMethod` wouldn't consider it empty. However the ZWS was selected by copy/paste operations, resulting in junk results if users tried to copy the link.
Fix this by subclassing `LinkMovementMethod` and fixing the click detection code to ignore clicks that are outside the bounds of the line that was clicked on.
Remove the code that adds the ZWS.
Fixes https://github.com/tuskyapp/Tusky/issues/1567
* Assume arguments are all non-null
* Use `object` for singleton
* getInstance as a one-liner
* Use an explicit SCHEMA_VERSION instead of BuildConfig.VERSION_CODE
Every nightly release has a new BuildConfig.VERSION_CODE, so the previous
code would not do the right thing.
Require the schema version to be explicitly set. While I'm here, provide
a clear set of guidelines as to what has to happen when the schema changes.
* Improve documentation links
* Update ViewVideoFragment.kt
Testing
- Open audio attachment: https://solarpunk.moe/@vv/109562659215759090
- Ensure media control UI and alt text is shown once playback starts
Fixes#3261
* Fix commit issue
* Fix spacing
* Make "Up" and "Overflow" menu icons more visible in AccountProfile
The toolbar in AccountProfile is transparent, so any profile image the user
has chosen is shown under it.
This makes the "Up" and "Overflow" menu icons also have transparent
backgrouns.
Consequently, they can be hard to spot, or possibly invisible, on backgrounds
that are very dark or very light.
Fix this by compositing the icons in a LayerDrawable, with a circular
background identical to the surface colour. This ensures they stand out
against the background image, and blend in when the user scrolls.
* Get and reuse the background drawable
* Apply a smidgen of transparency
Currently translated at 100.0% (566 of 566 strings)
Translated using Weblate (Vietnamese)
Currently translated at 100.0% (564 of 564 strings)
Co-authored-by: Hồ Nhất Duy <mastoduy@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/vi/
Translation: Tusky/Tusky
Currently translated at 100.0% (566 of 566 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (564 of 564 strings)
Co-authored-by: Ihor Hordiichuk <igor_ck@outlook.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/uk/
Translation: Tusky/Tusky
Currently translated at 100.0% (566 of 566 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (564 of 564 strings)
Co-authored-by: Eric <alchemillatruth@purelymail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/zh_Hans/
Translation: Tusky/Tusky
- Add a FAB for user interaction (hide on scroll if appropriate)
- Show a dialog to collect the new hashtag
- Autocomplete hashtags the same as when composing a status
* Kotlin 1.8.10
https://github.com/JetBrains/kotlin/releases/tag/v1.8.10
* Migrate onActivityCreated to onViewCreated
* More final modifiers
* Java Cleanups
* Kotlin cleanups
* More final modifiers
* Const value TOOLBAR_HIDE_DELAY_MS
* Revert
Previous code was:
```
for (i in tabs.indices) {
// ...
if (tabs[i].id == LIST) {
tab.contentDescription = tabs[i].arguments[1]
} else {
tab.setContentDescription(tabs[i].text)
}
// ...
```
When I converted it over, `i` was replaced with `position`, but I misread `tab.contentDescription = tabs[i].arguments[1]` as `tab.contentDescription = tabs[i].arguments[i]`.
Put the `1` back.
This uses unusual code provided by Mikhail Lopatkin of Gradle Inc:
https://github.com/gradle/gradle/issues/23914#issuecomment-1431909019
It wraps the git sha function in a "value source". This allows it to interact correctly with configuration caching.
Because the code is longer than before, it is now broken out into its own file getGitSha.gradle.
Make `tabs` `var` instead of `val` in `MainPagerAdapter` so it can be updated
when tabs change.
Then detach the `tabLayoutMediator`, update the tabs, and call
`notifyItemRangeChanged` in `setupTabs()`.
This fixes a bug (not sure if it's this code, or in ViewPager2) where
assigning a new adapter to the view pager seemed to result in a leak of one
or more fragments. This wasn't user-visible, but it's a leak, and it becomes
user-visible when fragments want to display menus.
This also fixes two other bugs:
1. Be on the left-most tab. Scroll down a bit. Then modify the tabs at
"Account preferences > tabs", but keep the left-most tab as-is.
Then go back to MainActivity. Your reading position in the left-most
tab has been jumped to the top.
2. Be on any non-left-most tab. Then modify the tab list by reordering tabs
(adding/removing tabs is also OK).
Then go back to MainActivity. Your tab selection has been overridden,
and the left-most tab has been selected.
Because the fragments are not destroyed unnecessarily your reading position
is retained. And it remembers the tab you had selected, and as long as that
tab is still present you will be returned to it, even if it's changed
position in the list.
Fixes https://github.com/tuskyapp/Tusky/issues/3251
Currently translated at 100.0% (564 of 564 strings)
Translated using Weblate (Persian)
Currently translated at 100.0% (560 of 560 strings)
Co-authored-by: Danial Behzadi <dani.behzi@ubuntu.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/fa/
Translation: Tusky/Tusky
* Add support for updating media description and focus point when editing statuses
* Don't publish description/focus point updates via the standard api when editing a published post
* Add initial feature for viewing trending graphs. Currently only views hash tag trends.
Contains API additions, tab additions and a set of trending components.
* Add clickable system through a LinkListener. Duplicates a little code from SFragment.
* Add accessibility description.
* The background for the graph should match the background for black theme too.
* Add error handling through a state flow system using existing code as an example.
* Graphing: Use a primary and a secondary line. Remove under line fill. Apply line thickness. Dotted end of line.
* Trending changes: New layout for trending: Cell. Use ViewBinding. Add padding to RecyclerView to stop the FAB from hiding content. Multiple bugs in GraphView resolved. Wide (landscape, for example) will show 4 columns, portrait will show 2. Remove unused base holder class. ViewModel invalidate scoping changed. Some renaming to variables made. For uses and accounts, use longs. These could be big numbers eventually. TagViewHolder renamed to TrendingTagViewHolder.
* Trending changes: Remove old layout. Update cell textsizes and use proper string. Remove bad comment.
* Trending changes: Refresh the main drawer when the tabs are edited. This will allow the trending item to toggle.
* Trending changes: Add a trending activity to be able to view the trending data from the main drawer.
* Trending changes: The title text should be changed to Trending Hashtags.
* Trending changes: Add meta color to draw axis etc. Draw the date boundaries on the graph. Remove dates from each cell and place them in the list as a header. Graphs should be proportional to the highest historical value. Add a new interface to control whether the FAB should be visible (important when switching tabs, the state is lost). Add header to the adapter and viewdata structures. Add QOL extensions for getting the dates from history.
* Trending changes: Refresh FAB through the main activity and FabFragment interface. Trending has no FAB.
* Trending changes: Make graph proportional to the highest usage value. Fixes to the graph ratio calculations.
* Trending changes: KtLintFix
* Trending changes: Remove accidental build gradle change. Remove trending cases. Remove unused progress. Set drawer button addition explicitly to false, leaving the code there for future issue #3010. Remove unnecessary arguments for intent. Remove media preview preferences, there is nothing to preview. No padding between hashtag symbol and text. Do not ellipsize hashtags.
* Trending changes: Use bottomsheet slide in animation helper for opening the hashtag intent. Remove explicit layout height from the XML and apply it to the view holder itself. The height was not being respected in XML.
* Use some platform standards for styling
- Align on an 8dp grid
- Use android:attr for paddingStart and paddingEnd
- Use textAppearanceListItem variants
- Adjust constraints to handle different size containers
* Correct lineWidth calculations
Previous code didn't convert the value to pixels, so it was always displaying
as a hairline stroke, irrespective of the value in the layout file.
While I'm here, rename from lineThickness to lineWidth, to be consistent
with parameters like strokeWidth.
* Does not need to inherit from FabFragment
* Rename to TrendingAdapter
"Paging" in the adapter name is a misnomer here
* Clean up comments, use full class name as tag
* Simplify TrendingViewModel
- Remove unncessary properties
- Fetch tags and map in invalidate()
- emptyList() instead of listOf() for clarity
* Remove line dividers, use X-axis to separate content
Experiment with UI -- instead of dividers between each item, draw an explicit
x-axis for each chart, and add a little more vertical padding, to see if that
provides a cleaner separation between the content
* Adjust date format
- Show day and year
- Use platform attributes for size
* Locale-aware format of numbers
Format numbers < 100,000 by inserting locale-aware separators. Numbers larger
are scaled and have K, M, G, ... etc suffix appended.
* Prevent a crash if viewData is empty
Don't access viewData without first checking if it's empty. This can be the
case if the server returned an empty list for some reason, or the data has
been filtered.
* Filter out tags the user has filtered from their home timeline
Invalidate the list if the user's preferences change, as that may indicate
they've changed their filters.
* Experiment with alternative layout
* Set chart height to 160dp to align to an 8dp grid
* Draw ticks that are 5% the height of the x-axis
* Legend adjustments
- Use tuskyblue for the ticks
- Wrap legend components in a layout so they can have a dedicated background
- Use a 60% transparent background for the legend to retain legibility
if lines go under it
* Bezier curves, shorter cell height
* More tweaks
- List tags in order of popularity, most popular first
- Make it clear that uses/accounts in the legend are totals, not current
- Show current values at end of the chart
* Hide FAB
* Fix crash, it's not always hosted in an ActionButtonActivity
* Arrange totals vertically in landscape layout
* Always add the Trending drawer menu if it's not a tab
* Revert unrelated whitespace changes
* One more whitespace revert
---------
Co-authored-by: Nik Clayton <nik@ngo.org.uk>
Currently translated at 100.0% (560 of 560 strings)
Translated using Weblate (Italian)
Currently translated at 95.8% (537 of 560 strings)
Co-authored-by: Manuel <mannivuwiki@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/it/
Translation: Tusky/Tusky
Currently translated at 100.0% (560 of 560 strings)
Translated using Weblate (Catalan)
Currently translated at 100.0% (560 of 560 strings)
Translated using Weblate (Catalan)
Currently translated at 90.7% (508 of 560 strings)
Translated using Weblate (Catalan)
Currently translated at 76.7% (430 of 560 strings)
Co-authored-by: Ricard Torres <ricard@ricard.dev>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/ca/
Translation: Tusky/Tusky
* make BlocksAdapter use viewbinding
* remove LoadingFooterViewHolder
* cleanup code
* move accountlist to component packes
* make FollowRequestsHeaderAdapter use viewbinding
* add license to MutesAdapter
* move accountlist to component packages
* use ConstraintLayout in item_blocked_user.xml
* support the bot badge everywhere
* cleanup code
* cleanup xml files
* ktlint
* ktlint
* upgrade AndroidX dependencies
* use new @Upsert in InstanceDao
* fix crash because of new Room nullchecks
* make TimelineStatusEntity.reblogAccount a val as well
* Perform preference schema upgrades at startup
Over time it can be desirable to change how preferences are interpreted.
Preferences might be removed, or renamed. Or the default value for a
preference might be changed.
When this happens it's important that users upgrading from one version to
the next (or jumping from one version to several versions ahead) get a
consistent experience. In particular:
- Preferences that no longer exist should be deleted
- Preferences that have been renamed should have the old preference values
copied over
- If the user used the default value for the preference, and the default has
changed, the previous default value should be explicitly set as their
value for the preference
To support this, store a SCHEMA_VERSION as a preference. This is not exposed
to the user, and corresponds to the app's VERSION_CODE.
If the version code does not match the schema version then this is a newer
version of the app with older preferences that may need to be changed.
Those changes will be implemented in `upgradeSharedPreferences`.
* Translated using Weblate (Hungarian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Gera, Zoltan <gerazo@manioka.hu>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/hu/
Translation: Tusky/Tusky
* Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Eric <alchemillatruth@purelymail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/zh_Hans/
Translation: Tusky/Tusky
* Translated using Weblate (Ukrainian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Ihor Hordiichuk <igor_ck@outlook.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/uk/
Translation: Tusky/Tusky
* Translated using Weblate (Vietnamese)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Hồ Nhất Duy <mastoduy@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/vi/
Translation: Tusky/Tusky
* Translated using Weblate (Belarusian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Mikalai <mikalai.hryb@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
* Translated using Weblate (Belarusian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Andrej Zabavin <andre.zabavin@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
* Translated using Weblate (Belarusian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Mikalai <mikalai.hryb@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
* Translated using Weblate (Belarusian)
Currently translated at 100.0% (552 of 552 strings)
Translated using Weblate (Belarusian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: xzFantom <xzfantom@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
* Translated using Weblate (Japanese)
Currently translated at 91.3% (504 of 552 strings)
Co-authored-by: TAKAHASHI Shuuji <shuuji3@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/ja/
Translation: Tusky/Tusky
* Translated using Weblate (Icelandic)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Sveinn í Felli <sv1@fellsnet.is>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/is/
Translation: Tusky/Tusky
* Translated using Weblate (Belarusian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Mikalai <mikalai.hryb@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
* Lint
---------
Co-authored-by: Gera, Zoltan <gerazo@manioka.hu>
Co-authored-by: Eric <alchemillatruth@purelymail.com>
Co-authored-by: Ihor Hordiichuk <igor_ck@outlook.com>
Co-authored-by: Hồ Nhất Duy <mastoduy@gmail.com>
Co-authored-by: Mikalai <mikalai.hryb@gmail.com>
Co-authored-by: Andrej Zabavin <andre.zabavin@gmail.com>
Co-authored-by: xzFantom <xzfantom@gmail.com>
Co-authored-by: TAKAHASHI Shuuji <shuuji3@gmail.com>
Co-authored-by: Sveinn í Felli <sv1@fellsnet.is>
Verified by enabling "Pointer Location" in the developer options, and then experimenting to see which angles trigger opens of the nav. drawer, and in a stock "Tabbed Activity" generated in Android Studio (New > Activity > Tabbed Activity) that uses ViewPager2.
Currently translated at 99.1% (555 of 560 strings)
Translated using Weblate (Swedish)
Currently translated at 98.0% (549 of 560 strings)
Co-authored-by: Elias Mårtenson <elias@dhsdevelopments.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/sv/
Translation: Tusky/Tusky
Currently translated at 99.8% (559 of 560 strings)
Co-authored-by: Grzegorz Cichocki <grzegorz.cichocki@pollub.edu.pl>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/pl/
Translation: Tusky/Tusky
Currently translated at 100.0% (560 of 560 strings)
Translated using Weblate (Welsh)
Currently translated at 100.0% (560 of 560 strings)
Co-authored-by: puf <puffinux@tutanota.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/cy/
Translation: Tusky/Tusky
Currently translated at 83.0% (465 of 560 strings)
Translated using Weblate (Spanish)
Currently translated at 94.1% (527 of 560 strings)
Translated using Weblate (Basque)
Currently translated at 78.5% (440 of 560 strings)
Translated using Weblate (Basque)
Currently translated at 78.5% (440 of 560 strings)
Translated using Weblate (Basque)
Currently translated at 78.5% (440 of 560 strings)
Translated using Weblate (Basque)
Currently translated at 78.5% (440 of 560 strings)
Co-authored-by: Aitor Salaberria <trslbrr@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/es/
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/eu/
Translation: Tusky/Tusky
* First attempt at user notifications of failure when media upload fails
* Drafts alert displays alert
* ktLint
* Fix defaced 46.json, add 47.json
* Mock draftsNeedUserAlert in MainActivityTest to prevent spurious failure
* Friendlier posts-failed message
* Create DraftsAlert object
* DraftsAlert works
* Not the cleanest, but DraftsAlert works with multiple accounts
* Use plural strings
* KtLint
* Clean up debug prints
* Simplify DraftsAlert per Conny suggestions
* Text change suggested by Conny
* ktLint again
* Back out test changes
* Fix MainActivityTest for new approach
* Tweak debug log
* Do not use GlobalScope for coroutines
* Check for status "type" before casting.
* Update app/src/main/java/com/keylesspalace/tusky/components/viewthread/ViewThreadViewModel.kt
Co-authored-by: Nik Clayton <nik@ngo.org.uk>
* Make sure no placeholder is returned as status
---------
Co-authored-by: Nik Clayton <nik@ngo.org.uk>
Currently translated at 88.4% (488 of 552 strings)
Translated using Weblate (Latvian)
Currently translated at 86.7% (479 of 552 strings)
Translated using Weblate (Latvian)
Currently translated at 84.4% (466 of 552 strings)
Co-authored-by: Mārtiņš Bruņenieks <martinsb@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/lv/
Translation: Tusky/Tusky
Currently translated at 100.0% (555 of 555 strings)
Translated using Weblate (Vietnamese)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: Hồ Nhất Duy <mastoduy@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/vi/
Translation: Tusky/Tusky
* Reinstate optional login via custom browser tab
* Clarify the buttons for the different login options
* Add informative labels for the different login options
* Move "Login with Browser" to the options menu
MIME type detection for files based on extensions (the `getType()` method)
returns incorrect results from DownloadProvider and FileProvider for (at
least) .m4a files.
Investigation details are in https://github.com/tuskyapp/Tusky/issues/3189
Be safe, and use `MediaMetadataRetriever` to sniff the content of the files
to determine the correct type.
Fixes https://github.com/tuskyapp/Tusky/issues/3189
Currently translated at 100.0% (552 of 552 strings)
Translated using Weblate (Belarusian)
Currently translated at 100.0% (552 of 552 strings)
Co-authored-by: xzFantom <xzfantom@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
* Mark *PreferencesFragment as @Keep
PreferenceFragment references them by string name, which doesn't work after
ProGuard has obfuscated the code in release mode. The name is no longer
valid and the app crashes.
Fixes https://github.com/tuskyapp/Tusky/issues/3161
* Prefer to keep Preference classes with a Proguard rule
Ensures that all PreferenceFragmentCompat are kept, to prevent the risk
that this could break in a new fragment where `@Keep` is accidentally
omitted.
* Handle preference fragments using the framework
The previous code started new preference "screens" as activities, even though
each one hosted a single fragment.
Modify this to use the framework's support for swapping in/out different
preference fragments.
PreferencesActivity:
- Remove the code for launching tab and proxy preferences
- Remove the code for setting titles, each fragment is responsible for that
- Implement OnPreferenceStartFragmentCallback to swap fragments in/out with
the correct animation
PreferencesFragment:
- Use `fragment` property instead of `setOnPreferenceClickListener`
- Set the activity title when resuming
Everything else:
- Set the activity title when resuming
* Implement HTTP proxy summary as a SummaryProvider
Uses the frameworks's support for setting summaries instead of rolling our
own.
Also fix a tiny bug -- the minimum port number to connect to should be 1,
not 0.
* Lint
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Change "Load more" to load oldest statuses first in home timeline
Previous behaviour loaded missing statuses by using "since_id" and "max_id".
This loads the most recent N statuses, looking backwards from "max_id".
Change to load the oldest statuses first, assuming the user is scrolling
up through the timeline and will want to load statuses in reverse
chronological order.
* Scroll to the bottom of new entries added by "Load more"
- Remember the position of the "Load more" placeholder
- Check the position of inserted entries
- If they match, scroll to the bottom
* Ensure the user can't have two simultaneous "Load more" coroutines
Having two simultanous coroutines would break the calculation used to figure
out which item in the list to scroll to after a "Load more" in the timeline.
Do this by:
- Creating a TimelineUiState and associated flow that tracks the "Load more"
state
- Updating this in the (Cached|Network)TimelineViewModel
- Listening for changes to it in TimelineFragment, and notifying the adapter
- The adapter will disable any placeholder views while "Load more" is active
* Revert changes that loaded the oldest statuses instead of the newest
* Be more robust about locating the status to scroll to
Weirdness with the PagingData library meant that positionStart could still be
wrong after "Load more" was clicked.
Instead, remember the position of the "Load more" item and the ID of the
status immediately after it.
When new items are added, search for the remembered status at the position of
the "Load more" item. This is quick, testing at most LOAD_AT_ONCE items in
the adapter.
If the remembered status is not visible on screen then scroll to it.
* Lint
* Add a preference to specify the reading order
Default behaviour (oldest first) is for "load more" to load statuses and
stay at the oldest of the new statuses.
Alternative behaviour (if the user is reading from top to bottom) is to
stay at the newest of the new statuses.
* Move ReadingOrder enum construction logic in to the enum
* Jump to top if swipe/refresh while preferring newest-first order
* Show a circular progress spinner during "Load more" operations
Remove a dedicated view, and use an icon on the button instead.
Adjust the placeholder attributes and styles accordingly.
* Remove the "loadMoreActive" property
Complicates the code and doesn't really achieve the desired effect. If the
user wants to tap multiple "Load more" buttons they can.
* Update comments in TimelineFragment
* Respect the user's reading order preference if it changes
* Add developer tools
This is for functionality that makes it easier for developers to interact
with the app, or get it in to a known-state.
These features are for use by users, so are only visible in debug builds.
* Adjust how content is loaded based on preferred reading order
- Add the readingOrder to TimelineViewModel so derived classes can use it.
- Update the homeTimeline API to support the `minId` parameter and update
calls in NetworkTimelineViewModel
In CachedTimelineViewModel:
- Set the bounds of the load to be the status IDs on either side of the
placeholder ID (update TimelineDao with a new query for this)
- Load statuses using either minId or sinceId depending on the reading order
- Is there was no overlap then insert the new placeholder at the start/end
of the list depending on reading order
* Lint
* Rename unused dialog parameter to _
* Update API arguments in tests
* Simplify ReadingOrder preference handling
* Fix bug with Placeholder and the "expanded" property
If a status is a Placeholder the "expanded" propery is used to indicate
whether or not it is loading.
replaceStatusRange() set this property based on the old value, and the user's
alwaysOpenSpoiler preference setting.
This shouldn't have been used if the status is a Placeholder, as it can lead
to incorrect loading states.
Fix this.
While I'm here, introduce an explicit computed property for whether a
TimelineStatusEntity is a placeholder, and use that for code clarity.
* Set the "Load more" button background to transparent
* Fix typo.
* Inline spec, update comment
* Revert 1480c6aa3ac5c0c2d362fb271f47ea2259ab14e2
Turns out the behaviour is not desired.
* Remove unnecessary Log call
* Extract function
* Change default to newest first
Currently translated at 98.5% (538 of 546 strings)
Translated using Weblate (Belarusian)
Currently translated at 90.4% (494 of 546 strings)
Translated using Weblate (Belarusian)
Currently translated at 81.1% (438 of 540 strings)
Translated using Weblate (Belarusian)
Currently translated at 77.2% (417 of 540 strings)
Co-authored-by: xzFantom <xzfantom@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
Currently translated at 100.0% (546 of 546 strings)
Translated using Weblate (Vietnamese)
Currently translated at 100.0% (540 of 540 strings)
Co-authored-by: Hồ Nhất Duy <mastoduy@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/vi/
Translation: Tusky/Tusky
Currently translated at 79.6% (435 of 546 strings)
Translated using Weblate (Latvian)
Currently translated at 75.0% (410 of 546 strings)
Translated using Weblate (Latvian)
Currently translated at 72.9% (394 of 540 strings)
Translated using Weblate (Latvian)
Currently translated at 62.4% (337 of 540 strings)
Co-authored-by: Mārtiņš Bruņenieks <martinsb@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/lv/
Translation: Tusky/Tusky
Currently translated at 100.0% (546 of 546 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (540 of 540 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (540 of 540 strings)
Co-authored-by: Ihor Hordiichuk <igor_ck@outlook.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/uk/
Translation: Tusky/Tusky
Currently translated at 100.0% (546 of 546 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (540 of 540 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (540 of 540 strings)
Co-authored-by: Eric <alchemillatruth@purelymail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/zh_Hans/
Translation: Tusky/Tusky
Currently translated at 100.0% (546 of 546 strings)
Translated using Weblate (Welsh)
Currently translated at 100.0% (540 of 540 strings)
Co-authored-by: Rhoslyn Prys <post@meddal.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/cy/
Translation: Tusky/Tusky
Robolectric normally swallows output from `Log.*` calls in tests and
the code under test. This can make debugging failing tests more
difficult than it needs to be.
Set `robolectric.logging.enabled` to `true` to enable the logs.
* Remove rxjava from API calls used by AccountListFragment
* Remove rxjava from API calls used by AccountViewModel::changeRelationship()
The affected API functions are also called from
- ReportViewModel.kt
- SearchViewModel.kt
- AccountListFragment.kt
- SFragment.java
- TimelineCases.kt
so they have also been updated.
This change requires bridging from Java code to Kotlin `suspend` functions,
by creating wrappers for the `mute` and `block` functions that can be
called from Java and create a coroutine scope.
I've deliberately made this fairly ugly so that it sticks out and can be
removed later.
* Use "Throwable" type and name
* Delete 46.json
Not sure where this came from.
* Remove rxjava from the deleteStatus call path
* Emit log messages with the correct tag
* Add another log tag, and lint
* Use TAG in log messages now it's present
* Lint
* Move viewModelScope.launch in to changeRelationshop()
* Use onSuccess/onFailure pair instead of fold
* Return Deferred when deleting statuses
* Improve the actual and perceived speed of thread loading
To improve the actual speed, note that if the user has opened a thread from
their home timeline then the initial status is cached in the database. Other
statuses in the same thread may be cached as well.
So try and load the initial status from the database, falling back to the
network if it's not present (e.g., the user has opened a thread from the
local or federated timelines, or a search).
Introduce a new loading state to deal with this case.
In typical cases this allows the UI to display the initial status immediately
with no need to show a progress indicator.
To improve the perceived speed, delay showing the initial loading circular
progress indicators by 500ms. If loading the initial status completes within
that time no spinner is shown and the user will perceive the action as
close-to-immediate
(https://www.nngroup.com/articles/response-times-3-important-limits/).
Additionally, introduce an extra indeterminate progress indicator.
The new indicator is linear, anchored to the bottom of the screen, and shows
progress loading ancestor/descendant statuses. Like the other indicator is
also delayed 500ms from when ancestor/descendant status information is
fetched, and if the fetch completes in that time it will not be shown.
* Mark `getStatus` as suspend so it doesn't run on the main thread
* Save an allocation, use an isDetailed parameter to TimelineStatusWithAccount.toViewData
Rename Status.toViewData's "detailed" parameter to "isDetailed" for
consistency with other uses.
* Ensure suspend functions run to completion when testing
* Delay-load the status from the network even if it's cached
This speeds up the UI while ensuring it will eventually contain accurate data
from the remote.
* Load the network status before updating the list
Avoids excess animations if the network copy has changes
* Fix UI flicker when loading reblogged statuses
* Lint
* Fixup tests
The intent of the previous code seems to be to show an "X" icon on a hashtag
chip when two or more chips are present.
This didn't work because the icon was not set as visible.
Fix this. In addition, set this as a "cancel" icon, not the chip's regular
icon, so it appears on the right (in LTR locales), as is normal for the
close button on chips.
Tinting the icon did nothing, so remove that.
* Share and copy menu items for account page (first attempt)]
* Always include domain in username in 'handle' copy
* Remove profile copy options, rename 'handle' to 'username'
* Long press on username in profile to copy it to clipboard
* Changes for code review: localUsername not username, Snackbar not Toast
* Do not trust getDomain() when getting full username. This means full-username build has to happen in AccountActivity instead of Account
* Replace != null -> \!\! idiom with more kotlin-y (and more threadsafe) ?.let pattern
* Unnecessary import
* Comment clarifying safety of \!\!
Tusky mostly uses (correctly, per Android style guide) sentence case (i.e.,
a single initial capital letter) in strings like "Scheduled posts" or
"Muted users".
But there are a few instances of title case (i.e., each initial letter is
capitalised) that have crept in ("Account Preferences", "Log Out",
"Follow Requests", etc).
Convert them to sentence case.
Currently translated at 98.7% (533 of 540 strings)
Translated using Weblate (Welsh)
Currently translated at 99.4% (535 of 538 strings)
Co-authored-by: Newidyn <grugallt@protonmail.ch>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/cy/
Translation: Tusky/Tusky
* show status edits part 1
* show status edits part 2 - load status edits
* fix code formatting
* add dialog to show status edits
* small improvements
* use ALIGN_CENTER to position status visibility icon when possible
* rename status_timestamp_info view to status_meta_info
* make dateFormat static
* remove commented-out code
* move edits to dedicated fragment
Currently translated at 49.9% (267 of 535 strings)
Translated using Weblate (Latvian)
Currently translated at 49.7% (266 of 535 strings)
Co-authored-by: Mārtiņš Bruņenieks <martinsb@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/lv/
Translation: Tusky/Tusky
Currently translated at 63.3% (339 of 535 strings)
Translated using Weblate (Belarusian)
Currently translated at 59.4% (318 of 535 strings)
Co-authored-by: xzFantom <xzfantom@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
* Fix saving changes to statuses when editing
With the previous code backing out of a status editing operation where changes
had been made (whether it was editing an existing status, a scheduled status,
or a draft) would prompt the user to save the changes as a new draft.
See https://github.com/tuskyapp/Tusky/issues/2704 and
https://github.com/tuskyapp/Tusky/issues/2705 for more detail.
The fix:
- Create an enum to represent the four different kinds of edits that can
happen
- Editing a new status (i.e., composing it for the first time)
- Editing a posted status
- Editing a draft
- Editing a scheduled status
- Store this in ComposeOptions, and set it appropriately everywhere
ComposeOptions is created.
- Check the edit kind when backing out of ComposeActivity, and use this to
show one of three different dialogs as appropriate so the user can:
- Save as new draft or discard changes
- Continue editing or discard changes
- Update existing draft or discard changes
Also fix ComposeViewModel.didChange(), which erroneously reported false if the
old text started with the new text (e.g., if the old text was "hello, world"
and it was edited to "hello", didChange() would not consider that to be a
change).
Fixes https://github.com/tuskyapp/Tusky/issues/2704,
https://github.com/tuskyapp/Tusky/issues/2705
* Use orEmpty extension function
* Handle preference fragments using the framework
The previous code started new preference "screens" as activities, even though
each one hosted a single fragment.
Modify this to use the framework's support for swapping in/out different
preference fragments.
PreferencesActivity:
- Remove the code for launching tab and proxy preferences
- Remove the code for setting titles, each fragment is responsible for that
- Implement OnPreferenceStartFragmentCallback to swap fragments in/out with
the correct animation
PreferencesFragment:
- Use `fragment` property instead of `setOnPreferenceClickListener`
- Set the activity title when resuming
Everything else:
- Set the activity title when resuming
* Lint
* Use the commit extension function
* Fix off-by-one error in HttpHeaderLink
Link headers with multiple URLs with multiple parameters were being parsed
incorrectly.
Detected by adding unit tests ahead of converting to Kotlin.
* Convert util/HttpHeaderLink from Java to Kotlin
* Convert util/ThemeUtils from Java to Kotlin
* Convert util/TimestampUtils from Java to Kotlin
* Add tests for PairedList
* Convert util/PairedList from Java to Kotlin
* Implement feedback from PR
* Relicense as GPL
These aren't necessary for the app, and are overwritten with the actual style
in `BaseActivity.onCreate()`.
But if they're missing the Android Studio layout preview renderer crashes.
* Leave the "edit scheduled status" button enabled after clicking
If the user submits an edit to the scheduled status then this one will be deleted, the paging source will notice, the adapter will be notified in the normal way, and this binding will be reused.
Or the user backs out of the edit, and this adapter entry is still valid and should remain clickable.
Fixes https://github.com/tuskyapp/Tusky/issues/2705
* Remove unnecessary parameter.
* Remove unnecessary import
* Fix auto play when swiping between attachments
Fixes an issue where attachment doesn't autoplay when swiping left/right from initial attachment.
Fixes#3066
* Fix lint error for wild card imports
* Convert AccountViewHolder from Java to Kotlin
Use view binding in the converted code, which requires small changes in code
that calls constructors.
Pass showBotOverlays as a parameter, rather than having the code reach in to
the shared preferences, fixing a layering violation. This affects callers
and classes derived from AccountAdapter.
* Use 2-arg getString
* Simplify setting bot badge indicator
- Specify the drawable in the XML
- Use visible() to set visibility
- Rename ID to account_bot_badge to make it clearer that this is all it is for
* Use lateinit to avoid needing !! later
* Remove rxjava from API calls used by AccountListFragment
* Remove rxjava from API calls used by AccountViewModel::changeRelationship()
The affected API functions are also called from
- ReportViewModel.kt
- SearchViewModel.kt
- AccountListFragment.kt
- SFragment.java
- TimelineCases.kt
so they have also been updated.
This change requires bridging from Java code to Kotlin `suspend` functions,
by creating wrappers for the `mute` and `block` functions that can be
called from Java and create a coroutine scope.
I've deliberately made this fairly ugly so that it sticks out and can be
removed later.
* Use "Throwable" type and name
* Delete 46.json
Not sure where this came from.
* Emit log messages with the correct tag
* Add another log tag, and lint
* Move viewModelScope.launch in to changeRelationshop()
Currently translated at 15.5% (83 of 535 strings)
Translated using Weblate (Belarusian)
Currently translated at 9.3% (50 of 534 strings)
Co-authored-by: xzFantom <xzfantom@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/be/
Translation: Tusky/Tusky
Currently translated at 100.0% (535 of 535 strings)
Translated using Weblate (Turkish)
Currently translated at 99.8% (533 of 534 strings)
Co-authored-by: Umit Kabuli <umitkabuli@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/tr/
Translation: Tusky/Tusky
Currently translated at 100.0% (534 of 534 strings)
Translated using Weblate (Welsh)
Currently translated at 98.6% (527 of 534 strings)
Co-authored-by: Rhoslyn Prys <post@meddal.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/cy/
Translation: Tusky/Tusky
Currently translated at 100.0% (535 of 535 strings)
Translated using Weblate (Vietnamese)
Currently translated at 100.0% (534 of 534 strings)
Translated using Weblate (Vietnamese)
Currently translated at 100.0% (532 of 532 strings)
Co-authored-by: Hồ Nhất Duy <duy@tutamail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/vi/
Translation: Tusky/Tusky
Currently translated at 100.0% (535 of 535 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (534 of 534 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (533 of 533 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (532 of 532 strings)
Co-authored-by: Ihor Hordiichuk <igor_ck@outlook.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/uk/
Translation: Tusky/Tusky
Currently translated at 100.0% (534 of 534 strings)
Translated using Weblate (Icelandic)
Currently translated at 100.0% (532 of 532 strings)
Co-authored-by: Sveinn í Felli <sv1@fellsnet.is>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/is/
Translation: Tusky/Tusky
Currently translated at 100.0% (535 of 535 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (534 of 534 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (533 of 533 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (532 of 532 strings)
Co-authored-by: Eric <alchemillatruth@purelymail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/zh_Hans/
Translation: Tusky/Tusky
Currently translated at 100.0% (534 of 534 strings)
Translated using Weblate (Turkish)
Currently translated at 99.6% (530 of 532 strings)
Co-authored-by: Ümit Solmaz <usnotv@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/tr/
Translation: Tusky/Tusky
Currently translated at 100.0% (535 of 535 strings)
Translated using Weblate (Swedish)
Currently translated at 100.0% (534 of 534 strings)
Translated using Weblate (Swedish)
Currently translated at 100.0% (533 of 533 strings)
Translated using Weblate (Swedish)
Currently translated at 100.0% (532 of 532 strings)
Co-authored-by: Jan Lindblom <janlindblom@fastmail.fm>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/sv/
Translation: Tusky/Tusky
* issue 2890: Add an "ALT" sticker to the media preview container if there are descriptions
* issue 2890: Use end and start for positioning
* issue 2890: Adapt to new media view group
* issue 2890: Use an indicator overlay for every (single) preview image
* issue 2890: Reduce radius to match that of the preview layout
* issue 2890: Remove (again) unused code
* issue 2890: Set visibility in any case
* issue 2890: Use a translatable text for ALT
* issue 2890: Show ALT flag only when showing media
* issue 2890: Call doOnLayout on the layout wrapper
* Add post editing capability
* Don't try to reprocess already uploaded attachments.
Fixes editing posts with existing media
* Don't mark post edits as modified until editing occurs
* Disable UI for things that can't be edited when editing a post
* Finally convert SFragment to kotlin
* Use api endpoint for fetching status source for editing
* Apply review feedback
* fix crash in TouchDelegateHelper when not all views are available
* filter views before passing to TouchDelegateHelper
* remove unused import
* fix indentation
* replace hard-coded strings with existing constants
* proxy port
* * custom proxy port and hostname inputs
* typesafety, refactor, linting, unit tests
* relocate ProxyConfiguration in app structure
* remove unused editTextPreference fn
* allow preference category to have no title
* refactor proxy prefs hierarchy/dependency
On smaller devices the notification filter listview may be longer than the
screen height, and pushes the "Apply" button out of sight.
Fix this by:
- Set the height of the listview to 0dp and its layout_weight to 1
- Set the layout_weight of the button to 0
This ensures the button always appears (because the listview height is 0dp)
and the listview then expands to fill any remaining space (because the
layout_weight is 1).
Fixes https://github.com/tuskyapp/Tusky/issues/2985
* Use light/dark mode colors for image description text
This is an accessibility issue -- in light mode (which should have dark text
on a light background) the text color was hardcoded to light grey and the
background color was a semi-transparent black.
Fixes https://github.com/tuskyapp/Tusky/issues/2983.
* Update app/src/main/res/drawable/ic_drag_indicator_horiz_24dp.xml
Co-authored-by: Konrad Pozniak <connyduck@users.noreply.github.com>
Co-authored-by: Konrad Pozniak <connyduck@users.noreply.github.com>
Currently translated at 100.0% (531 of 531 strings)
Translated using Weblate (Vietnamese)
Currently translated at 100.0% (529 of 529 strings)
Co-authored-by: Hồ Nhất Duy <duy@tutamail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/vi/
Translation: Tusky/Tusky
Currently translated at 100.0% (531 of 531 strings)
Translated using Weblate (Icelandic)
Currently translated at 100.0% (529 of 529 strings)
Co-authored-by: Sveinn í Felli <sv1@fellsnet.is>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/is/
Translation: Tusky/Tusky
Currently translated at 78.2% (414 of 529 strings)
Co-authored-by: batuhanakkurt <batuhanakkurt000@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/tr/
Translation: Tusky/Tusky
Currently translated at 99.0% (524 of 529 strings)
Translated using Weblate (German)
Currently translated at 99.2% (523 of 527 strings)
Co-authored-by: Vri <vrifox@vrifox.cc>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/de/
Translation: Tusky/Tusky
Currently translated at 100.0% (531 of 531 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (529 of 529 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (527 of 527 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (525 of 525 strings)
Co-authored-by: Eric <alchemillatruth@purelymail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/zh_Hans/
Translation: Tusky/Tusky
Currently translated at 100.0% (531 of 531 strings)
Translated using Weblate (Swedish)
Currently translated at 99.8% (530 of 531 strings)
Translated using Weblate (Swedish)
Currently translated at 100.0% (529 of 529 strings)
Translated using Weblate (Swedish)
Currently translated at 100.0% (527 of 527 strings)
Translated using Weblate (Swedish)
Currently translated at 100.0% (525 of 525 strings)
Co-authored-by: Jan Lindblom <janlindblom@fastmail.fm>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/sv/
Translation: Tusky/Tusky
Currently translated at 100.0% (531 of 531 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (529 of 529 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (527 of 527 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (525 of 525 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (507 of 507 strings)
Co-authored-by: Ihor Hordiichuk <igor_ck@outlook.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/uk/
Translation: Tusky/Tusky
Currently translated at 99.8% (526 of 527 strings)
Translated using Weblate (Occitan)
Currently translated at 98.2% (516 of 525 strings)
Translated using Weblate (Occitan)
Currently translated at 97.1% (510 of 525 strings)
Translated using Weblate (Occitan)
Currently translated at 96.7% (499 of 516 strings)
Translated using Weblate (Occitan)
Currently translated at 94.3% (486 of 515 strings)
Translated using Weblate (Occitan)
Currently translated at 94.1% (485 of 515 strings)
Translated using Weblate (Occitan)
Currently translated at 93.3% (477 of 511 strings)
Translated using Weblate (Occitan)
Currently translated at 91.3% (463 of 507 strings)
Co-authored-by: Quentí <quentinantonin@free.fr>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/oc/
Translation: Tusky/Tusky
* issue 2890: Show a warning icon if media description is missing
* issue 2890: Remove disturbing additional signs
* issue 2890: Add another icon; use a snackbar; change wording; use orange as color
* issue 2890: Remove now unneeded new resource
* issue 2890: Use a toast (also) to avoid elevation problems
* issue 2890: Use snackbar with elevation again; refactor a bit
* Convert NotificationsFragment to use view binding
* Use requireContext() in places a context is required
Removes a nullness warning.
* Simplify code by using .sublist() and .contains()
Removes a lint warning.
* Add @NonNull annotations to onViewTag and onViewAccount
* Use consistent comment styles
* Add a menu option to mute / filter a hashtag from a status list
Un/muting uses the "home" filter
* Set the initial mute button visibility from existing filters
Check the user's filters to see if the tag is already filtered from HOME.
If it is then the initial button is to unmute it. If it isn't then the
initial button is to mute it.
* Avoid "mute tag" menu items "popping" in
- Initial state shows the "mute" option, disabled
- Update the state after the API call completes
* Support a swipe down to dismiss video
Images can already be dismissed with a swipe, this adds the same
functionality to videos.
- Add a VideoActionsListener interface for the hosting activity to dismiss
the fragment
- Add a gesture listener for swipes
- Dismiss the fragment if a swipe has a greated Y component than X
Fixes https://github.com/tuskyapp/Tusky/issues/2833
* Scale the video view when dragging
Provides identical visual feedback to the same operation on images.