--ui-mode can be smarter

[Alexander Belchenko]

Last few days I'm using and dogfooding bzr-explorer for my work. I found --ui-mode for some action windows very boring in the case when operation has finished successfully. For example: qcommit stays on the screen after it has committed my changes successfully. That's boring. If there are no errors then I'd like to have it closed automatically when operation finished. Unfortunately our --ui-mode flag prevents this.

So my intent is to slightly change the behavior of --ui-mode and auto-close the dialogs on success.

But this change will effectively breaks old behavior and I don't like to break backward compatibility without a note. So I think the best way for me is to provide a configurable knob to change the behavior of --ui-mode.

[Dr Al (abudden)]

I like the idea of closing the windows, but I am a little edgy. In my ideal little world, what I'd love to see is auto-close on success, BUT an indication on the status bar of Bazaar Explorer to say (e.g.) "Committed successfully". If there's any output associated with the successful operation (e.g. if you do an update you'd get the list of files updated), you could click on the status bar text and the last output would be displayed in a window.

[Alexander Belchenko (bialix)]

Dr Al пишет:
> I like the idea of closing the windows, but I am a little edgy. In my
> ideal little world, what I'd love to see is auto-close on success, BUT
> an indication on the status bar of Bazaar Explorer to say (e.g.)
> "Committed successfully". If there's any output associated with the
> successful operation (e.g. if you do an update you'd get the list of
> files updated), you could click on the status bar text and the last
> output would be displayed in a window.

I think we need status area then. Using status bar for that could be
tricky to implement. But special status area (or status window) and one
line in the main area would be great.

That won't work for Tortoise unfortunately :-(

--
All the dude wanted was his rug back

[Martin Ueding (martin-ueding)]

I would like that too, the open window always suggests that there is still something working or to be done to me.

[Alexander Belchenko (bialix)]

So we can change the existing behavior to close the q-window and show
the info dialog with information about successful finish. Such info
window can be auto-closed after 5 seconds for example.

[Martin Ueding (martin-ueding)]

Opening another window would not really help, maybe it is easier to just close the task window (commit, …) automatically after a few seconds. The window already shows the success, so just closing it automatically would do the trick I think.

[Eric Siegerman (eric97)]

On the mailing list, Alexander Belchenko wrote:
> [Providing feedback on the Explorer status bar] requires even
> more tighter integration between qbzr and explorer, but this is
> already in my todo list. Also it may mean we need to drop support
> for bzr-gtk widgets in explorer.

This should be doable in a not-too-difficult, UNIX-idiomatic, and
backward-compatible way: define an optional environment variable, e.g.
BZR_STATUS_MESSAGE_FD, which, if defined, tells the subprocess to
write a one-line status message, suitable for display in
explorer's status area, to the specified file descriptor.

  - qbzr: If BZR_STATUS_MESSAGE_FD is defined, write a status
    message to the specified file descriptor

  - explorer:
      - Before forking, open another pipe
      - Pass the file-descriptor number of its write end as
        BZR_STATUS_MESSAGE_FD
      - When the subprocess returns, copy the first line from the
        pipe to the status area
      - If the pipe doesn't provide any data, create a generic
        message based on the subprocess's exit status
      - If the user clicks through on the status area, display
        whatever was read from stdout and/or stderr
      - In all of this, of course, do the appropriate
        deadlock-prevention magic

  - bzr-gtk (and any other widget provider that isn't
    status-aware) will ignore BZR_STATUS_MESSAGE_FD, and so
    (unless it's totally perverse) it won't write anything to the
    pipe; thus, explorer won't read anything, and so will produce
    the generic message

This mechanism could be made extensible by labelling the status
line in some way, thus leaving the door open for other,
differently labelled sections, and giving the environment
variable a suitably generic name. (Would the low-level bits of
the smart-server protocol be appropriate, with different
primitives of course, or would that be overkill?)

I don't know how to do all this on Windows, but I presume it's
doable, using whatever mechanism is already used to emulate the
relevant bits of the UNIX API.

  - Eric

[Alexander Belchenko (bialix)]

What I would like to change and what to achieve re bzr-explorer integration:

1) For regular usage (not explorer): close the action dialog automatically on success, and show instead much smaller dialog with only status of operation shown (with output from subprocess) and only button Close.

2) Better integration into explorer: automatically close the action dialog on success and send the output from subprocess to explorer via IPC (QLocalSocket) and be able to see it in explorer on separate pane (e.g. Command Result).