After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 319608 - Enhance the GtkProgressBar widget
Enhance the GtkProgressBar widget
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
unspecified
Other All
: Normal enhancement
: Medium feature
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2005-10-24 14:11 UTC by Luca Ferretti
Modified: 2013-02-14 10:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Quick and simple "mode" property (5.27 KB, patch)
2008-06-17 17:41 UTC, Christian Dywan
none Details | Review

Description Luca Ferretti 2005-10-24 14:11:40 UTC
This is a feature request about new modes for GtkProgressBar widget. Maybe a new
widget.

 - Introduction

A graphical toolkit needs a widget to show the percentage of "something". But
"something" could be:
  a. the amount of ink in printer
  b. the used/free space in HD
  c. the number of files yet copied/moved
  d. the number of emails yet sent/received

As you can see, a and b are used to show a "static" information (the level or
the amount of something), c and d instead a "dynamic" info (the status of
operations). So, following Apple HIG[1], let's call them "Level indicators" and
"Progress indicators".

 - Level Indicators

Currently this kind of widget is not really available in GTK+. Of course
developers can use the GtkProgressBar widget, but there are some limitations.
Apple HIG suggests 3 types of level indicators: capacity, rating, relevancy.

The capacity type is the more interesting. As you can figure, it's used "to
provide information about the level or amount of something that has well defined
minimum and maximum values". Examples: level of storage space, battery charge...

Apple capacity indicator has 2 styles: continuous and discrete. See Apple HIG
page for screenshots.

One feature not available is Apple capacity indicator is "color tweaking". The
apple widget is green when the value is in standard range, yellow when in
warning and red when in critical. This is a scheme well behaving for storage
space and battery charge. But, using a capacity indicator to show the levels of
ink tanks in your printer, could be interesting use for each indicator the color
of the tank. The indicator could blink when the ink level is critical.

Rating and relevance indicators in Apple HIG are not so interesting, at least to
be implemented directly in GTK+. An example of rating indicator is in Rhythmbox.

Summarizing, a GtkLevelBar should:

  * provide a 'continuous' and 'discrete' appearance (GNOME HIG should specify
when use them)
  * provide major/minor ticks outside the widget (maybe useful only in
continuous mode)
  * provide a way to visually show warning and critical level
  * have the ability to be used as cell rendered

As additional feature, it could be interesting let developers to create "skins".
For example Rhythmbox developers could use GtkLevelBar and GtkLevelCellRenderer
to show song rating in main UI and in song properties dialog, setting max_value
to 5, min_value to 0, warning_value to none, mode to discrete and writing code
to draw each segment as a star. Another skin could be used to create a "mini
mode"; there are at least 3 applets in gnome-panel that could need a
mini-GtkLevel widget: the CPU frequency scale, the battery level monitor and
netstatus. So the widget is a standard and tested GTK+ widget (ATK!!) and only
the drawing code (maybe using Cairo) is customized by applications.


 - Progress Indicators

Why split progress and level? Well, 'cause progress indicators should be
ANIMATED widgets. Adding an animation to GtkProgress, we will help users to see
immediately that something is happening. Something like this [2] designed by
jimmac and implemented as hack in Clearlooks theme.

The progress animation can help to distinguish a GtkLevel* widget from a
GtkProgress* widget.

There are two kind of progress (as per Apple HIG): determinate and indeterminate.

Determinate is, for example, the progress of a copy/move action. The application
knows how many files is transferring and can show the current status and/or the
needed time to complete.

Indeterminate is, for example, the query to a DHPC server. The duration of the
process can't be determinated or extimated.

Note that a indeterminate progress bar can switch do a determinate one: just
take a look to the Send/Receive Email dialog in Evolution. The same progress bar
is used first to show that Evolution is querying the server for new messages
(indeterminate process, depends on network congestion), then to show the status
of message download (determinate process, at least can says "x of y downloaded").

The widget currently implemented in GTK+ provides the activity mode (just like
the K.I.T.T. SuperCar :-): this could be used in indeterminate progress.
Comment 1 Luca Ferretti 2005-10-24 14:13:22 UTC
Forgot to mention: this could be stuff for ProjectRidley
Comment 2 Matthias Clasen 2005-10-25 18:21:41 UTC
Potentially interesting ideas. If you are interested in seeing this in GTK+
anytime soon, I propose to start with prototyping these ideas, ideally in 
an appication which has an actual need for this kind of ui.
Comment 3 Luca Ferretti 2007-07-07 12:01:28 UTC
Additional note: with the emerging of sematic/searchable desktop, metadata, and other related stuff, the rating "skin" suggested before could become a widely adopted widget (file manager[1], music/photo manager, search tool...).

In fact, File.Rank is one of generic metadata proposed by fd.o Shared Metadata Spec[2]: it's "editable file rank for grading favourites. Value should be in the range 1..10"

So the widget hierarchy could be something like:

   ...
   +----GtkWidget
         +----GtkIndicator
               +----GtkIndicatorLevel
               +----GtkIndicatorProgress
               +----GtkIndicatorRating

and 

   ...
   +----GObject
         +----GtkCellRenderer
               +----GtkCellRendererIndicatorLevel
               +----GtkCellRendererIndicatorProgress
               +----GtkCellRendererIndicatorRating

Note that *Rating isn't only used to get/show a value, like *Level and *Progress do, but also to set it (Rhythmbox has this kind of widget and cell renderer).

[1] http://media.ereslibre.es/2007/07/klistviewsortbyrating.png
[2] http://freedesktop.org/wiki/Specifications/shared-filemetadata-spec
Comment 5 Thomas Perl 2008-05-25 08:54:59 UTC
I'd also like to see these additional widgets, so I don't have to mis-use a progressbar for some indicator (as there are gtk themes that animate the progress bar, which looks stupid for static indicators).
Comment 6 Christian Dywan 2008-06-08 13:44:54 UTC
Do we actually need many different widgets for this? Can we not instead add a property to GtkProgressBar, for example 'mode' or 'behaviour' and just let the theme (engine) style it differently.

I'm not sure about the 'skin' functionality but I think that can just as well be added to GtkProgressBar since it would be useful for any kind of indicator as mentioned here, as far as I understand the intention.
Comment 7 Christian Dywan 2008-06-17 17:41:43 UTC
Created attachment 112924 [details] [review]
Quick and simple "mode" property

I just made a patch that adds a "mode" property. This could be used by themes to easily determine what the purpose or role of the bar is. I tend to think that would improve the situation a lot already without added complexity, for example the animation of bars some engines do, as mentioned by the previous comment.
Comment 8 Thomas Perl 2013-02-14 10:29:56 UTC
mclasen: This was closed as RESOLVED FIXED without any comment, but I initially wasn't able to see any changes in Gtk+3 that address the issues mentioned in this bug. I'm looking at:

http://developer.gnome.org/gtk3/3.7/GtkProgressBar.html
http://git.gnome.org/browse/gtk+/log/

Looking at the docs it seems like GtkLevelBar is the widget to use for these cases, it might have been helpful to point this out, so I'm adding it here as a comment in case anyone else stumbles over this bug in the future:

http://developer.gnome.org/gtk3/3.7/GtkLevelBar.html