This doesn’t seem to be a requirement when using view-based NSOutlineViews, and as our implementation wasn’t actually doing any copying, better to not pretend we conform to this interface.
This function is called when running ‘bl’ and ‘test_network’, so previously we would end up with ‘bl.plist’ and ‘test_network.plist’ in ~/Library/Preferences.
Some commands clearly should not share output window frame, OTOH it might be tedious having to position every new command used (if the default position is undesired).
We should probably re-use last command’s frame if there isn’t already a frame stored for the command (that’s what TextMate 1.x did). It might also be possible to group commands via its semantic class, so all run commands use the same window frame, though currently semantic classes have unique (language) suffixes.
This is to decrease the tab width which technically should be doen by creating NSTextTab objects (with tab positions), but that is too complex and I think ideally we should visualize the tabs (e.g. “‣”) like we do in the search/clipboard history windows.
Previously, the commit window was changed from a "always on top" window to a more typical window that could be minimized or sent to the background. While this made viewing the diffs more convenient, we could easily loose track of it or at worst end up with multiple dangling commit windows. By making it document modal, this prevents dangling windows. Furthermore, since the commit window is now attached to the main project window and the file browser already has the SCM status, we hide the file list by default and dropped the action button. Users can choose to show the file list via a checkbox and the action button's menu is still available via the file list's context menu.
This improves the chance that someone googling for a certain accessibility
attribute or other accessibility constant in order to find inspiration how to
implement it will find our code in OakTextView. It also makes the code more
understandable for reading by someone else, and generally follows the way
others write accessibility code (including Apple in their code samples). It
does make the code more verbose, but I think that does not outweight the above
advantages.
Inspired by: googling and "githubbing" for NSAccessibilityLinkTextAttribute:
http://lists.apple.com/archives/accessibility-dev/2014/Aug/msg00016.html
This is for the “untitled save path” which is normally used for new untitled files, so we wouldn’t actually have a folder, however, the property is also used as a fallback for a “project folder” when that property is unset (which it generally shouldn’t be).
