편집 트랜잭션 외부에서 수행되는 장식적 속성에 대해 약간 혼란스럽다. "그리고 트랜잭션을 인지하지 못하는데, 이는 NSLayoutManager 자체에 존재하기 때문이지 NSTextStorage에 있는 것이 아니다"라고 했다. 색상과 같은 장식적 속성은 보통 NSTextStorage에 존재하는데! 저자는 마크다운 문자에 적용된 색상이 NSLayoutManager의 임시 속성 지원(일반적으로 철자가 틀린 단어를 색칠하는 데 사용됨)을 통해 이루어지고 있다는 것을 암시하는 건가? 그렇다면 그 목적은 무엇일까?
댓글 작성자는 텍스트 편집과 관련된 기술적인 세부사항에 대해 혼란을 느끼며, 장식적 속성이 NSLayoutManager와 NSTextStorage 사이에서 어떻게 다루어지는지에 대한 저자의 설명에 의문을 제기함.
정말 훌륭한 기사다(그리고 개인적으로도 시기적절하다. 현재 NSTextViews를 다루고 있음). 이 정보를 어떻게 얻었나? 다른 사람의 코드? 고통스러운 경험? developer.apple.com?
댓글 작성자는 기사가 매우 유용하다고 평가하며, 저자가 이러한 지식을 어떻게 얻었는지 궁금해함.
DOM 문서의 시대에(예: notion, gitbook), 나는 종종 텍스트 파싱과 조작에 마법 같은 일을 하기 위해 속성 문자열을 사용한다. 이것은 매우 우아한 구조이고 왜 이렇게 알려지지 않았는지 이해할 수 없다. 참고로 기사는 놀랍다
댓글 작성자는 속성 문자열을 사용하는 것이 우아한 방법이라고 생각하며, 이 기술이 더 널리 알려지지 않은 이유를 이해할 수 없다고 언급함. 기사에 대한 칭찬도 함께함.
나는 과거에 스크래치부터 자체 텍스트 에디터를 작성하려고 시도한 적이 있는데, 이런 자원이 있었다면 정말 대단했을 것이다.
댓글 작성자는 자신이 텍스트 에디터를 처음부터 만들려고 시도했던 경험을 언급하며, 이 기사가 그 당시에 있었다면 매우 도움이 되었을 것이라고 말함.
나는 오랫동안 안드로이드 앱 개발자였기 때문에, 애플이 사물을 다소 다르고 더 신중하게 접근하는 방식을 보는 것이 흥미로웠다. 안드로이드에서는 Layout 클래스(및 그 서브클래스)가 레이아웃과 렌더링과 관련된 모든 것을 처리하고, TextView는 편집/선택 논리의 일부를 구현한다. EditText와 TextView의 유일한 차이점은 EditText가 TextView에 이미 존재하는 편집 기능을 '활성화'한다는 것이다. 이러한 다소 일체형 접근 방식(그리고 불량한 API)의 문제점은 앱이 텍스트를 렌더링하는 방식에 대해 더 많은 제어가 필요할 경우 운이 없다는 것이다. 예를 들어, 레이아웃된 후 개별 글리프에 접근하고 싶다면? 아니, 미안하다.
댓글 작성자는 안드로이드와 애플의 텍스트 렌더링 및 편집 접근 방식의 차이점에 대해 설명하며, 안드로이드의 경우 더 세밀한 제어가 필요할 때 제한적이라는 점을 지적함.
TextEdit 앱은 거의 전적으로 단일 TextView로 구성되어 있다. 나는 WordPad가 Windows의 대응물이라고 생각한다. 이는 RichEdit 컨트롤을 기반으로 한다. 또 다른 재미있는 사실은 RTF가 기본적으로 NSAttributedString의 직렬화된 형태라는 것이다. Windows의 RichEdit 컨트롤에도 동일하게 적용된다. 실제로, Windows의 구현이 먼저 나온 것 같다: <a href="https://en.wikipedia.org/wiki/Rich_Text_Format" rel="nofollow">https://en.wikipedia.org/wiki/Rich_Text_Format</a>;
댓글 작성자는 TextEdit 앱이 TextView를 기반으로 하고 있으며, RTF(Rich Text Format)가 NSAttributedString의 직렬화된 형태라는 점을 언급함. 또한, Windows에서 비슷한 기능을 하는 RichEdit 컨트롤이 먼저 나왔을 수도 있다고 함.
이 앱을 정말 좋아한다. obsidian과 ia Writer를 포함한 다른 모든 마크다운 앱을 대체했다!
댓글 작성자는 해당 앱이 마크다운 작업을 위한 자신의 모든 기존 앱을 대체했다고 매우 만족해함.
다행히도 적어도 누군가는 2024년에도 Cocoa를 사용하고 있다.
댓글 작성자는 여전히 Cocoa 프레임워크를 사용하는 개발자가 있다는 사실에 안도감을 표현함.
iOS 컴포넌트에 대해 이런 문서가 더 많았으면 좋겠다!
댓글 작성자는 iOS 컴포넌트에 대한 이러한 유형의 문서가 더 많이 있었으면 좋겠다는 바람을 나타냄.
Hacker News 의견
이 글은 정말 좋다. TextKit에 대한 나의 기본 소개 자료로 <a href="https://:///www.objc.io&/…;" rel="nofollow">https://www.objc.io</a>를 대체할 것 같다.
편집 트랜잭션 외부에서 수행되는 장식적 속성에 대해 약간 혼란스럽다. "그리고 트랜잭션을 인지하지 못하는데, 이는 NSLayoutManager 자체에 존재하기 때문이지 NSTextStorage에 있는 것이 아니다"라고 했다. 색상과 같은 장식적 속성은 보통 NSTextStorage에 존재하는데! 저자는 마크다운 문자에 적용된 색상이 NSLayoutManager의 임시 속성 지원(일반적으로 철자가 틀린 단어를 색칠하는 데 사용됨)을 통해 이루어지고 있다는 것을 암시하는 건가? 그렇다면 그 목적은 무엇일까?
정말 훌륭한 기사다(그리고 개인적으로도 시기적절하다. 현재 NSTextViews를 다루고 있음). 이 정보를 어떻게 얻었나? 다른 사람의 코드? 고통스러운 경험? developer.apple.com?
DOM 문서의 시대에(예: notion, gitbook), 나는 종종 텍스트 파싱과 조작에 마법 같은 일을 하기 위해 속성 문자열을 사용한다. 이것은 매우 우아한 구조이고 왜 이렇게 알려지지 않았는지 이해할 수 없다. 참고로 기사는 놀랍다
나는 과거에 스크래치부터 자체 텍스트 에디터를 작성하려고 시도한 적이 있는데, 이런 자원이 있었다면 정말 대단했을 것이다.
나는 오랫동안 안드로이드 앱 개발자였기 때문에, 애플이 사물을 다소 다르고 더 신중하게 접근하는 방식을 보는 것이 흥미로웠다. 안드로이드에서는 Layout 클래스(및 그 서브클래스)가 레이아웃과 렌더링과 관련된 모든 것을 처리하고, TextView는 편집/선택 논리의 일부를 구현한다. EditText와 TextView의 유일한 차이점은 EditText가 TextView에 이미 존재하는 편집 기능을 '활성화'한다는 것이다. 이러한 다소 일체형 접근 방식(그리고 불량한 API)의 문제점은 앱이 텍스트를 렌더링하는 방식에 대해 더 많은 제어가 필요할 경우 운이 없다는 것이다. 예를 들어, 레이아웃된 후 개별 글리프에 접근하고 싶다면? 아니, 미안하다.
TextEdit 앱은 거의 전적으로 단일 TextView로 구성되어 있다. 나는 WordPad가 Windows의 대응물이라고 생각한다. 이는 RichEdit 컨트롤을 기반으로 한다. 또 다른 재미있는 사실은 RTF가 기본적으로 NSAttributedString의 직렬화된 형태라는 것이다. Windows의 RichEdit 컨트롤에도 동일하게 적용된다. 실제로, Windows의 구현이 먼저 나온 것 같다: <a href="https://en.wikipedia.org/wiki/Rich_Text_Format" rel="nofollow">https://en.wikipedia.org/wiki/Rich_Text_Format</a>;
이 앱을 정말 좋아한다. obsidian과 ia Writer를 포함한 다른 모든 마크다운 앱을 대체했다!
다행히도 적어도 누군가는 2024년에도 Cocoa를 사용하고 있다.
iOS 컴포넌트에 대해 이런 문서가 더 많았으면 좋겠다!