Initial experience with synchronization
Bels
was curious about the Qt port and decided to play around with it.
I have some initial thoughts on how the synchronization works (and
some related components) that I wanted to share before (or instead of)
creating various bug reports. Sorry if these should be separate
threads, but I didn't want to spam.
1) The Synchronize toolbar and view have different ordering of the
buttons. This is minor and may have been addressed by an earlier
thread (http://groups.google.com/group/thg-dev/browse_thread/thread/
a0f0d66d90def0ad#), but is confusing.
2) The interactions of how to check for incoming revisions is
confusing. Clicking the toolbar button opens the synchronize view,
which is a little jarring but not a big deal (and preferred if that
view is the synchronization one-stop-shop). However, I had a
repository with 105 incoming revisions and could not find any feedback
that the incoming process was still running. It did the initial
"searching..." progress for the incoming revisions but then that
disappeared. The log just had 'searching for changesets' and that was
it. I did not notice anything else to show that something was running.
After waiting a bit for it to finish, the incoming revisions were
shown.
2a) I found the log, but since it is shared across opened repositories
I had trouble finding the output for the particular repository I
needed. Perhaps the log can be made per-repository instead? Separating
it is especially nice since you permit users to type in it (which is
awesome to avoid opening a separate command window for extensions or
features that aren't yet fully integrated).
3) When showing incoming revisions I wanted to accept them. But it
took considerable searching to find the accept/reject buttons above
the graph (where the filter area is). I think that is very confusing,
especially coming from THg where the Cancel/Stop button changed to
Accept after the incoming revisions were fetched. I was looking in the
Synchronize view for these buttons since that is what clicking on the
toolbar directed me to initially. Putting them above the graph
involves to much up-down-up searching of the UI. A few weeks ago (when
I had some older installers), I think I closed the repository and re-
opened it which resulted in some errors. To get out of that state I
think I had to close/reopen the Workbench.
4) I know this was discussed in previous threads (http://
groups.google.com/group/thg-dev/browse_thread/thread/
fa289314d2af0a74/024c18c0977e4d97), but I find the disabled revisions
disorienting. I understand the need to differentiate the incoming
revisions (and the arrows are not favored), so perhaps just the colors
can be changed to make it look disabled, but not actually disable
clicking etc of them. If there is not a technical reason to disable
the revisions (some cache state getting mauled, etc?) it would be
ideal to allow them to be selected.
5) The status bar at the bottom did show some progress for pulling
revisions, but, similar to the log, since it wasn't repository-
specific, it was difficult to know which progress corresponded to
which repository. Similar to (2a), splitting up the status bar
information to be per-repository would also help with that. And
somewhat related, it was not possible at-a-glance to know which
repositories were in the middle of a process and which were simply
idle. Perhaps the tab could have some 'busy' indicator on it?
5a) Another minor thing, but I don't see the advantage of hiding tabs
if you only have a single repository open. The title bar changes, but
you can only view one tab at a time anyway. Instead, it would be nice
if the tabs could always be shown and the title bar is suffixed with
the name of the selected repository. Then there is no special cases
for tabs/titles.
I think that is about it. I will continue to play around with it, but
so far I really like how the tool is consolidating features into a
single dialog instead of needing multiple windows. And having the
tabbed repositories is awesome.
Bels
as of this AM:
1.1.9.1+50-08177bd... with Hg 1.7.5+4-8f5c... Python-2.6.6,
PyQt-4.8.2, Qt-4.7.1
Also another minor note: if I open and immediately close the About
dialog it hangs for say 45 seconds or so. If I just keep the dialog up
for those 45 seconds, then close it, it closes immediately.
André Sintzoff
> Ah sorry I forgot the version I was using. I got the latest installer
> as of this AM:
>
> 1.1.9.1+50-08177bd... with Hg 1.7.5+4-8f5c... Python-2.6.6,
> PyQt-4.8.2, Qt-4.7.1
>
> Also another minor note: if I open and immediately close the About
> dialog it hangs for say 45 seconds or so. If I just keep the dialog up
> for those 45 seconds, then close it, it closes immediately.
Do you need a proxy to access Internet?
If yes, how do you configure it? Is it via a PAC file?
If yes, you should configure a proxy in thg itself (via Settings...).
André
Bels
> 2011/2/11 Bels <sbelk...@gmail.com>:
Yea, we have a URL that has that PAC function call. I assume I can
setup Mercurial.ini to use that? If so I can look around in the hgrc
docs to find information.
Thanks
Steve Borho
> Hi all. I have been using THg for a while and like it quite a bit. I
> was curious about the Qt port and decided to play around with it.
>
> I have some initial thoughts on how the synchronization works (and
> some related components) that I wanted to share before (or instead of)
> creating various bug reports. Sorry if these should be separate
> threads, but I didn't want to spam.
>
> 1) The Synchronize toolbar and view have different ordering of the
> buttons. This is minor and may have been addressed by an earlier
> thread (http://groups.google.com/group/thg-dev/browse_thread/thread/
> a0f0d66d90def0ad#), but is confusing.
You've caught the nightly builds while we're tweaking the buttons,
trying to decide which way to go.
> 2) The interactions of how to check for incoming revisions is
> confusing. Clicking the toolbar button opens the synchronize view,
> which is a little jarring but not a big deal (and preferred if that
> view is the synchronization one-stop-shop). However, I had a
> repository with 105 incoming revisions and could not find any feedback
> that the incoming process was still running. It did the initial
> "searching..." progress for the incoming revisions but then that
> disappeared. The log just had 'searching for changesets' and that was
> it. I did not notice anything else to show that something was running.
> After waiting a bit for it to finish, the incoming revisions were
> shown.
There's a general Nit to show more progress bars for commands
Mercurial doesn't generate them itself. This is one such place where
a progress bar is needed.
> 2a) I found the log, but since it is shared across opened repositories
> I had trouble finding the output for the particular repository I
> needed. Perhaps the log can be made per-repository instead? Separating
> it is especially nice since you permit users to type in it (which is
> awesome to avoid opening a separate command window for extensions or
> features that aren't yet fully integrated).
An interesting thought. Too late for 2.0, but perhaps later. That
would simplify some things if there were one per repository.
> 3) When showing incoming revisions I wanted to accept them. But it
> took considerable searching to find the accept/reject buttons above
> the graph (where the filter area is). I think that is very confusing,
> especially coming from THg where the Cancel/Stop button changed to
> Accept after the incoming revisions were fetched. I was looking in the
> Synchronize view for these buttons since that is what clicking on the
> toolbar directed me to initially. Putting them above the graph
> involves to much up-down-up searching of the UI. A few weeks ago (when
> I had some older installers), I think I closed the repository and re-
> opened it which resulted in some errors. To get out of that state I
> think I had to close/reopen the Workbench.
Some of that is simply unlearning the GTK interface. The Workbench
displays incoming and outgoing changesets in the same way it displays
all revision set queries. I think this is cleaner in the long term.
> 4) I know this was discussed in previous threads (http://
> groups.google.com/group/thg-dev/browse_thread/thread/
> fa289314d2af0a74/024c18c0977e4d97), but I find the disabled revisions
> disorienting. I understand the need to differentiate the incoming
> revisions (and the arrows are not favored), so perhaps just the colors
> can be changed to make it look disabled, but not actually disable
> clicking etc of them. If there is not a technical reason to disable
> the revisions (some cache state getting mauled, etc?) it would be
> ideal to allow them to be selected.
I'm open to other styles of graph annotation, the disabled state
actually has rendering artifacts on Linux, so I would not be sad to
see it go. It would require a bit of extra logic in the menu handling
for incoming previews, but not much.
> 5) The status bar at the bottom did show some progress for pulling
> revisions, but, similar to the log, since it wasn't repository-
> specific, it was difficult to know which progress corresponded to
> which repository. Similar to (2a), splitting up the status bar
> information to be per-repository would also help with that. And
> somewhat related, it was not possible at-a-glance to know which
> repositories were in the middle of a process and which were simply
> idle. Perhaps the tab could have some 'busy' indicator on it?
Hmm, I suppose many tabbed web browsers do show a busy animation in the tab.
> 5a) Another minor thing, but I don't see the advantage of hiding tabs
> if you only have a single repository open. The title bar changes, but
> you can only view one tab at a time anyway. Instead, it would be nice
> if the tabs could always be shown and the title bar is suffixed with
> the name of the selected repository. Then there is no special cases
> for tabs/titles.
On laptops with 16:9 ratio screens, vertical space is precious. I
even move the toolbars to the left side of the Workbench on my Macbook
to squeeze out a few more vertical pixels.
I'm fine with unconditionally changing the window title, but I quite
like the disappearing repo tabs.
> I think that is about it. I will continue to play around with it, but
> so far I really like how the tool is consolidating features into a
> single dialog instead of needing multiple windows. And having the
> tabbed repositories is awesome.
I'm glad the general approach is getting good reviews.
--
Steve Borho
Bels
On Feb 11, 1:23 pm, Steve Borho <st...@borho.org> wrote:
their respective repositories. Perhaps in the short term, the
repository name can be prefixed to the progress (the horizontal space
allocated to the progress seems wide enough to allow at least 5-10
characters of the repository name). And longer term perhaps it can be
made repository-specific and/or have fancy tab animation if most folks
like that.
Steve Borho
Prepending the repository shortname would be trivial, if someone
wanted to do this.
>> > 5a) Another minor thing, but I don't see the advantage of hiding tabs
>> > if you only have a single repository open. The title bar changes, but
>> > you can only view one tab at a time anyway. Instead, it would be nice
>> > if the tabs could always be shown and the title bar is suffixed with
>> > the name of the selected repository. Then there is no special cases
>> > for tabs/titles.
>>
>> On laptops with 16:9 ratio screens, vertical space is precious. I
>> even move the toolbars to the left side of the Workbench on my Macbook
>> to squeeze out a few more vertical pixels.
>>
>> I'm fine with unconditionally changing the window title, but I quite
>> like the disappearing repo tabs.
>>
>> > I think that is about it. I will continue to play around with it, but
>> > so far I really like how the tool is consolidating features into a
>> > single dialog instead of needing multiple windows. And having the
>> > tabbed repositories is awesome.
>>
>> I'm glad the general approach is getting good reviews.
>> --
>> Steve Borho
>
--
Steve Borho
Bels
On Feb 11, 1:51 pm, Steve Borho <st...@borho.org> wrote:
edited as appropriate.
https://bitbucket.org/tortoisehg/thg/issue/124/add-repository-name-to-workbench-title
https://bitbucket.org/tortoisehg/thg/issue/123/improve-repository-progress-and-status
https://bitbucket.org/tortoisehg/thg/issue/122/associate-repository-to-progress-messages
https://bitbucket.org/tortoisehg/thg/issue/121/do-not-disable-revisions-on-incoming
https://bitbucket.org/tortoisehg/thg/issue/120/make-the-logs-in-the-workbench-per