The refresh helper uses the document’s undo manager in its destructor. Normally the document would stay open throughout the duration of the scope in which the refresh helper is used, but it might be possible to close the current document from a nested event loop, as spawned e.g. by showing a tool tip, in which case, the document will be closed when we reach the destructor.
It’s not feasible to maintain the old-style xib translations while we work on the UI. We’ll soon move fully to constraint-based layout which should allow translations to be purely string-based.
The gutter will invalidate its intrinsic size when its width changes which will cause the Cocoa layout engine to update the layout, so no more explicit code to deal with adjusting the gutter’s width.
Likewise, the height of the gutter (not the gutter scroll view) has been setup to match the height of the text view (again, not the containing scroll view). This avoids observing the text view frame and manually updating gutter height to match it.
There’s a few subtle advantages of going with a view, mostly theoretical (about minimizing refresh rectangles) but switching to constrained based layout should provide minor code simplifications, since our ancestor view won’t have to deal with the gutter divider rectangle.
This is an ongoing effort to refactor and simplify OakTextView. The goal is to move decisions up the hierarchy and instead have properties on the objects lower in the hierarchy (making the components more flexible and allowing for better decision making at the higher level).
We now require this to be set when changing theme, rather than have the IBeamCursor getter return a cursor appropriate for the current theme.
When switching themes we need to update several UI elements (scrollview background and knob style, gutter view, and possibly more in the future) so we might as well move the logic that picks the proper cursor color to this setup code.
Both from code and the menus. These were not implemented and I see no real reason to implement freehanded movement as a toggle since it is easily obtainable via column selections or option-clicking beyond EOL.
Overwrite mode might be implemented, but rather low priority.
1. Removed the alpha channels from all images.
2. Deleted unnecessary double images. (@sorbits: You might want to
rename them to more accurately display what they do.)
3. Slight adjustments to improve the visibility of the bookmark icons
at lower font sizes.
The advantage is that we avoid creating an off-screen image for compositing. We want to avoid off-screen images as they may not use the same pixel format/density as the render context (screen).
This removes all the blending, the need to provide a scope selector to obtain them, and no longer taxes the general syntax highlight (by no longer having to carry around a dozen gutter styles per scope).
When we update the text view frame we implicitly cause the gutter to refresh, which will ask for line records from the text view based on the selection, so we should ensure the selection is up-to-date before changing frame size.
This is to allow a bundle item to display another key than the one assigned to the item, e.g. when the bundle item is matched by a proxy item it should show that item’s key equivalent.
On Mountain Lion the OS provides a colorWithCGColor: which tmColorWithCGColor: now wraps for (when available).
This fixes a warning when building with the 10.8 SDK.
We now load the image via NSImage and creates a CGImageRef from that (based on the current graphics context). This ensures we get the @2px version when on a HiDPI display.
We filter out items that doesn’t have the current prefix and deselect current item if the user deletes the selection.
Some of this logic should probably be encapsulated by a filterPrefixString property added to OakChoiceMenu. This will also avoid the visual flash which arise when filtering the menu and selection changes (since we do one redraw w/o any items selected).
This is done using an alert with an accessory view. Not the best user experience, but given how rarely the user interacts with this, I wasn’t really in the mood to spend a lot of time on this part now (can always be improved later).
Closes issue #200.
