On Wed, May 20, 2009 at 11:37 PM, TK Soh <[email protected]> wrote: > On Wed, May 20, 2009 at 11:17 PM, Adrian Buehlmann <[email protected]> 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 <[email protected]> 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
Perhaps I spoke too soon. I double checked the overlay handler on stable, and it too doesn't update the parent folders of the modified files. Though pressing F5 would bring the icons up to date, and I believe this has been brought up too. > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
