GType gtk_progress_bar_get_type (void) G_GNUC_CONST;
GtkWidget* gtk_progress_bar_new (void);
-/*
- * GtkProgress/GtkProgressBar had serious problems in GTK 1.2.
- *
- * - Only 3 or 4 functions are really needed for 95% of progress
- * interfaces; GtkProgress[Bar] had about 25 functions, and
- * didn't even include these 3 or 4.
- * - In activity mode, the API involves setting the adjustment
- * to any random value, just to have the side effect of
- * calling the progress bar update function - the adjustment
- * is totally ignored in activity mode
- * - You set the activity step as a pixel value, which means to
- * set the activity step you basically need to connect to
- * size_allocate
- * - There are ctree_set_expander_style()-functions, to randomly
- * change look-and-feel for no good reason
- * - The split between GtkProgress and GtkProgressBar makes no sense
- * to me whatsoever.
- *
- * This was a big wart on GTK and made people waste lots of time,
- * both learning and using the interface.
- *
- * So, I have added what I feel is the correct API, and marked all the
- * rest deprecated. However, the changes are 100% backward-compatible and
- * should break no existing code.
- *
- * The following 9 functions are the new programming interface.
- */
void gtk_progress_bar_pulse (GtkProgressBar *pbar);
void gtk_progress_bar_set_text (GtkProgressBar *pbar,
const gchar *text);
* outside the widget. If returning %TRUE, widgets normally
* call gtk_widget_grab_focus() to place the focus accordingly;
* if returning %FALSE, they don't modify the current focus location.
- *
- * This function replaces gtk_container_focus() from GTK+ 1.2.
- * It was necessary to check that the child was visible, sensitive,
- * and focusable before calling gtk_container_focus().
- * gtk_widget_child_focus() returns %FALSE if the widget is not
- * currently in a focusable state, so there's no need for those checks.
- *
+ *
* Return value: %TRUE if focus ended up inside @widget
**/
gboolean