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

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.


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


 * We can reimplement GtkTooltips using GtkTooltipsGroup and

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:


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

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]