This is for attr.project.XXX and attr.scm.XXX, although the latter is also provided by scm::info_t.
With this commit, the file::path_attributes function no longer collect this information.
The idea was that e.g. a status bar may wish to not be opaque and rely on the window’s border to shine through.
Unfortunately there is an issue where if the view is not opaque, the user can drag the entire window by clicking the scroll knobs (requires scrollbars to be configured to be visible and using a mouse, a trackpad doesn’t seem to cause the issue).
The symbol chooser is now owned by DocumentView instead of DocumentController.
The symbol chooser does not know about its owner and is not an observer of any notifications. Instead it has a property for “document” and one for “selectionString”. It is the owners job to update these properties (i.e. when switching document or changing the selection).
Previously we placed the views with a one point gap between them and had the superview fill the background. This works fine, but has the somewhat theoretical disadvantage that the superview then needs to implement drawRect: and for performance reasons declare that it is “opaque” which means subviews can’t use the (true) window background, should they want to.
Also add a preferences key for “tabs above document” (issue issue #214), but not hooked up in this commit.
This is instead of placing it relative to the entire window. The main motivation is that with the file browser on the right, I want the file chooser closer to the left edge of the window.
My memory is a little vague here, but I believe the point of handling the menu keys was to workaround a bug in NSMenu.
The bug was that NSMenu would look at (the target of) cached menu items, probably for UI validation, so potentially sending methods to unretained objects, which could lead to a crash. Several workarounds were attempted (like clearing the target property after the menu had been displayed) but the only effective one was overloading key handling.
I’m quite sure though that this bug is no longer relevant.
Now resizing one subview has the other view locked at its current size and will stay at that size. Previously if you made the window smaller, causing the HTML view (on right) to shrink, and then resized the file browser to be smaller, the HTML view would grow until it had reclaimed the pixels lost during window resize.
Additionally, when resizing the window, the HTML view (on right) will shrink to its minimum size before the file browser starts to shrink. Previously this was “undefined” and after shrinking a window, you could actually see the two views resize to redistribute the loss.
The window uses the empty string, but since we use our represented file property to create proxy icons, test if we should setup SCM status watching, etc., we don’t want to test for either nil or empty string in all these places.
This fixes exception from creating OakFileIconImage from empty string.
This is only if there are no other documents with unsaved changes and the user has ‘open documents from last session’ enabled in preferences.
The rationale behind only offering it for untitled documents is that we can be sure that these will not be modified by another program while TextMate is not running. It also seems to be less valuable to have TextMate keep unsaved changes to a file that exist on disk, in fact, it’s a pretty bad behavior IMHO (and dangerous if other programs may work on the file).
These were set to ‘NSLayoutPriorityRequired-1’ which is higher than the window’s size constraints, meaning that resizing the window would not allow shrinking the file browser (or HTML output) views, furthermore, by making the views larger (when dragging the divider) the growth would not be constrained by the current window size, so it was possible to make the window grow with it.
The priority is now the proper NSLayoutPriorityDragThatCannotResizeWindow.
When opening a new window we ignore windows in full screen or on another space when searching for a window we can cascade to.
Full screen status of a window is restored after a relaunch and the bigger frame (when in full screen mode) is not stored in the session data or user defaults (as it should not be used).
Closes issue #667.
This is required to have the object respond to various action methods such as cut:, copy:, paste:, and delete: — ideally though the class would handle it by itself, as OFB responsibility is bleeding into the document controller (though long-term I think it makes sense to instead let the document controller implement the OFB action methods).
Preview can now be initiated with multiple items and while the preview panel is showing, one can use arrow up/down to switch to other items (in the file browser).
