Thomas Keller <[EMAIL PROTECTED]> writes: >>> b) would make me having to rebuild the whole inventory tree in the >>> GUI and thus loose the user's focus, which could be still in some >>> completly different context. >> >> I don't follow this. If by "focus" you mean the typical GUI notion of >> "which window receives input events", I don't see why that would be >> lost. > > Imagine an konqueror/explorer-like application with a folder tree on the > left and a file list on the right. The tree on the left displays a > certain state, i.e. shows all directories as expanded the user clicked. > The file list on the right lists the contents of the _active_ folder on > the left and may have a scroll offset and/or individual selection. > > Since the filesystem watcher updates to the model do happen > autonomously, I want to ensure that these view states are preserved as > greatly as possible,
Ok. But that's the responsibility of the GUI, not monotone. That's what the model/view/controller pattern is for. > but this also means that I can only do very restrictive querying and > updates to the underlying model. Of course, you do have to work with the GUI you have. Minimizing the updates for each run of monotone will make things simpler. > I'm pretty confident that the current restricted output is ok for my > application and doesn't harm any other existing implementation either ;) Right; all of the test cases are all still passing. >> The case where the user used "--bookkeeping-only" is odd, but I don't >> think that should bother this tool. > > I don't think --bookkeep-only is our problem, more f.e. IDEs like > Eclipse which may not be mtn-aware when they refactor / move code. Right. > So you end up having absolutely no sync between the filesystem and > the workspace manifest. Right. I've added a mechanism in Emacs DVC for this; it allows the user to identify the source and target rename files easily in the display of the results of mtn automate inventory. Then DVC issues the approprate mtn mv --bookkeep-only command to catch up. -- -- Stephe _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
