On Wed, Feb 11, 2009 at 3:25 AM, Steve Borho <st...@borho.org> wrote: > On Wed, 2009-02-11 at 00:34 +0000, TK Soh wrote: >> On Sun, Feb 8, 2009 at 11:58 PM, Steve Borho <st...@borho.org> wrote: >> > Hi folks, >> > >> > I've pushed a number of bug fixes for the commit tool to crew. If you >> > were waiting to try out the new record/selection features, now would be >> > a good time to take a first or second look. >> > >> > The 'hide rejected chunks' toggle is gone, since it seemed to confuse >> > people and was broken on Windows anyway. Strikethrough is also no >> > longer used on rejected hunks. Instead, the hunk background is darkened >> > and the text is scaled down to 60% size. Let me know what you think >> > about these changes. Scaled too far, not enough? >> >> The 'regected' hunks should still be kept readable so we can review >> them when needed, and 60% is too small for that. The use of different >> font size also makes the diff panes very 'jumpy' as we select/deselect >> the hunks. One idea I have is that, instead of playing with the font >> size, we can have a combination of removing the diff hunks coloring, >> and show the hunks as 50% gray (or whatever level of with gray with >> good readability) and italic font? > > That's doable. The italic font is easy, but removing the markup I think > will require two copies of the text. I'll give this a try. > >> > Partially selected files are now visually noticeable in two ways. The >> > 'inconsistent' state in the file list now works correctly, on Windows >> > the box is filled in like in a multiple choice exam. Also, the file >> > diff header has the tag '** Partial **' added to it. Let me know what >> > you think about this as well (is the text tag in the right place?) >> >> When a file is partial, it's associated file-list checkbox is >> disabled. It should be checked, but with some visual cue to indicate >> partial selection, or, errr, rejection. > > The checkbox is marked as 'inconsistent', but it's still enabled. > Having three states for the check box seems the best visual clue: > > checked - entire file is selected > inconsistent - part of file is selected
What does 'inconsistent' look like graphically? > unchecked - no part of the file is selected > > I can't think of any other visual clues that are as consistent with what > we're trying to convey. Maybe it's just me, I'll take third and fourth > opinions on this one. > >> > I have two TODOs yet before the 0.7 feature freeze (Feb 15th). >> > >> > 1) show diffs from copies/renames, allow their change selection >> > 2) move shelve feature into it's own dialog, so the status dialog will >> > have three modes: commit, shelve, status >> >> I tried the 'new' thgshelve window. IMO, it feel like a compromise to >> me to have it around, probably due to the lack of good representation >> on the selection of hunks. IMO (again), the shelve functionality is >> best, and should have no problem, offered within status/commit window, >> had a better visual algorithm is available. > > Until we do, I feel it's safer to keep them separated, since they have > completely different behavior. Honestly, it took me 15 minutes to split > it out. It would take less than 15 minutes to combine them again. I > would even be open to adding it back as an opt-in configuration for 0.7 > if there was interest. > > Optimally, we would come up with a selection algorithm that worked just > like gtk.SELECTION_MULTIPLE except it was sticky (no need to hold down > the ctrl key), and worked correctly with the keyboard. I like your idea > of tweaking the foreground text color. That's a start. > >> > I'm hoping for feedback as well about how to visualize a file's diffs >> > when it is entirely unselected. Should they be removed from the diff >> > list, or modified somehow? >> > >> > Should we put a comment above the diff list telling the user to 'toggle >> > hunks to exclude them from commit'? >> >> No offense, but I somehow have a feeling that the need to have this >> comment around actually points to the fact the concept of 'rejecting >> hunks' (vs selecting hunks) might be less intuitive than it should be. > > None taken, you are right. > >> Well, feature-freeze is around the corner. Guess it's too late this >> sort of discussion. > > No, this is the part that I want to get straight before the freeze, so > I'm happy to go another two rounds through this till we're happy with > the interface. The UI changes are low risk. > > -- > 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-discuss mailing list Tortoisehg-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
