There are some new rules, I think they mostly make sense, except for the
max line length which I had to disable because we are over it in a lot
of places.
---------
Co-authored-by: Goooler <wangzongler@gmail.com>
This adds support for the new Mastodon 4.2 role badges. Admins can
define if a role should be visible in the interface and then we get it
delivered by the Api on the `Account` object like this:
```
"roles": [
{
"id": "4",
"name": "TEST",
"color": "#ffee00"
}
]
```
- keeps compatibility with older Mastodon version and non Mastodon
servers
- Took me a while, but I figured out a way to use the color and have it
look ok on all backgrounds (Mastodon itself ignores the color and just
always uses its brand color)
- falls back to Tusky blue in case no color is configured
- I adjusted the "Follows you" and "Bot" badges so they match the new
badge style
- In case the "Follows you" and "Bot" badges are visible at the same
time, "Follows you" gets its own line and "Bot" goes into the same line
as the role badge.
- Will work even with a lot of role badges (right now users can only
have 1 role at once though)
- Will work even when the badges federate (right now they don't)
<img
src="https://github.com/tuskyapp/Tusky/assets/10157047/24cbe889-ae46-408e-bfa0-cf3fd3c24f74"
width="320" />
* Replace DefaultTextWatcher with extensions in core-ktx
* Fix positiveButton.isEnabled
* editable!! for highlightSpans
* Fix style
* Put noteWatcher back
* 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.
* 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
* 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
* 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
* 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
* 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 \!\!
* 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
* 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
The "Enable swipe gesture to switch between tabs" preference was ignored
on the tabs on a profile page ("Posts", "With Replies", "Pinned", "Media"),
and search ("Posts", "Accounts", "Hashtags").
Fix this.
While I'm here, replace a string for the preference name in MainActivity.kt
with a constant.
Fixes https://github.com/tuskyapp/Tusky/issues/2874.
* Show account's creation date in Profile.
* Fix broken test.
* Store account creation date in the Database.
* Reformat and reposition Joined Date according to PR Feedback.
* Revert "Store account creation date in the Database."
This reverts commit d9761f53 as it's not needed.
* Change Account's Creation Date to a java.util.Date.
Update Test.
* Fix wildcard import.
* Show full month instead of an abbreviation.
* Remove `lazy` usage in favor of local instantiation.
Co-authored-by: Martin Marconcini <martin.marconcini.rodriguez@nl.abnamro.com>
Co-authored-by: Konrad Pozniak <connyduck@users.noreply.github.com>
* Update to Emoji2
* Hopefully fix the emoji picker preference
* Switch to released Filemojicompat version
* Filemojicompat version as an own var
* Remove an unused import
* Small cleanup
* Correct onDisplayPreferenceDialog; test TuskyApplication
* Use TextViews instead of EmojiTextViews
* Recreate the Main Activity if the emoji pack is updated
* Enable coreLibraryDesugaring (for Java Streams); update Filemojicompat, downgrade Emoji2
* Update emoji font versions to 14
* Use FilemojiCompat 3.2.0-beta01
* Make ktLint happy again
* Remove coreLibraryDesugaring and a FIXME
* Use EmojiPickerPreference.get()
* Disable emoji pack import
* Update FilemojiCompat to Beta 2
* Update FilemojiCompat to Beta 3
* Update FilemojiCompat to Beta 3.2.0 final
* Update FilemojiCompat to 3.2.1
* Migrate LinkHelper to kotlin
* Support tags field on statuses
* Use embedded tags list in status instead of text scraping to embed tag click handler.
Fixes#2283
* Make mentions and tags lists nonnullable
* Make LinkHelper.openLink a Context extension method
* Use builtin extension for uri conversion
* More cleanup in LinkHelper
* Add tests for LinkHelper.getDomain
* Unbreak tags in places that don't have a tag list (e.g. profiles)
* Fixup javadoc
* update gradle, kotlin and other dependencies
* fix new warnings
* remove unused import
* update Proguard rules
* add explicit dependency on Gson to get the newest version
* remove debug flag from proguard rules again
* fix typo
Konrad Pozniak
UlrichKu
Conny Duck
Angelo Suzuki
Goooler
Nik Clayton
Levi Bard
mcclure
Eric Frohnhoefer
kyori19
Martin Marconcini
moddedBear
Constantin A
Mélanie Chauvel
