The advantages are:
- More compatible with version control
- Easier to copy/paste menus and menu items between other projects
- Easier to setup menu delegates or obtain pointers to menu items
- We can use symbolic names when setting a menu item’s tag
- More transparent: We can read the declaration in a few minutes, use search, etc.
There are two disadvantage that I can think of:
1. We currently need to use private API to create the Open Recent submenu. Should this become a problem in a future macOS update, we can always create a single Open Recent menu in MainMenu.nib and use that when building our menu.
2. If you make a typo in the menu declaration then the compiler error will often just point to the first line of the declaration rather than the line with the incorrectly declared item. One can comment out sections to narrow it down, if many edits have been made since last compile.
This allows a simple way to build menus in code which can then be used with pop-up buttons or even the main menu of an application.
For creating the main menu, this should be done in an applicationWillFinish: delegate method. If done later, the Open Recent menu will not work.
There is a MBDumpMenu function which will take a menu as argument and output the MBMenu structure required to build the menu in code.
Can be used like this:
NSLog(@"\n%@", MBDumpMenu(NSApp.mainMenu));
Some caveats:
1. If you have alternate items *without key equivalents* then you need to ensure that `.modifierFlags` is set to include the modifier flags of the previous item plus an additional modifier key (the one to press to reveal this item).
2. The code does not know about outlets so check your MainMenu.nib in Xcode to see if you connect any outlets to menu items or submenus. If so, you can do `.ref = &menuItemOutlet` or `.submenuRef = &menuOutlet`. The former will store a pointer to the menu item in `menuItemOutlet` where the latter will store a pointer to the menu item’s submenu (and ensure a submenu gets created for this item, even if there are no submenu items defined).
3. The code will insert `«unknown»` for any unknown target or delegate, you will need to manually update this (but if you forget, it’ll result in a compiler error).
We already auto-hide them for majority of our scrollviews, but since they are hidden by default when using a trackpad, a few “new” scrollviews didn’t get this setting, and I hadn’t noticed.
Apple writes the encoding charset (e.g., com.apple.TextEncoding) in
all lowercase (at least since macOS 10.9); however, TextMate assumes that the
encoding will always be uppercase. So in order to avoid any issues with case
mismatches, when setting the charset, uppercase the given string.
See http://lists.macromates.com/textmate/2018-April/040602.html
This causes TextMate’s QL generator to take over thumbnail generation of all binary files (without a dedicated QuickLook plug-in), for example disk image files.
There does not seem to be any way to dynamically opt out of thumbnail generation, it’s all or nothing, therefor we would either need to completely remove support for thumbnail generation or not support QuickLook previews for files without extension.
For now it’s the latter.
This reverts commit fd827fb817.
Not only do we test for the presence of these functions at runtime, but we do not use them at all, when building with the 10.11 SDK (or earlier).
This is because if we had to support building with an earlier SDK it is not enough to declare the prototypes, we also need to add the symbols as weak to the linker options.
Not using the functions does not remove crucial functionality.
The algorithm to calculate exact rank requires n × m storage which is stack allocated, so for large strings, we could blow the stack.
Rather than switch to dynamic allocation, we’re just foregoing the exact rank, since for large strings, it’s unlikely to be useful to try to calculate such a thing.
Versions of the OS X 10.11 SDK prior to 10.11.4 require this to
be done explicitly. This fixes the build on OS X 10.10 when
using the OS X 10.11 SDK from Xcode 7.2.1 and earlier.
Modern multimarkdown tends to convert the <% and %> tags into HTML when they
occur before or after an empty line. This would then break parsing with erb.
Remove all empty lines in the vicinity of these tags to prevent this problem.
Sent in by @neverpanic through @ryandesign
When all paths had the same prefix as first item, the first item would be returned as the common ancestor even if the other paths were not children.
For example:
/path/to/some_folder
/path/to/some_folder_with_same_prefix
Here `/path/to/some_folder` was returned even though `/path/to` is the common ancestor.
The function is still not correct when all paths are actual descendants of first path, but since it’s only used for display purposes, and with “find in folder” (where paths shouldn’t overlap), I am not bothering with that issue.
Previously this database was loaded each time a file of unknown encoding was read, which could add a significant overhead when using “find in folder” with a large database and many files with unknown encoding.
The reason is that menuForEvent: will draw an outline around the items under the mouse, which can be incorrect when we use the keyboard.
While we can address it by creating a fake mouse event that points to the selection, this will fail when there is no selection, so I felt it was better to always forego it.
Comment also added to the source (since this workaround is not optimal, and I would like to find the correct solution):
If we use `self.size` for the off-screen image buffer then we get a scaled up 16×16 image in the file chooser (⌘T).
My theory is that when drawing the image, the image size is 16×16 but the graphics context uses a transformation so that each point is multiple pixels, which our off-screen image does not replicate.
I do not know how to get the actual “pixel size” of the destination, so using the largest image is a workaround and knowing the actual size could give a better result.
