Currently translated at 100.0% (648 of 648 strings)
Translated using Weblate (Welsh)
Currently translated at 100.0% (647 of 647 strings)
Co-authored-by: fin-w <fin-w@tutanota.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/cy/
Translation: Tusky/Tusky
Found this crash in the Google Play reports:
```
Exception java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 0
at jdk.internal.util.Preconditions.outOfBounds (Preconditions.java:64)
at jdk.internal.util.Preconditions.outOfBoundsCheckIndex (Preconditions.java:70)
at jdk.internal.util.Preconditions.checkIndex (Preconditions.java:266)
at java.util.Objects.checkIndex (Objects.java:359)
at java.util.ArrayList.get (ArrayList.java:434)
at java.util.Collections$UnmodifiableList.get (Collections.java:1394)
at com.keylesspalace.tusky.components.compose.MediaPreviewAdapter.onMediaClick (MediaPreviewAdapter.java:45)
at com.keylesspalace.tusky.components.compose.MediaPreviewAdapter.access$onMediaClick (MediaPreviewAdapter.java:32)
at com.keylesspalace.tusky.components.compose.MediaPreviewAdapter$PreviewViewHolder._init_$lambda$0 (MediaPreviewAdapter.java:144)
at android.view.View.performClick (View.java:7535)
at android.view.View.performClickInternal (View.java:7512)
at android.view.View.-$$Nest$mperformClickInternal
at android.view.View$PerformClick.run (View.java:29488)
at android.os.Handler.handleCallback (Handler.java:984)
at android.os.Handler.dispatchMessage (Handler.java:104)
at android.os.Looper.loopOnce (Looper.java:238)
at android.os.Looper.loop (Looper.java:357)
at android.app.ActivityThread.main (ActivityThread.java:8118)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:957)
```
Can't reproduce, but seems to be some kind of race condition where the
view is clicked at the same time as it is being removed from the
`RecyclerView`. Not using the index in the click listener should resolve
the problem. Also refactored to `ListAdapter` to not deal with the
`AsyncListDiffer` manually.
Follow up to https://github.com/tuskyapp/Tusky/pull/3921
- no more hardcoded `tusky_blue`, instead the `colorPrimary` attribute
is used. This will help us when adding more themes, e.g a dynamic color
one.
- The `colorPrimary` of the dark theme is now lighter for more contrast
and subsequently the `colorOnPrimary` is now dark grey instead of white.
- `tusky_red_lighter` is now a bit more red than before
- Tweaked color usage in a few places for better contrast
I think this looks a bit unfamiliar but overall better and the higher
contrast makes things noticeably easier to read.
<img
src="https://github.com/tuskyapp/Tusky/assets/10157047/4cbb92d8-b772-4e94-bc15-c4baf0e5473f"
width="260"/>
This pull request aims to dramatically improve the performance of
`BlurHashDecoder` while also reducing its memory allocations.
- Precompute cosines tables before composing the image so each cosine
value is only computed once.
- Compute cosines tables once if both are identical (for square images
with the same number of colors in both dimensions).
- Store colors in a one-dimension array instead of a two-dimension array
to reduce memory allocations.
- Use a simple `String.indexOf()` to find the index of a Base83 char,
which is both faster and needs less memory than a `HashMap` thanks to
better locality and no boxing of chars.
- No cache is used, so computations may be performed in parallel on
background threads without the need for synchronization which limits
throughput.
## Benchmarks
Simple: 4x4 colors, 32x32 pixels output. (This is what Mastodon and
Tusky currently use)
Complex: 9x9 colors, 256x256 pixels output.
**Pixel 7 (Android 14)**
```
365 738 ns 23 allocs Trace BlurHashDecoderBenchmark.tuskySimple
109 577 ns 8 allocs Trace BlurHashDecoderBenchmark.newSimple
108 771 647 ns 88 allocs Trace BlurHashDecoderBenchmark.tuskyComplex
12 932 076 ns 8 allocs Trace BlurHashDecoderBenchmark.newComplex
```
**Nexus 5 (Android 6)**
```
4 600 937 ns 22 allocs Trace BlurHashDecoderBenchmark.tuskySimple
1 391 487 ns 7 allocs Trace BlurHashDecoderBenchmark.newSimple
1 260 644 948 ns 87 allocs Trace BlurHashDecoderBenchmark.tuskyComplex
125 274 063 ns 7 allocs Trace BlurHashDecoderBenchmark.newComplex
```
Conclusion: The new implementation is **3 times faster** than the old
one for the current usage and up to **9 times faster** if we decide to
increase the BlurHash quality in the future.
The source code of the benchmark comparing the original untouched Kotlin
implementation to the new one can be found
[here](https://github.com/cbeyls/BlurHashAndroidBenchmark).
Currently translated at 100.0% (647 of 647 strings)
Translated using Weblate (Italian)
Currently translated at 100.0% (645 of 645 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% (647 of 647 strings)
Translated using Weblate (Welsh)
Currently translated at 100.0% (645 of 645 strings)
Translated using Weblate (Welsh)
Currently translated at 100.0% (645 of 645 strings)
Co-authored-by: fin-w <fin-w@tutanota.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/cy/
Translation: Tusky/Tusky
https://docs.gradle.org/current/userguide/dependency_verification.html
Verification of checksums was easy to set up, but verification of
signatures is more involved as gradle couldn't do it automatically for
most dependencies. Checksum verification will already give us additional
security though so lets try it out.
closes#4499
This restores support for v1 filters. The problem was that the state was
uncoditionally set to error instead of checking the v1 response.
While checking the code I found some other problems:
- Two error messages that were shown to users were not translatable
- When filters were updated sometimes `PreferenceChangedEvent` was sent
instead of `FilterUpdatedEvent`
- The notifications fragment was not listening to the
`FilterUpdatedEvent`
This PR fixes https://github.com/tuskyapp/Tusky/issues/2798 and is
mostly based on and supersedes
https://github.com/tuskyapp/Tusky/pull/2826 but I have fixed all merge
conflicts and unit tests.
I tested the changes locally and the setting takes effect immediately
for replies, and persists across killing the app.
---------
Co-authored-by: Eva Tatarka <eva@tatarka.me>
Co-authored-by: Konrad Pozniak <connyduck@users.noreply.github.com>
As discussed in our contributors meeting.
Advantages:
- last element of list never obscured by action button
- less code that runs on every scroll
- less settings to worry about
Additionally:
- Added a (smaller) padding to the bottom of lists without action
button, I think it looks nice if there is a bit of white space and the
nav bar divider and the last list divider don't touch.
- The list of filters had no dividers, I added them.
- Recyclerviews with fixed height (Drafts, Filters, edits) now have
scrollbars
- code formatted all touched xml files
closes https://github.com/tuskyapp/Tusky/issues/1563
<img
src="https://github.com/tuskyapp/Tusky/assets/10157047/cd50199f-e84f-4402-93e4-a5a1beba2a08"
width="280"/>
Currently translated at 100.0% (645 of 645 strings)
Translated using Weblate (Ukrainian)
Currently translated at 100.0% (645 of 645 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% (645 of 645 strings)
Translated using Weblate (Italian)
Currently translated at 100.0% (643 of 643 strings)
Co-authored-by: Manuel <mannivuwiki@gmail.com>
Translate-URL: https://weblate.tusky.app/projects/tusky/tusky/it/
Translation: Tusky/Tusky
At first I thought simply changing the regex might help, but then I
found more and more differences between Mastodon and Tusky, so I decided
to reimplement the thing. I added 74 testcases that I all compared to
Mastodon to make sure they are correct.
On an Fairphone 4 the new implementation is faster, on an Samsung Galaxy
Tab S3 slower.
Testcases for the benchmark:
```
test of a status with #one hashtag http
```
```
test
http:// #hashtag https://connyduck.at/http://example.org
this is a #test
and this is a @mention@test.com @test @test@test456@test.com
```
```
@mention@test.social Just your ordinary mention with a hashtag
#test
```
```
@mention@test.social Just your ordinary mention with a url
https://riot.im/app/#/room/#Tusky:matrix.org
```
FP4:
```
11.159 ns 15 allocs Benchmark.new_1
119.701 ns 43 allocs Benchmark.new_2
21.895 ns 24 allocs Benchmark.new_3
87.512 ns 32 allocs Benchmark.new_4
16.592 ns 46 allocs Benchmark.old_1
134.381 ns 169 allocs Benchmark.old_2
28.355 ns 68 allocs Benchmark.old_3
45.221 ns 77 allocs Benchmark.old_4
```
SGT3:
```
43,785 ns 18 allocs Benchmark.new_1
446,074 ns 43 allocs Benchmark.new_2
78,802 ns 26 allocs Benchmark.new_3
315,478 ns 32 allocs Benchmark.new_4
42,186 ns 45 allocs Benchmark.old_1
353,570 ns 157 allocs Benchmark.old_2
72,376 ns 66 allocs Benchmark.old_3
122,985 ns 74 allocs Benchmark.old_4
```
benchmark code is here: https://github.com/tuskyapp/tusky-span-benchmark
closes https://github.com/tuskyapp/Tusky/issues/4425
Manuel
Danial Behzadi
fin-w
Konrad Pozniak
Christophe Beyls
Hồ Nhất Duy
renovate[bot]
Levi Bard
Ümit Solmaz
Deleted User
Anonymous
Quentí
Eliot Lash
Weblate
Ihor Hordiichuk
