Bzr-Explorer: Embedding status output after executing qbzr dialogs.
craig Hewetson
I work on a source big tree and the delay is very noticeable.
It "seems" that the only reason for leaving the dialog open after executing qadd, qcommit and qupdate from bzr-explorer is that it gives the user the opportunity
to view the details of the result of the operation.
I'm thinking that if the "status panel" used in the qbzr dialogs can be embedded in bzr-explorer (maybe below the working tree status area) the dialogs can therefore
be "automatically closed" immediately after they are "successfully" executed. If they fail for some reason then the dialog remains open.
Doing this will give the user an advantage of (atleast) seening the last successful operation AND it will mean the user will NOT have to explicitly close the dialog every time (example of a potential paper cut).
Another thought is that if bzr-explorer can somehow determine from qbzr that the command was successful before the "embedded status panel" gets updated, bzr-explorer can then kick of a thread to refresh (bzr status) the
working tree status view, while the "embedded status panel" gets populated. (this will reduce the give the user the impression that delay has been reduced.)
Cheers
Ian Clatworthy
> Another thought is that if bzr-explorer can somehow determine from qbzr
> that the command was successful before the "embedded status panel" gets
> updated, bzr-explorer can then kick of a thread to refresh (bzr status) the
> working tree status view, while the "embedded status panel" gets
> populated. (this will reduce the give the user the impression that delay
> has been reduced.)
That's very doable. In fact, the branch operation implicitly opens the
new page on command completion, not on dialog close, so the signal is
available for use for immediate refreshing.
The only reason I went with 'refresh on dialog close' for everything
else was because it seemed a good idea at the time. (More explicitly, I
thought refreshing earlier would be surprising to the user.)
Would you like to have a good at a patch for changing this?
Ian C.
craig Hewetson
How does embedding the status panel sound? It allows the user to avoid having to explicitly close the dialog for certain operations and provides a history of operations of some sort.
Alexander Belchenko
How it will work with bzr-gtk?
Ian Clatworthy
> Ok I'll give it a shot....
Cool.
> How does embedding the status panel sound? It allows the user to avoid
> having to explicitly close the dialog for certain operations and
> provides a history of operations of some sort.
If commands complete successfully, we could implicitly close the dialog
if and only Explorer gave you a way of viewing the last few command
sessions.
What about adding a notification icon to the status bar? Clicking on it
would show the output of the last command in a modeless dialog. We might
want to provide access to the last N command outputs?
Here's a sketch ...
Recent commands: Output:
...
...
...
Selecting an item on the left would show the output on the right.
Sound OK?
Ian C.
craig Hewetson
If commands complete successfully, we could implicitly close the dialog
if and only Explorer gave you a way of viewing the last few command
sessions.
What about adding a notification icon to the status bar? Clicking on it
would show the output of the last command in a modeless dialog. We might
want to provide access to the last N command outputs?
Here's a sketch ...
Recent commands: Output:
...
...
...
Selecting an item on the left would show the output on the right.
Sound OK?
I'm not too keen on another popup... when updating in a checkout you need to see what changed and hiding it behind an icon will not be so nice since the user will most likely always want to see the output of bzr update. I've attached another mockup as an idea.
@Alexander
>>How it will work with bzr-gtk?
Ian Clatworthy
> I've attached another mockup as an idea.
That looks awesome.
It fits nicely with the general UI design I'm heading towards as well
where both the repository view and the status view will support a
configurable set of "reports" being displayed in that location.
To be more explicit, the idea is to have the one list of reports
including the current ones: Recent History, Local Changes, Missing
Revisions, Submit Report. The user will then be able to configure
whether each report is shown on the repository view, status view or both.
If you create the "Recent Commands" report, I'll put together the code
to hook it into the various views. :-)
> @Alexander
>>>How it will work with bzr-gtk?
> Maybe we need to have bzr explorer implement its own status panel and
> pipe the standard output to it. No change to qbzr then and therefor no
> change on bzr-gtk
I'd be fine with only initially supporting this for QBzr commands. I
suspect that would cover 95% of users.
Ian C.
craig Hewetson
If you create the "Recent Commands" report, I'll put together the code
to hook it into the various views. :-)
I'll see what i can do :)...
BTW where in bzr-explorer's source do you this:
>> In fact, the branch operation implicitly opens the new page on command completion, not on dialog close, so the signal is available for use for immediate refreshing.