Re: RFC: Tooltips redesign (needed e.g. for row dependent tips in treeview)

[Christof Petig <christof petig-baender de>]

Hi Owen,

closer examination (~1h) of your proposal did not make me understand 
everything. So here is my iterational step ;-) [I added my differing 
proposal at the end]

Owen Taylor schrieb:
> Here's an alternate approach I came up with talking to Jonathan (he's
> promised a more detailed writeup of GtkTreeView requirements) is a
> little more of a radical change.
>
>  * We ditch (deprecate) GtkTooltips; GtkTooltips objects are 90% just
>    annoying to create and memory manage.

I'm 100% in favor of ditching GtkTooltips in favor of a widget property.
What about tip_private? It does not show up in your proposal at all.

>  * The one case where the tooltips object isn't just annoying is
>    the sticky delay behavior where mousing between tooltips in 
>    a single group doesn't involve a full delay for it to pop up.
>    For this functionality, we add GtkTooltipsGroup, along the
>    lines of GtkSizeGroup.

Agreed.

>  * For simple cases, we add "tooltip" and "tooltip-uses-markup" 
>    properties to GtkWidget.

Agreed.

>  * We can reimplement GtkTooltips using GtkTooltipsGroup and
>    gtk_widget_set_tooltip().

Agreed. (You are talking about backwards compatibility here, right?)

>  * For custom tooltips, we introduce the GtkTooltipsWindow widget,
>    There is a singleton GtkTooltipsWindow object per toplevel,
>    which can be retrieved with:
>
>     gtk_widget_get_tooltips_window()
>
>    This both handles the display of the yellow rectangle, and the 
>    logic for showing/hiding the tooltip based on keyboard and 
>    mouse actions.

So, TooltipsWindow is manageing querying the widgets for the text and 
the display of the tooltip?

>     void gtk_tooltips_window_begin (GtkTooltipsWindow *window,
>                                     GtkTooltipsContext context,
>                                     GObject           *owner);
>     void gtk_tooltips_window_end   (GtkTooltipsWindow *window,
>                                     GtkTooltipsContext context,
>                                     GObject           *owner);

Who calls these? And what would be done inside these calls? [Emitting a 
signal?]

>     void gtk_tooltips_window_set_text (GtkTooltipsWindow  *window,
>                                        GtkTooltipsContext  context,
>                                        GObject            *owner,
>                                        const char         *text);
>     void gtk_tooltips_window_set_markup (GtkTooltipsWindow  *window,
>                                          GtkTooltipsContext  context,
>                                          GObject            *owner,
>                                          const char         *markup);

This looks like you still manage the tip storage outside of widgets. (In 
Tooltips Window). owner would always be a GtkWidget, wouldn't it?

>     void gtk_tooltips_window_set_area   (GtkTooltipsWindow  *window,
>                                          GtkTooltipsContext  context,
>                                          GdkWindow          *relative_to,
>                                          int x, int y, int width, int height);

So here you mark the active area. Managing different areas inside one 
widget is missing?

>     void gtk_tooltips_window_set_group  (GtkTooltipsWindow  *window,
>                                          GtkTooltipsContext  context,
>                                          GObject            *owner,
>                                          GtkTooltipsGroup    group);

I would code it as
void gtk_tooltips_group_add(GtkTooltipsGroup *group, GtkWidget *widget)

>  - The GtkTooltipsWindow keeps two stacks of "active objects" for
>    keyboard and mouse focus. With each object in the stack, we
>    store text/markup rectangle, and possible GtkTooltipsGroup.

Sounds like a heavyweight object. I'd like to store the information 
inside the widgets.

>  - You call  tw.begin (MOUSE) on when the mouse enters a tooltips
>    area, tw.begin (KEYBOARD) on a tooltips object getting 
>    keyboard focus and tw.end (MOUSE/KEYBOARD) on 
>    mouse leave / focus out.
>
>  - The 'GObject *owner*' arguments allow proper handling of nested
>    tooltips areas. (think a treeview with tooltips with tooltips
>    on individual rows.) It can be any GObject - the widget itself,
>    a GdkWindow, whatever.
>
> A lot of the details of the above maybe should be a little different
> than I've sketched out, but I think it is a whole lot simpler than
> any callback-based mechanism with the same set of functionality.

I originally envisioned asking the toplevel widget for the 
text/markup/widget to display when the mouse _rests_ at a certain spot 
of the window. Containers would query their children in turn. Possibly a 
container can return it's own tip when its child does not provide a tip.

So the tooltip text query signal/vfunc (I tend to use a vfunc) would 
only get called when a tip is about to be displayed.

Displaying the tooltip for the cursor focus is a different issue (mouse 
movement does not affect the display but focus changes do) because the 
actual on screen position is meaningless (that means we do not need to 
hierarchically query the widget tree for the tip to display).

So long for todays evening
  Christof

Attachment: signature.asc
Description: OpenPGP digital signature