On Thu, Feb 05, 2009 at 08:22:29AM +0000, TK Soh wrote: > On Wed, Feb 4, 2009 at 5:16 AM, Steve Borho <[email protected]> wrote: > > On Wed, 2009-02-04 at 04:58 +0000, TK Soh wrote: > >> I just pull from you repo, but got a ImportError when trying to run > >> commit.py: > >> > >> ImportError: cannot import name ParseError > > > > My bad, I thought this exception was moved from cmdutil.py. It actually > > came from dispatch.py. I've pushed a fix. > > Here's some of my observation: > > Before anything further, I just want to state that I understand how > difficult it is to design a decent interface for this and that Steve > has put in a lot of good work into implementing this. So everything I > have to say is strictly my personal view being a user (vs. being a > developer).
This is the kind of feedback I'm looking for. > I understand now what was causing my confusion earlier. Clicking on > the Shelve button would shelve the visible (non-selected) diff hunks, > instead of the selected ones. IMO, it's not very intuitive. As a user, > I'd want to select the diff hunks that I _want to_shelve away, but now > I have to first select the diff hunks that I _don't want to_ shelve > away, then do the shelving. To make things more confusing, the diff > hunks will be folded up (or becomes strikethrough) when I double click > to select the hunks, giving me the wrong impression that they have > been shelved, while in actual fact the selected ones are to be keep > around instead. This does seem to be the most common reaction. People expect the shelve operation to work on the selected hunks, not necessarily those that are not-rejected. Still, I would like to get a vote on what people think would be more clear to first-time users: a) having separate dialogs for commit and shelve b) making shelve operate on selected hunks, while commit operates on non-rejected hunks (keeping both functions in one tool) c) Some other option we haven't discussed > I also prefer a "Hide Rejected Chunks" over the "Show Rejected Chunks" > checkbox. The difference between the two may be subtle, but it might > make it easier for new users on grasping the concept when facing the > strikethrough, vs something that disappear (folded) on me. In any > case, I still personally feel that the concept of 'rejected' chunks > might actually serve to add more confusion. It'd be simpler to have > just the 'selected' hunks and, perhaps, the 'shelved' hunks if it's to > be supported later. I agree with the name change for the checkbox. It's been my intention to expand on the shelve functionality to support multiple named shelves. Part of that will be the ability to browse the shelves and pick those to be re-applied to the working directory. I've always figured this would be a separate tool from the commit tool. > Double-clicking on file header inverse the selections. IMO, it should > select the all the diffs in the file, or unselect all if all the diffs > have been selected - this is actually the behavior of the checkbox on > the file-list header. One suggestion I have is to change the display > of the header to indicate that the whole file is either > not/partially/fully selected. That's feasible. We should do this regardless of the other changes we're considering. > Having said all these, I still feel that the strikethrough font is > better used for represent shelved hunks. We should find a different > visual representation for 'selected' hunks. I would like to keep the shelve hunks separated from the working directory hunks, for simplicity's sake (they may conflict). But I'm open for ideas on better ways to visualize rejected hunks. > In the case of commit, the idea of rejected chunks also create some > confusion, as they will still be committed even they have been marked > as 'rejected'. ? this shouldn't be the case. > BTW, the record (commit selected diff hunks) functionality doesn't > seemed to be supported directly. Maybe I missed it somehow? I wonder if you were bitten by the Windows GTK bugs. The difftree widget gets confused when you toggle the 'show rejected chunks' button. In that function I clear the tree attributes and write new ones and this doesn't seem to work correctly on Windows. -- Steve ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
