我正在研究基於可可的文本編輯器。我應該將其基於NSTextView還是有更高效的選項?請記住,我計劃支持製表符,以便可以同時打開許多編輯器。基於可可的文本編輯器的選項
回答
我正在研究基於可可的文本編輯器。我是否應該將其基於NSTextView
是的。
還是有更高效的選擇?
沒有,假設「效率」包括您自己的時間和精力權衡功能設置要支持,可可的文字系統確實很多你,你會被扔掉,如果你滾你擁有。
一些例子:
- 撤消支持
- 高級編輯(emacs的鍵)
- 支持輸入經理/輸入法
- 支持所有Unicode的
- 鼠標選擇
- 鍵盤選擇
- 多選 種
- 字體
- 顏色
- 圖片
- 聽起來
- 查找
- 查找和替換
- 拼寫檢查
- 語法檢查
- 文本替換
- 無障礙
如果你推出自己的產品,你會花費幾個月的時間重新開發和調試一些,如果不是大多數(如果不是全部)那些車輪。我稱之爲效率低下。
與此同時,您已經擁有的文字系統幾乎都是快速的。你需要長長的線條(或者許多嵌入的圖像/聲音)的巨大文本來阻止它。
請記住,我計劃支持選項卡,以便可以同時打開許多編輯器。
除非用戶打算一次輸入所有這些數據,否則我不會看到這會導致性能問題。 0%CPU×N或N-1視圖= 0%CPU。
可能有一個問題是內存使用情況,如果文件都很大。他們必須兩者都處於極端,因爲現在即使是一個普通的Mac也有1吉比特的內存,文本也不重要。
如果是這種情況,那麼您只能將最近使用的N個未修改文本保留在內存中,否則只記住選擇範圍的數組。但99%的時間,交換文本會比將它們全部留在內存中昂貴得多。
NSTextView可能是最簡單的方法,如果你想獲得大量免費的漂亮功能。它不能做任何事情,但這是一個非常棒的開始。
謝謝,這只是我一直在閱讀你應該如何避免爲提高效率而創建太多NSView的子類。 – Bret 2010-04-03 22:05:09
user308444:要麼你沒有看到上下文,要麼就是錯誤。除開發人員時間以外,子類除了開發人員時間以外不需要花費任何成本,除非您(1)在早期iPhone-OS硬件上運行或(2)創建數千個實例。更不用說,當您使用NSTextView時,您不會創建NSView的子類;實際上,任何「更有效的選擇」都可能是一個新的子類。更重要的是,正確的順序是寫入,然後配置文件,然後進行優化。優化首先會導致錯誤的決策和不必要的複雜代碼。 – 2010-04-04 05:42:34
- 1. 基於文本的選項選擇器
- 2. 日期選擇器文本框編輯不可編輯
- 3. 可編輯QComboBox:與項目文本同步編輯文本
- 4. 基於列表的可編輯gridview
- 5. 基於文本文件的文本編輯器鏈接
- 6. 基於瀏覽器的可視化編輯器/設計器?
- 7. 可編輯動態js中的文本選項
- 8. 多行可編輯的文本片段:可編輯的UILabel?
- 9. 富文本編輯基於Rails的CMS
- 10. 有沒有可以用於vue.js的文本編輯器?
- 11. GuidedStepFragment選項默認是可編輯的
- 12. 首選項中的可編輯列表
- 13. 如何使eclipse編輯器的標題文本可選?
- 14. 禁用可編輯文本 - 它不應該是可編輯的
- 15. 圍繞Java中的不可編輯文本編輯可編輯的JTextArea
- 16. 可選但不可編輯的html文本字段
- 17. 如何使可編輯的textarea文本不可選
- 18. TinyMce編輯器中的普通文本編輯器和富文本編輯器選項
- 19. 基於Web的PDF文檔編輯器
- 20. 可自定義的基於Web的編輯器?
- 21. 基於數據屬性的X可編輯選擇
- 22. 基於PSD的文件的基於Web的油漆編輯器
- 23. 關於文本編輯器和html輸出的基本信息
- 24. 基本的基於網絡的視頻編輯的當前選項是什麼?
- 25. 可編輯(jQuery就地編輯器):如何使文本沒有被選中,可編輯
- 26. 可編輯文本字段
- 27. 可編輯文本高亮
- 28. 可編輯文本框
- 29. 可編輯文本塊
- 30. Popover可編輯文本
謝謝。我有一種感覺,我是過度思考的事情 – Bret 2010-04-05 14:56:07