AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity

Remove docs about 1.2 <> 2.0 differences

Browse Source 
These should not be kept in 3.0.
Noticed by Dan Winship in bug #619838.
This commit is contained in:
Matthias Clasen 2010-06-02 19:59:41 -04:00
parent ee0d695a91
commit 6a8a2f7ef3
2 changed files with 1 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
gtk/gtkprogressbar.h
View File

@ -98,33 +98,6 @@ struct _GtkProgressBarClass
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);

8
gtk/gtkwidget.c
View File

@ -7679,13 +7679,7 @@ gtk_widget_get_root_window (GtkWidget *widget)
* 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