GNOME Bugzilla – Bug 127726
gtk_toolbar_insert() doesn't allow tooltip to be set.
Last modified: 2011-02-04 16:12:26 UTC
gtk_toolbar_insert() doesn't have a tooltip parameter. There is gtk_toolitem_set_tooltip() but that needs a GtkTooltips instance, but that would need to be the same GtkTooltips instance used by the Toolbar, but that can not be accessed. In theory, you could use an additional GtkTooltips instance, but then things like gtk_toolbar_set_tooltips(gboolean) would not actually enable/disable them.
Just adding a "const char *tooltip" parameter to gtk_toolbar_insert() doesn't solve the problem of changing the tooltip of an existing GtkToolItem. I guess the < 2.4 way to change the tooltip of a tool item was to access the toolbar->tooltips object directly; that is also the way GtkAction does it currently. I can see these two possibilities: (a) Add a new gtk_toolbar_get_tooltips_object(). Applications would be expected to call this function and pass the resulting GtkToolTips object to gtk_tool_item_set_tooltip(). (b) Change gtk_tool_item_set_tooltip() to be a regular string (child?) property, documented to mean: "This string will be the tooltip when the item is inserted into a toolbar with tooltips enabled". (a) is the simplest and least intrusive solution, but (b) has the advantage that new 2.4 API will not further propagate the use of the GtkToolTips class that bug 50619 is likely to deprecate in the future. However (b) doesn't allow a "private tooltip" to be set for tool items. (Would anyone miss that feature?)
I don't think a) is too bad. When the time comes, we can deprecate the gtk_toolbar_get_tooltips_object() at the same time as gtk_toolitem_set_tooltip().
private tooltips are entirely uninteresting, in my opinion.
I am making the toolbar->tooltips object public. The property solution is a complicated as there has to be a way to override the tooltip setting (for example if the tooltip needs to be set on several child widgets with windows). On the other hand, I don't like adding an accessor for a soon-to-be-deprecated feature if I can avoid it. Since C++ can just access the field, I am marking as FIXED, but feel free to reopen if there is a scenario where it is absolutely necessary that there is an accessor. Sat Jan 17 12:37:46 2004 Soeren Sandmann <sandmann@daimi.au.dk> * gtk/gtktoolbar.c (gtk_toolbar_finalize): Don't leak the overflow menu. * gtk/gtktoolbar.h (struct _GtkToolbar): Make some fields public. [#127726]
Why did you mark the other things as public as well? For instance, there are accessor functions for the style already.
Those are fields that I'd say reasonable code could depend on (as opposed to say "style_set_connection"), and therefore could not suddenly start containing something else. Since it isn't possible to mark fields as "previously public, but now use of them is deprecated", they'll just have to be public.