The former is mainly to allow using Open With from inside TextMate (to force open the document with TextMate), as you likely have Xcode setup as the default app to handle xib files.
This is only if the project directory is actually set at the time the default properties are expanded, so presently this has no effect (but will when TextMate sets a default value for the projectDirectory variable).
The menu item within is not hooked up to anything (as mentioned in issue #650) and as my idea for finishing the indent settings UI does not involve this menu item, I am removing it to avoid further confusion.
This key was previously assigned to File → Page Setup but as we currently don’t support that, and it is likely not going to see that big a use (when implemented) I think we can live without a key equivalent for that menu action.
Closes issue #525.
If user opens the dialog on one space, moves to another space (with a TextMate window) and then re-activate the (already open) dialog, it would previously switch back to the space containing the dialog, whereas with the changed setting, it now moves the dialog to the active space.
This should address issue #599.
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.
Ideally I also wanted to include project directory, but since the user’s properties are read after the default ones, and those contain the setup of projectDirectory, this isn’t possible with the current semantics.
This changes the way the include/exclude keys work: A path now *must* be matched by an include key to actually be shown.
The default value of the global include key has been changed to include “*” but if users have edited the value, they will see few or no files in the file browser.
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.
This is mainly for TextMate’s own Open With menu, as it doesn’t seem to affect Finder’s (and TextMate already did support folders being dragged onto its application icon).
This is done by overloading performKeyEquivalent: for the main menu (by setting it to OakMainMenu in MainMenu.xib).
The default implementation of performKeyEquivalent: does not know about scope selectors so it will sometimes call the wrong actions. For example a bundle overloading ⌘X for “-dyn.selection” may still see the item fire with a selection.
This wasn’t a problem previously, as we set the key equivalents via (deprecated) Carbon API (so presumably Cocoa didn’t know about the keys).
This is a preliminary implementation, I just want it out there to have it tested for edge-cases. Long-term we can probably remove the overload of performKeyEquivalent: on OakTextView, which sort of does similar (stops Cocoa from executing the wrong menu actions or interfering with multi-stroke key bindings).
