On Wed, May 20, 2009 at 7:41 PM, Adrian Buehlmann <adr...@cadifra.com> wrote: > On 21.05.2009 01:37, TK Soh wrote: >> 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. > > No it really isn't. There is a reason why there is a hg status command. > Running > that command has a cost. > > Remember, we are talking about the icons on the _folders_, covering the sum > of whole subtrees. If it takes that long to compute them, I'd rather turn > the icons off on the folders (if I could). So if I want an update on the > folder icons, I'm fine with having to issue a context menu command. > > But maybe it's just me who is working on large trees and is willing to > pay that price in exchange for being able to quickly navigate inside it. > I also like being able to say when I want to spend that moment for updating > the icons on the folders. > > Also, in my trees I'm working a lot in quite narrow subtrees inside a specific > clone (I'm doing a clone when I need to work on specific issue or feature). > For example, in one project we have the source files related to storing > functions all together in the same subfolder. If I have a bug to fix about > storing things, I work in that folder, editing files. > So the set of modified directories doesn't actually change that often > in my workflow. > > But again, requirements can vary. I'm just not that obsessed with up-to-date > to the second icons on the folders in my everyday use. > > And remember, the icons on the files are still immediate (provided that > you can live with the already described consequences of the shellext > reading .hg/dirstate - I can, and the CuteHg project has decided to do > that too). One of them is that you have to hit F5 to update the file icons > of the files in a folder you have opened in explorer, if you do something > on the command line with mercurial on files in that folder (I could > call that doing something "behind the scenes", as you could have done it > with the context menu, which implicitly updates _all_ icons). > > But, for example, if I start editing a file that was not modified before > (green) and I have the folder containing that file open in explorer in > the background, the icon changes immediately to red when I save it in > my editor in the foreground, because explorer notices that the file has > changed an queries the shellext immediately. No need to hit F5 or even > execute "update icons" from the cmenu. > > Also, with current crew all the commands from the context menu do > a hg thgstatus implicitly when needed. This for example means that if you > select some new files and add them with the context menu, everything > -- including the icons on all folders in that repo -- is updated when > the hg add command is finished. Same with commit. Same with update from > the log dialog. Same with clone from the clone dialog. Same with adding > or removing files in the status dialog. Etc. > > So I don't see it that dramatic as you say. Certainly nothing unreasonable > here, I'd say. > > And it is very nice to have folder icons on the repo _roots_. You can forget > that on the old system. I have a folder where I have all my clones. > I now have an overview, in what repos I have changes. Yes, I do have to > run that refreshicons.cmd in the base dir (where I have all my clones). > It takes about 20 seconds here to update that overview of which of my > clones is modified and which isn't. And I have some thirty clones with lots > of files in it. I would have to navigate into each of them to see if > anything is changed under the old system. > > This is quite comparable to having to issue a hg status on the command > line, as the linux folks are doing it all the time. And some Windows users > do, who don't use the overlay icons (because, maybe they were just too slow). > > You can think of just seeing the result of your last 'hg status' (Update Icons > in the cmenu) on the folders in your tree while you navigate it with explorer. > Icons on the files in a specific folder you see show the state according > to what's in the .hg/dirstate, but file modification times freshly compared > in that > very moment you navigate into it (the files having status 'n' in .hg/dirstate) > > Is that really that unreasonable?
I need to take a step back from this for a couple of days and come at this from a different angle. Perhaps what we want is a taskbar daemon that watches directories, checks for changes periodically, and runs thgupdate when necessary. It could be entirely detached from the shell extension. That would be the full-service approach, as apposed to Adrian's preference of entirely manual. And each user could chose the approach they want on a repo-by-repo basis. Perhaps we want something entirely different. I tend to agree with Adrian, though, that the overlay code needs to be as efficient as we can make it, and as simple as possible. -- Steve Borho ------------------------------------------------------------------------------ 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
