feat: rebrand app as Syncline - #45
Conversation
# Conflicts: # DocmostlyMac/MacSettingsView.swift # docs/index.html # docs/privacy/index.html # docs/support/index.html
|
| Filename | Overview |
|---|---|
| docmostly/Features/Editor/NativeEditorBodyView.swift | Introduces focus-before-removal behavior, but makes deletion and merging depend on a best-effort responder callback. |
| docmostly/Features/Editor/NativeRichEditorViewModel.swift | Adds pending handoff state to isEditing, with incomplete cleanup when handoff fails. |
| docmostly/Features/Search/SearchViewModel.swift | Reworks search invalidation, request identity, cancellation, and pagination with strong stale-response protections and tests. |
| docmostly.xcodeproj/project.pbxproj | Consistently updates products, executables, test hosts, display names, and icon configuration for Syncline. |
| docmostly/Syncline.icon/icon.json | Defines the layered Syncline application icon and references the newly added SVG assets. |
| script/build_and_run.sh | Updates the expected macOS bundle and executable name to match the renamed product. |
Prompt To Fix All With AI
### Issue 1
docmostly/Features/Editor/NativeEditorBodyView.swift:293-294
**Focus Failure Drops Mutation**
The merge reports success immediately after requesting focus, but it changes the document only after the destination text input becomes focused. If the destination is not attached to a window, focus is skipped and the callback that performs the merge never runs. Because returning `true` already consumes the backspace, the user sees no document change. The deferred deletion path can likewise leave the block undeleted when destination focus fails. Perform the mutation independently of the focus callback or provide a fallback when focus cannot be acquired.
### Issue 2
docmostly/Features/Editor/NativeRichEditorViewModel.swift:38
**Handoff State Can Persist**
The pending focus marker now makes `isEditing` true, but focus-reset paths do not consistently clear it. If a requested handoff never acquires focus, this marker can remain set after focus is cleared. The view model then stays in an editing state without a focused text input, which can keep editing UI visible. Clear the marker whenever authoring or focus state is reset, not only when another input begins editing or the active block changes.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "Merge remote-tracking branch 'origin/dev..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| requestBlockFocus(destinationBlockID) | ||
| return true |
There was a problem hiding this comment.
The merge reports success immediately after requesting focus, but it changes the document only after the destination text input becomes focused. If the destination is not attached to a window, focus is skipped and the callback that performs the merge never runs. Because returning true already consumes the backspace, the user sees no document change. The deferred deletion path can likewise leave the block undeleted when destination focus fails. Perform the mutation independently of the focus callback or provide a fallback when focus cannot be acquired.
Prompt To Fix With AI
This is a comment left during a code review.
Path: docmostly/Features/Editor/NativeEditorBodyView.swift
Line: 293-294
Comment:
**Focus Failure Drops Mutation**
The merge reports success immediately after requesting focus, but it changes the document only after the destination text input becomes focused. If the destination is not attached to a window, focus is skipped and the callback that performs the merge never runs. Because returning `true` already consumes the backspace, the user sees no document change. The deferred deletion path can likewise leave the block undeleted when destination focus fails. Perform the mutation independently of the focus callback or provide a fallback when focus cannot be acquired.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
| } | ||
| } | ||
| } | ||
| var focusedTextInputBlockID: UUID? |
There was a problem hiding this comment.
The pending focus marker now makes isEditing true, but focus-reset paths do not consistently clear it. If a requested handoff never acquires focus, this marker can remain set after focus is cleared. The view model then stays in an editing state without a focused text input, which can keep editing UI visible. Clear the marker whenever authoring or focus state is reset, not only when another input begins editing or the active block changes.
Prompt To Fix With AI
This is a comment left during a code review.
Path: docmostly/Features/Editor/NativeRichEditorViewModel.swift
Line: 38
Comment:
**Handoff State Can Persist**
The pending focus marker now makes `isEditing` true, but focus-reset paths do not consistently clear it. If a requested handoff never acquires focus, this marker can remain set after focus is cleared. The view model then stays in an editing state without a focused text input, which can keep editing UI visible. Clear the marker whenever authoring or focus state is reset, not only when another input begins editing or the active block changes.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.1 participant
Summary
Verification
Bundle identifier remains ski.chef.docmostly so this updates the existing App Store record.