[sugar] How to get pygtk to give you a GtkToolTips from a Toolbar to pass to ToolItem's set_tooltip?

Don Hopkins dhopkins
Tue May 22 17:21:06 EDT 2007


I looked at how gtkaction.c was doing it, and tried to do the same thing 
in Python, which turned out to be impossible because the tooltips object 
of the toolbar was not exposed in pygtk.

I presume the tooltips object I'm supposed to pass to set_tooltip is the 
tooltips of the toolbar that contains the toolitem, so I don't think 
creating my own one would work (especially since there is no way to set 
the toolbar's tooltips to the one I created, let alone get the toolbar's 
tooltips).

I wonder why the toolitems need to be given a tooltips object in their 
set_tooltip method in the first place, since their parent is the very 
toolbar I'm getting the tooltips from, so they should be able to get the 
same object by getting their parent's public tooltips member, instead of 
requiring the programmer to always pass it in.
Better yet, why can't there be one global tooltips object (or one per 
screen or toplevel window), instead of each toolbar having its own 
tooltips?

I am glad the tooltip api is being rewritten, since it could be simpler 
and more flexible.
I hope it will support a callback signal to dynamically compute the 
tooltip at the time the user points at the item.

Any idea how long until the tooltip rewrite lands, and how long until 
that version of gtk is incorporated into the Sugar build tree?
In the mean time, should I submit a patch to pygtk, or give up the idea 
of using gtk's tooltips from Python for now?

More tooltip questions:

Do gtk tooltips support Pango markup rendering?
Is there an api for popping up and hiding tooltips under program control 
from Python? (So I can pop them up when the user presses a game 
controller button, and keep them up for a while).
Does Sugar have its own tooltips implemented in Python that I should use 
instead of gtk?

My thoughts on gtk's Action and UIManager classes:

I've tried to use gtk's Action and UIManager classes, but they are too 
brittle and hard-coded to do what I need.
It hits the wall when you want to put a widget that's not a button or a 
menu into a toolbar, like a page number input field or page count label, 
or any custom control.
You should be able to use the keyboard or game controller to navigate to 
non-sensitive (disabled) items, and see a tooltip describing what the 
item is, why it's disabled, and what to do to enable it.
Disabling a control should not kick the focus out of that control and 
into the next control, because that violates the principle of least 
astonishment, and makes type-ahead dangerous and unreliable.
Unfortunately gtk does not support showing tooltips on disabled items, 
and does not support keyboard navigation to disabled items, and does not 
support showing tooltips in response to keyboard navigation.
I tried using gtk Actions and UIManager to implement that stuff, but it 
turned out to be hard coded to do exactly what it currently does and 
nothing more, with no way to extend the xml user interface definition 
format, or add new widgets or types of interfaces, without defining a 
bunch of extra intermediate Action classes, one for each custom widget.
The only way to get the UIManager to make a custom widget in a toolbar, 
is to make your own custom Action class just for that widget.
And if you're using your own custom Actions to implement your own custom 
Widgets, you can't use the actiongroup.add_actions utilities (so I wrote 
my own equivalents in Python).
You can't just make one general purpose parameterized Action class that 
can create many types of different widgets according to how it's 
configured, because it's a *class variable* in the action class 
(accessed via action.set_tool_item_type, etc) that determines what 
widgets are created by the action, and it's not up to the individual 
Action instance.

After reading over the source code and giving them a try, I've decided 
not to use gtk's Action/UIManager classes, and I'm writing my own stuff 
on top of Toolbar and ToolItem and its subclasses in Python.

More questions about icons:

I was able to get my own custom icons to display in toolbuttons when I 
was using Actions and UIManager, by making my own gtk.IconFactory, 
making a bunch of IconSets, adding them to the IconFactory, calling 
add_default() on the IconFactory to put them into the icon search path, 
and then making Actions and calling action.set_property('icon-name', 
'read-rotate-right') referring to the names of the icons I put into the 
factory.
(Is it possible to define your own IconFactory subclass that implements 
lazy loading on demand from your application's icon directory, instead 
of scanning the directory and loading all the icons in advance? The only 
examples I could find force-feed the iconfactory with all known icons 
while the application is starting up, with is less than optimal.)
But when I created my own toolbuttons and called set_icon_name with the 
same name I was assigning to the Action, I got the undefined red X icon 
instead of my own icon.
Is there something special about the way Actions are setting the icons 
of ToolButtons? Some other work they're doing to enable looking up icons 
in the default factories?
I read over the code and can't figure out what I'm doing differently. So 
I ended up making my own Icon widget for each toolbutton, showing it, 
and calling toolbutton.set_icon_widget, manually.

    -Don


Marco Pesenti Gritti wrote:
> Don Hopkins wrote:
>> I'm trying to set the tooltip of a tool item, which I though would be 
>> easy, but the ToolItem.set_tooltip takes a first parameter that's a 
>> mysterious GtkTooltips object.
>> But I can't figure out how to get a reference to the required 
>> ToolTips object to pass as a first argument to a ToolItem's 
>> set_tooltip(tooltips, tool_tip_string) ...
>> The obvious looking method GtkToolbar.get_tooltips() actually returns 
>> a boolean that tells if the toolbar is using tooltips, but does not 
>> return the toolbar's "GtkTooltips *tooltips" member, which is 
>> declared public but apparently not exposed as a property to Python.
>>   
>
> I don't quite remember how the tooltips API works but... doesn't just 
> creating an instance of gtk.Tooltips() work?
>
> The tooltips API is being rewritten on gtk trunk btw.
>
> Marco




More information about the Sugar-devel mailing list