Navigation: Ideas |
The current Nautilus extension API is not rich enough for VCS integration.
Contents
Limitations and problems
Core
Description: update_file_info() gets called repeatedly without context when several files are being updated.
Applies to: All VCS (more relevant to some than others, depending on the overhead of opening the VCS metadata)
This is a problem because:
- Requires opening the VCS metadata for each update_file_info() call, which can hurt performance badly (in case of lots of files).
Possible improvements:
- Add plural version of update_file_info() to update the information for a list of files rather than for a single file, this should make it possible to open the VCS metadata only once.
- The default implementation could just fall back to update_file_info(), e.g.:
def update_files_info(self, files): return [self.update_file_info(f) for f in files]
Workaround(s):
- When reading VCS metadata, cache it and use the cache for subsequent calls until the VCS metadata changes.
Discussion:
Description: The status of a file can't be updated unless the file itself changes somehow, not if metadata about it stored elsewhere changes
Applies to: All VCS
This is a problem because:
- VCS metadata can be changed externally without changing the file itself. Example situations where this can happen:
- one of the Subversion file properties can be changed
only metadata is changed when doing a: svn add, svn commit, svn lock. See Inside the Working Copy Administration Area
- the file can be unversioned (without being removed from the file system)
- the Bazaar file id can be changed.
Possible improvements:
- Allow updating the file info in Nautilus from an extension manually as well (rather than just using a callback).
Workaround(s):
- Modify the file in some way to force update_file_info() to be called on it.
- Write your own inotify event processor to monitor changes to the wc administration area. For example in Subversion we'd notice the .svn/entries would change, we'd parse it to find out what item changed and how, and then we'd do our changes to the item accordingly (e.g. add_emblem, invalidate_extension_info() etc.)
Discussion:
I don't get the possible improvement suggested. Are you referring to the way that it isn't possible to get a NautilusVFSFile from a path/uri? If so, that seems unrelated. For that purpose at the moment we (NautilusSvn) keep a lookup table of NautilusVFSFiles to do that.
The question here is whether or not it's Nautilus's (libnautilus-extension) responsibility to figure out if a change to the wc administration area belongs to a certain file or not. This it probably isn't, but perhaps libnautilus-extension should be able to offer a mechanism for extensions to easily tell it about relations between metadata and an actual item.
Something that's easier to implement and would allow us to implement a workaround ourselves is simply for Nautilus to tell us about changes to a wc administration area too (see below). As this isn't done right now. -- BrucevanderKooij 2008-12-25 16:16:02
We do have nautilus_file_info_create[_from_uri]() now, So this should be fixable. -- AlexanderLarsson
Description:
- update_file_info is called only when:
- When you enter a directory (once for each item)
- When an item viewable from the current window is created or modified
Applies to: All VCS
This is a problem because:
- You're not notified about items you don't see, which is needed to keep the emblem for the directories above the item up-to-date. For example in TortoiseSVN a directory is regarded as modified if any of its children (depth=inifinty) are either added, deleted or modified.
Possible improvements:
- update_file_info should also be called when items not viewable (but that are children) are modified/created. So if you're in foo and see bar, but foo/bar/baz is modified you should still be notified abo