Created attachment 18177 [details]
header file for gtkcellrendererprogressbar widget.

Created attachment 18178 [details]
source code for proposed new widget gtkcellrendererprogressbar.

Created attachment 18187 [details] [review]
Patch for gtkcellrendererprogressbar.h

Created attachment 18188 [details] [review]
Patch for gtkcellrendererprogressbar.c

The two patches fix a few bugs.

1. The call to gdk_draw_drawable ignored the parameter expose_area and
instead redrew the progressbar completely rather than just the section
that needs the update. 

2. The call to gtk_widget_map() was not needed and caused superfluous
bars to appear in unexpected places.

3. gtk_widget_size_allocate() is now only called when the size
changes.  This should be quicker and fix a bug where if the same
GtkProgressBar is associated with two different
GtkCellRendererProgressBar cells when one is rendered,
gtk_widget_size_allocate is called which causes the other cell to get
rendered, this then calls gtk_widget_size_allocate and the two cells
continue to provoke the other to get redrawn.  Nasty loop and CPU hog.

4. Finally added the function,
gtk_cell_renderer_progress_bar_update_tree_view(GtkTreeView *).

This function invalidates the entire surface area of a GtkTreeView
widget causing the progress bars and everything else to be redrawn. 
This should be called after any functions which change the way that
the progressbars would be displayed such as
gtk_progress_bar_set_fraction().

It should be noted that I do not like this and if anyone has an idea
on how to tie changing the value of the progress bar to a region being
redrawn, please let me know.

Thanks,
Russ

Hi Russell,

I'm trying the code. First of all, it needs gtkintl.h, I don't know why.

Second, it requires a GtkProgressBar. If you look at
gtkcellrenderertoggle.c you will see there is no GtkToggle property
but "active", "inconsistent", ... instead, this is, it behaves as a
widget, while your implementation needs that widget.

Someone with more experience should comment on this though.

Please, look at the cellrenderer.{h,c} file in gnome-system-monitor.
It looks like a good implementation to integrate in gtk+.

Kris had a bunch of comments on the progressbar renderer.  Can you
post them here, Kris?

Hi Manuel,

Thanks for reviewing the patches and providing some constructive
criticism.  I am sure that they are far from perfect and could use a
few more pairs of eyes on them.

I agree there is no need to include "gtkintl.h" sorry about including
that I must have copied it from gtkcellrendererpixbuf.  Speaking of
which is there a need for gtkintl.h in gtkcellrendererpixbuf?

I have looked at the cellrenderer.{h,c} included with
gnome-system-monitor and think that it has some significant
shortcomings.  It has a single property which is a (double) value. 
The progressbar is then rendered based on this value.  This means that
the application programmer cannot do the following things. (To my
knowledge???)

 - Set the text on the progress bar to an arbitrary value or disable
it at their discretion.
 - Set the GtkProgressBarOrientation.
 - Set the progress bar into "pulse" mode.

It would be possible to write an implementation which had these
features but there would then be a great deal of duplicated logic in
the rendering of the widget.  For this reason, I thought it would be
cleaner and easier to make use of the already existing GtkProgressBar
widget and let it do the rendering.

Thanks again for looking at the widget.

-Russ

First of all, I personally do not like embedding arbitrary widgets in
cell renderers. This is because certain complications will popup (like
the function gtk_cell_renderer_progress_bar_update_tree_view() which
you had to add) and because it will never work 100% right.

The progress renderer as found in gnome-system-monitor/procman comes
much closer to what I have in mind. Though I agree that it is pretty
limited.

As I will need a progress renderer like this myself at some point, I
will look into writing one. It will have more features than the one
found in gnome-system-monitor (and I prolly also want another size
requisition system), but I am not sure exactly which.

(For an actually unknown reason) I think it makes sense to exclude all
 animated progress types from the renderer, and thus basically
implement everything GtkProgressBar supports exluding the animated
options. I came to this when imagining a treeview full with discrete
pulsing progress bars, I think that will be way too busy. But I am
prolly wrong here.

I will update this bug once I have more information on the subject.
(Probably after my feature requirement investigation ;)

Note that Epiphany has a progress bar cellrenderer as well
(lib/widgets/ephy-cell-renderer-progress.[ch]).

regs,
 Chris

I integrated the Epiphany progress cell renderer.