On Wed, May 20, 2009 at 11:17 PM, Adrian Buehlmann <adr...@cadifra.com> wrote: > On 20.05.2009 19:35, Adrian Buehlmann wrote: >> On 20.05.2009 17:09, Steve Borho wrote: >>> On Wed, May 20, 2009 at 12:36 AM, TK Soh <teekay...@gmail.com> wrote: >>>> Just try it for a short time, but here's some observation so far: >>>> >>>> On overlay icons: >>>> - on first view, tracked folders have no overlay icons, and it's not >>>> obvious to user that a call to thgstatus is required. Some visual que >>>> is needed to signal that. >>>> - after thgstatus, untracked folders are marked as unchanged. >>>> - overlay icons on folders, including the root folders, don't reflect >>>> the correct status when files contained are modified/reverted/etc. >>>> Must run thgstatus to update. IMO, this is counter-intuitive. Can >>>> calls to thgstatus be automated? >>> We think a lot of the cases can be caught by Mercurial hooks, but that >>> will not catch changes made by the user. Ie: When they edit a file >>> the directory icons below it are not updated. It should be possible >>> to fix this when we refresh, but I don't know what Adrian's plans are >>> in this regard. >> >> I have none. I'm pretty much finished with this. > > To my surprise even the hooks thing is now pretty much ruled out by Matt > (as per his rejects of my patches on mercurial-devel), and the existing hg > hooks are largely unusable for getting up-to-date hg status update triggers > by Mercurial. > > So, unless we start routinely patching Mercurial, we will probably have to > live with what we have re icon updating. And most likely not worth investing > much more time on the updating overlay thing then. > > I think the current system in crew is still a big improvement over the old > pythonic shell extension and I will continue to use the new system as long > as I have to work on Windows :-).
Unfortunately, I can't agree with that. It's already bad enough to ask user to run Update icons to update the folder icons the first time, and telling them "you have to run it every time you change something" is simply unreasonable. The 'hg status' approach, other than being a little slower, is doing the thing right. I originally hope the dirstate approach can give us the speed improvement, which some acceptable (though reluctant) tradeoff, but I see now is simply too much a compromise for practical usage. What happen to the original dirstate implementation that doesn't require hgstatus? Or it has the same problem too? > For me, having to issue an "Update Icons" from the context menu now and > then is not such a big deal, compared to having that much comfort on > the speed side. > > And, after all, it was interesting to hack a bit on this thing. > > Cheers, > > Adrian ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ Tortoisehg-discuss mailing list Tortoisehg-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
