This is only when using the special Navigate → Move Focus to File Browser (⌥⌘⇥) command and is mainly because there is no other visual feedback (other than the text view being rendered in its inactive state).
I could see sometimes not wanting a selection in the file browser, this however seems like a general problem (i.e. the solution should likely be to introduce a way to “deselect all”).
We would previously bring up an “Do you want to keep unsaved changes?” sheet for these, so no convenience (i.e. batch closing several modified tabs) is really lost (on the contrary).
The reason for this is that NSTextField will draw itself in the “faded” state (for non-key windows) unless some of its parent views are marked opaque.
The previous problem with not having the parent views opaque (see da3a91a7bb) seems to have been solved by setting the autohidesScrollers property to YES.
The window border drawing seems to be done by the root content view so it’s best to keep it around (as it may also do other things that we are unaware of).
This fixes a crash bug when menu validation is invoked before the controller has set up a document. Hardening the other methods is just a precaution (as we generally shouldn’t make assumptions about the state of public properties.
This is instead of going through ‘self’ and was done to harmonize the code. Since two of the three variables are C++ types we cannot use dot syntax (self.property) when we wish to call a member function on the result, but using [self property] is ugly and would require us to then also use [self setProperty:value] (for consistency), hence why I went with direct access.
Since the selectedTabIndex property is closely related to documents and selectedDocument, I applied the same changes to this property.
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.
