Currently translated at 100.0% (609 of 609 strings)
Translated using Weblate (Vietnamese)
Currently translated at 100.0% (604 of 604 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% (609 of 609 strings)
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (604 of 604 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% (609 of 609 strings)
Translated using Weblate (Persian)
Currently translated at 100.0% (609 of 609 strings)
Translated using Weblate (Persian)
Currently translated at 100.0% (604 of 604 strings)
Co-authored-by: Danial Behzadi <dani.behzi@ubuntu.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/fa/
Translation: Tusky/Tusky
GBoard and other IME's support pasting images, which are converted to attachments.
Sometimes these have labels that describe the image. If present, set it as the default alt-text.
Fixes#3799
Fix a crash where workers, in some conditions, should show a notification. These are sent to a dedicated channel with no importance.
Convert NotificationWorker to a CoroutineWorker and remove its use of `runBlocking`.
Fixes#3754
Most lists in the app use (explicitly or implicitly) platform metrics for dimensions, text size, colour, and so on, possibly via styles.
A few don't, inadvertently using the user's setting for status text size
Fix these, and simplify code where possible.
- Use android attributes for padding and height, for consistent UX.
- Remove explicit usage of app:tabTextAppearance, rely on the style.
- Remove ListSelectionAdapter and item_picker_list.xml, and adjust TabPreferenceActivity to use an ArrayAdapter with simple_list_item_1.xml
- Simplify item_followed_hashtag.xml, consistent with item_list.xml.
Fixes https://github.com/tuskyapp/Tusky/issues/3131
Font scaling is applied in addition to any scaling set in Android system preferences. So if the user set the Android font size to largest (a 1.3x increase) and then sets the preference to 120%, the total change is 1.56x.
Create SliderPreference to adjust the preference.
- Use Slider, which supports float values and step sizes > 1
- Display the selected value in the preference's summary
- Provide buttons to increment / decrement the value
Restart the activity if the preference changes so that the user sees the impact of the change immediately. Fix a bug in PreferencesActivity where the "EXTRA_RESTART_ON_BACK" intent was never processed. Fix this to ensure that other activities are restarted so the new font scale takes effect.
Implement the scaling in BaseActivity by overriding onAttachBaseContext, and providing a wrapped context with the font scaling applied.
Fixes https://github.com/tuskyapp/Tusky/issues/2982, https://github.com/tuskyapp/Tusky/issues/2461
Instead of repeating the same if/else check on the error type when setting up the background message, move this in to BackgroundMessageView.
Provide different `setup()` variants, including one that just takes a throwable and a handler, and figures out the correct drawables and error message.
Update and simplify call sites.
Currently translated at 100.0% (604 of 604 strings)
Translated using Weblate (Persian)
Currently translated at 100.0% (603 of 603 strings)
Co-authored-by: Danial Behzadi <dani.behzi@ubuntu.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/fa/
Translation: Tusky/Tusky
This can happen if the edit history has not been propogated to the user's server.
If the edit history is missing then show an error with a link to the specifc Mastodon issue.
Fixes#3743
When the user is closing the compose view,
if it's new and empty, don't show a prompt.
if it's an existing draft and now empty, ask if the user wants to delete it or continue editing. I don't think there is much value in saving an empty draft.
---------
When NotificationWorker was moved from ...components.notifications to
...worker.
Installing Tusky with this change doesn't remove any future periodic
jobs queued under the old class name. So when Class.forName() is
called the old class name is not found, and the exception is thrown.
Handle this the same way androidx.work.WorkerFactory does -- catch
the exception, log it, and return null.
Fixes#3740
- Create a flow with new items (arbitrary ints) when a reload from the top should happen
- Combine this flow with notificationFilter, so changes to either of them trigger a reload
- Provide a menu item in NotificationsFragment to initiate the reload
- Handle the action in the view model
Remove the use of ReplacementSpan. It turns out this span type is incompatible with spans that occupy more than one line, and the result is that a longer diff can run off the end of the screen. The alternative means that the diff'd text doesn't have additional padding and rounded corners, but it's better than not being visible.
Display the most recent version of the status with larger text. Again, consistent with the thread view.
Display the avatar, name, and username of the poster in a pinned header at the top of the screen, instead of duplicating the information on every edit. This reduces the amount of redundant information on the screen.
The Android libraries have a bug where a TextView can forget that it contains selectable text, can be pasted in to, etc.
See https://issuetracker.google.com/issues/37095917
Fix this with an extension method that toggles the selectable state to re-enable it, and use this on the profile fields when editing an account.
Fixes https://github.com/tuskyapp/Tusky/issues/3706
- Use NO_POSITION instead of hardcoding 0.
- Don't set a state restoration policy, PagingDataAdapter already does that
- Return the closest item, not just the closest page, in getRefreshKey
It caused text size differences between the text in this view and all the other textviews in this layout.
It's not used in other layouts.
Fixes https://github.com/tuskyapp/Tusky/issues/3494
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
Santiago Kozak
Sotolf Flasskjegg
TAKAHASHI Shuuji
Ümit Solmaz
Gera, Zoltan
Deleted User
GunChleoc
Luna Jernberg
Manuel
Hồ Nhất Duy
Eric
Oliebol
Danial Behzadi
Nik Clayton
Konrad Pozniak
XoseM
Chaitanya
junius
Quentí
L.Yo
sk
Prat
Balázs Meskó
Levi Bard
João Alves
Mārtiņš Bruņenieks
Sveinn í Felli
Deleted User
Gordot Forrot
Andrés Blasco Arnáiz
Deleted User
Deleted User
Ihor Hordiichuk
puf
Deleted User