When we see a changed item we drop it from the cache and mark the cache as “incomplete”, indicating that the bundle index should be rebuilt, which in turn causes all known items to be fetched, and the cache will thereby reload the updated entries.
However, when replaying fs-events, we are in a “rebuild index” state and would not re-rebuild the index incase items were dropped.
This makes loading time roughly twice as fast, although some of the speed gain is because we no longer need to convert CFPropertyListRef → plist::any_t.
The bundle item is causing ⌘Q to act subtlety different (issue #1031) but as we still see a lot of users on old versions, the item is still valuable to keep around.
This is work in progress, the reason why the situation arise has not yet been found and there are likely other ways in which the index can be wrong/stale (based on user reports like issue #998).
Since we get the failed sources by a const reference it is only live during the scope of the caller, and our use of blocks makes that scope shorter than the called block’s full scope.
We now store the time of last check in user defaults instead of via extended attributes on the source(s) and do a check every third hour, except of errors, where we retry after 30 minutes.
We now also check for bundle updates even if the sources hasn’t been updated. This is incase we previously updated a source but failed to then update bundles, these will now be updated when we retry, rather than next time the source index has updates.
Overall the code should be simpler and thus more robust. The text in the Bundles preferences page has also been improved slightly in that it will now tell the user if there was a problem updating the bundles, although for the specifics, the user will need to grab the log.
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.
