Progress bars as widgets

[Jelmer Vernooij]

  affects /products/bzr-gtk
  status triaged
  importance medium

A widget should be added to bzr-gtk that can show progress rather than
using an external window for progress bars.

[Jeff Fortin Tam (kiddo)]

Just copy-pasting a conversation from #bzr, for the record.

<nekohayo> those progressbars are weird. They remove themselves dozens of times per second! Don't quite know what to do with that
<jelmer> I've been thinking about making it possible to set a "progress bar widget", so windows can tell the progress bar to appear in a specific place before they start doing something (like viz analysing history)

<nekohayo> a big question I'd like to ask: wouldn't it be simpler to just have *one* master progressbar?
<jelmer> There is a top-level progressbar, so you could choose to ignore all sub-progress bars

<nekohayo> hrmm. Do you have a branch of that or something? a bit beyond my coding skillset i think, but if you want a UI reviewer I'd be glad to comment, etc

<jelmer> No, not yet. The progress bars need a lot of work, not just the way they look but also the way they're handled inside of bzr-gtk/olive. Comments the UI are more than welcome on the mailing list or the bug tracker. Ideally, they'll be integrated in the various windows and no longer be standalone windows. They really need a lot of refactoring first before we can look at the specific ui

<nekohayo> actually, I think the best way would be having an "info pane" like gedit/eog's at the top below the toolbar; http://blogs.gnome.org/lucasr/files/2007/02/eog-error.png
<jelmer> bzr-gtk is not just olive, the various dialogs can appear without olive as well
<nekohayo> but then how would you integrate them into the various windows?
<jelmer> integrate them into the various windows themselve rather than in some top-level window or did I misunderstand you earlier?
<nekohayo> well isn't olive just one top level window?
<jelmer> some of the windows that can appear with olive as top level window can also appear standalone

<jelmer> the problem is, the master progress bar isn't always linear
<lifeless> we can't do linear; we can do linear for some parts of the operation
<jelmer> so you may want to see the subprogressbar in some cases

<jelmer> I think this would be an interesting thing to bring up on the list

[Daniel Schierbeck (dasch)]

This is an area that needs much work, indeed.

I think a general cleanup and refactoring of the entire project should precede any significant work, though -- the code duplication alone makes it hard to do much without breaking even more.

[Jeff Fortin Tam (kiddo)]

Has this issue, or those on which it depends, moved forward a bit? This piece of UI (progress display) is making the whole thing look a bit unpolished; so much that it affects perceptions of robustness. I personally use the command line for bazaar now since olive gives me the "impression" that it is not handling operations well, it is kind of a scary feeling.

[Javier Derderyan (javierder)]

I've implemented (based on GtkUIFactory from bzr-gtk) a very experimental version of GtkProgressBarStack with a single progress bar that contains all the nested ones.
Also, since I'm working on bzr-gedit (plugin that integrates bzr into gedit) i managed to put the progressbar inside some dialogs.
The code sits right now here: https://code.launchpad.net/~javierder/bzr-gedit/main
The window where it shows better is in "branch from".

I would like to implement something like this to bzr-gtk.

[Jasper Groenewegen (colbrac)]

Jelmer, is the current implementation of the Progressbars sufficient to close this one as being committed?

[Jelmer Vernooij (jelmer)]

HI Jasper,

I think there's a couple of places where we still show progress windows rather than progress bars.