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 127726 - gtk_toolbar_insert() doesn't allow tooltip to be set.
gtk_toolbar_insert() doesn't allow tooltip to be set.
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.3.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2003-11-23 12:28 UTC by Murray Cumming
Modified: 2011-02-04 16:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Murray Cumming 2003-11-23 12:28:04 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.
Comment 1 Soren Sandmann Pedersen 2003-11-23 13:45:11 UTC
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?)
Comment 2 Murray Cumming 2003-11-23 13:51:10 UTC
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().
Comment 3 Owen Taylor 2003-11-25 22:27:33 UTC
private tooltips are entirely uninteresting, in my opinion.
Comment 4 Soren Sandmann Pedersen 2004-01-17 11:45:15 UTC
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]
Comment 5 Murray Cumming 2004-01-29 17:49:49 UTC
Why did you mark the other things as public as well? For instance,
there are accessor functions for the style already.
Comment 6 Soren Sandmann Pedersen 2004-01-29 18:09:57 UTC
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.