We need this when installing standalone bundle items, saving macros, and when creating items in the bundle editor without a bundle selected.
The user experience of this code is however rather poor in that you can’t actually crete new bundles, the dialog text is not specific, and the logic for what bundle to preselect can be improved (prefer previously created bundle falling back on a local bundle, if any).
We now use dispatch queues for updating bundles and bundle sources.
The determinate progress indicator is presently gone and so is the detailed info about which dependent bundles are being installed.
Some shortcomings:
1. Cache format is more wasteful (and kept in memory)
2. Device UUID and inode of root folder is not considered when replaying fs-events (we should do a recursive rescan if either changes).
On the bright side, the code better separates loading bundles from disk, and maintaining a disk cache updated via fs-events. This should make it easier to force cache invalidation when updating bundles from within TextMate (so we do not rely on fs-events) and to move bundle loading away from the main thread.
Additionally, by moving the bundle loading code to the bundle manager singleton, we’re introducing a single source of knowledge about “bundles on disk”, regardless of wether they are managed or not.
Initially I wanted all keys in a single header file but to avoid circular dependencies then this header would need to be in a framework that doesn’t depend on anything else, and the main benefit was only to have a single place to look for which keys exist, but now that we consistently prefix settings keys with ‘kUserDefaults’ then it’s easy to extract all keys via search.
Starting with Lion (I think) the progress bar at the Bundles preferences pane won’t always hide after having installed a bundle.
The progress bar is set to not show when stopped, but for some reason this property does not seem to always be respected, but if we manually set the progress to zero before setting the property (bound to ‘animate’) to NO, then it does properly hide.
We now explicitly disable it for targets that hasn’t yet been upgraded to ARC. This way, it’s easier to get an overview of which targets hasn’t yet been upgraded and ensures new targets has ARC enabled.
