* Allow the user to customize the thread indentation
The user can now select if they want to indent threads/replies, and how much
the replies should be indented.
* Make the wording clearer
The wording is now clearer since "thread" is replaced by "reply".
* Fix localizations
---------
Co-authored-by: Thomas Ricouard <ricouard77@gmail.com>
If the content settings specify their own post settings and override the
instance settings, a hint (and link to the content settings) is added to the
instance settings (infos) since that setting might introduce confusion (As
happened in #1677).
Threads/replies are now shown more clearly. Each reply has an indentation level
(and therefore the number of vertical lines) one more than its direct parent.
This leads to siblings having the same indentation level. It makes
understanding somewhat complex thread structures way easier. Previously, a
reply was only indented if it came directly after its parent. If a toot had
more than one reply, the structure was nearly indecipherable, as it wasn't
clear which the parent post of the second (or later) toot was. An example is
"https://mastodon.social/@mhoye/110452462852364819" and all of its replies.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
The pending-button can now be shown in any corner the user prefers. This is
accomplished by allowing the user to move the counter left in addition to the
already present option to move it down. Fixes#1637
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
The crash will happen when you type something unexpected instance URL.
Example
```swift
let server = "mstdn.jp/"
var components = URLComponents()
components.scheme = "https"
components.host = server
components.path = "/api/v1/instance"
components.url! // 💥 error: Execution was interrupted, reason: EXC_BREAKPOINT (code=1, subcode=0x18c986650).
```
* Automatically remove spaces in server names
If a server name includes a space (which can happen if the string is pasted /
autocompleted), this space is removed, which results in the app not crashing.
Fixes#1599
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Format
---------
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
Co-authored-by: Thomas Ricouard <ricouard77@gmail.com>
* Allow specifying the visibility of replies
Replies can now have their own default visibility. This visibility is always at
least as restrictive as the default post visibility. When posting a reply, the
visibility is pre-populated with the more restrictive out of the default and
the visibility of the original post.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Use iOS-specific modifier
If the app is run on iOS 17, the new onChange(...)-modifier is used.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Restrict the extension of the onChange-Modifier
The extension of the view to allow the use of the version-appropriate
onChange-modifier is now only available in the relevant file.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Reset to use Xcode 14 / iOS 16
The iOS 17 specific changes are removed to allow building in the older Xcode 14.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Make the default reply visibility public
The standard default reply visibility is now public, the behavior of the app
isn't changed for a user who just updated.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
---------
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Add setting to control share button default behavior
This adds a setting to control the behavior of the share button on the status row actions view.
Currently, it always shares the link to the post as well as the post text.
In iOS 16.4, Apple added iMessage unfurling for Mastodon URLs.
When sharing posts from Ice Cubes via iMessage, this leads to the recipient seeing two copies of the post: one from the unfurled link and one from Ice Cubes including the post text.
Users will now have the option to exclude the post text from their sharing.
This is easier than tapping the 3-dots button on the post (which is kind of small) and then expanding the Share menu in the context menu, which is the other way to access this functionality at the
moment.
The default value for the new option will be "Link and Text", which is the current behavior - so we won't change the behavior on existing users.
* Add new strings to other language localizations
* Allow forced translation with DeepL
Translation with DeepL can now be forced either per post or on the system level.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Require the use of a private API key
A private API key of the user is now required to allow "always translate via
DeepL".
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Persist a stored API key
An API key is stored even if useOnlyDeepL is disabled. If the API key is empty,
the setting is still disabled.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Localize the texts
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Save API key while writing
The API key is now saved, even if the app is closed before leaving the
translation settings view.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Fix build
* Fix theme
* Transition to KeychainSwift, clean up
KeychainHelper is replaced with the already-used KeychainSwift package, the
functions are cleaned up so that the process is easier to understand. The
deactivateToggleIfNoKey function doesn't change the behavior of the buttons or
context menus in the timeline, only demonstrates the necessity of an API key to
the user. Consequently, it's only called when the settings view is shown.
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
* Swiftformat + fixes
---------
Signed-off-by: Paul Schuetz <pa.schuetz@web.de>
Co-authored-by: Thomas Ricouard <ricouard77@gmail.com>
