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).
The issue this code solved was that setting the proxy icon via represented file before a file actually exists on disk would lead to no icon so we would have to update it again after a successful save.
This however is already done (by the save callback passed in).
We first search for a window containing one of the documents we wish to open, then for the window with a best match for project folder (for any of our documents), then check if frontmost window is a scratch window, and if none of the above gives a candidate, we create a new window (and give it a project folder based on the document(s) we opened).
Removed the ability to specify wether documents should open in current window or a new window — all documents opened via this API will go through the same algorithm to find where the documents should end up (more choice is just adding confusion and complexity).
It didn’t really make sense as an instance method since it iterate all instances, and we also want to execute code incase of no instances (save that fact as session data).
