On Sun, Jan 18, 2009 at 11:15 PM, TK Soh <[email protected]> wrote:
> On Mon, Jan 19, 2009 at 1:18 AM, Steve Borho <[email protected]> wrote:
> > On Sun, Jan 18, 2009 at 6:27 PM, TK Soh <[email protected]> wrote:
> >>
> >> On Sun, Jan 18, 2009 at 6:26 AM, Steve Borho <[email protected]> wrote:
> >> > It's my intention to unbundle Qct from THG by the next release (0.7).
> >> > I've
> >> > made a lot of progress in the last week incorporating Qct features
> into
> >> > the
> >> > native PyGtk dialogs.
>
> I just had a quick try....
>
> >> > Done:
> >> > * record/shelve support - better than Qct
> >> > * hgignore management - better than Qct
>
> Where do I find this?
>
context menu of unknown files, select ignore
> >> > * keyboard workflow - nearly as good as Qct
> >>
> >> You are the referring to keyboard shortcut? We should have them on all
> >> the GUI windows.
> >
> > I agree. Can we agree on common short-cuts for each dialog? We might
> > be able to add them in a general way.
>
> I guess we can just start with anything reasonable, then gradually
> polish them as we go. Only question now I have is "is it going to Alt-
> or Ctrl- for the accel keys?". We need to standardize on this.
>
Prefer ctrl myself, but could be convinced otherwise if GTK reserves
ctrl keys for other purposes.
> >>
> >> > * exposed gtools.diffbottom in thgconfig, for Qct style layout
>
> I think the TortoiseHg page is getting too crowded. Options specific
> for certain GUI are not immediately clear to users what they are for.
>
I agree, but it's not obvious to me how to group them. Feel free to move
them about.
> >> > TODO:
> >> > * Move precommit.username hook from hgconfig to hggtk and thgconfig
> >> > * Detect merges (two parents) and modify UI as necessary (disable file
> >> > selection, etc)
> >>
> >> We are already doing merge detection. Though I just found a small bug
> >> on the header checkbox, where it should have been disabled in merged
> >> repos.
> >
> > Yes, I saw that you did start work in this direction. The merge
> workflow,
> > where you're supposed to commit the entire workspace at once, didn't
> match well
> > with the new record/shelve features, so I made the merge case more
> "special". It
>
> I thought record/shelve are not permitted on merged repo, which
> requires all changes to be committed by Hg. No?
>
Yes, so I had to disable chunk selection entirely when there are two
parents. It uses
an entirely separate process to show merge diffs. It actually shows diffs
to both parents,
similar to the way Qct did it.
>
> > could probably use more work, but what I pushed this morning is close to
> > what I expect it will need to do.
> >
> >>
> >> > * Detect applied patch queue, switch to qrefresh mode, update patch
> >> > description
> >
> > I added basic support for qrefresh, much less than what Qct had, but it
> > dawned on
> > me that this really belongs in a separate app. We could make a pretty
> nice
> > MQ app with the record/shelve tools, but it doesn't belong in the
> commit/status
> > tool.
>
> One issue: I can't refresh on changes to commit message alone.
>
Yep. That's fixable, but will clutter the commit check logic.
> >>
> >> > * Unbundle qct and hgconfig from installer patch queue and forest
> >
> > This is done now, but untested.
>
> No hurry.
>
> >>
> >> > * Make sure Qct will work with THG when installed separately (new
> >> > windows
> >> > installer for Qct)
> >> > * copy/move/rename support
> >>
> >> I thought we just added them in 0.6. Maybe you meant to improve on them?
> >
> > Yes, I think there's room for more improvement here to help the user
> detect
> > renames and copies that were done without Mercurial's knowledge.
>
> It will be really nice if we can show more useful/meaningful info on
> renames and copies.
>
>
> Anyway, some issues and comment:
> - traceback when clicking on the filelist header checkbox.
woops, I broke this just recently.
>
> - traceback when I check the checkbox of an unknown file
probably the same bug. I just pushed a fix.
>
> - we should overstrike the diff header also, when all diffs of the
> file has been selected. This is especially necessary for binary files,
> since they only show the headers.
Hmm. Should be doable. The only way to tell now is to look at the
check-mark
in the file list.
>
> - when selection change on the filelist, we should scroll the diff
> window to expose the select file (like the changeset window).
it should be doing this already, though not all files have diffs
>
> - there's also a problem I has noticed for awhile: somehow the
> treeview widget has problem displaying grid line on the headers (which
> has a different background color from the default). I never found the
> solution to this though.
Yeah, that's wierd.
>
> Feature requests:
> - it'd be nice to provide some visual clue on the filelist for the
> files that contain selected diff hunks.
Some indication of a "mixed" state?
>
> - feature req: I'd really like to be able to copy the diff texts and
> paste it in an editor.
>
Shelving to a file would be useful as well. Should put both ideas on a TODO
list
somewhere.
Thanks for the feedback
--
Steve
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Tortoisehg-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
