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 599617 - a modern tooltip look
a modern tooltip look
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
3.2.x
Other All
: Normal normal
: 3.4
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 643862
 
 
Reported: 2009-10-26 03:36 UTC by Matthias Clasen
Modified: 2011-10-19 19:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
the patch (10.88 KB, patch)
2009-10-26 03:36 UTC, Matthias Clasen
none Details | Review
Updated patch for GTK+ 3.0. (6.83 KB, patch)
2011-03-15 20:43 UTC, Cosimo Cecchi
needs-work Details | Review
tooltip: add support for opacity and rounded corners for tooltips (3.88 KB, patch)
2011-10-06 21:10 UTC, Cosimo Cecchi
reviewed Details | Review
tooltip: add support for opacity and rounded corners for tooltips (5.37 KB, patch)
2011-10-12 17:59 UTC, Cosimo Cecchi
committed Details | Review

Description Matthias Clasen 2009-10-26 03:36:57 UTC
Created attachment 146240 [details] [review]
the patch

In Fedora 12, we have a GTK+ patch that makes tooltips have rounded corners and
be slightly translucent. This is currently opt-in for themes, by setting a
style property.
Comment 1 Martin Sourada 2009-10-28 16:50:43 UTC
As an engine developer (I'm making the gtk-nodoka-engine), long-term I'd prefer more systematical change. I.e. let an engine handle the drawing and ask the engine for the desired tooltip shape as well (if not composited). That way we could implement it in a clean way in engines, with radius as set in engine options (as opposed to counting the radius from x/ythickness in the proposed patch) and with our custom styling (like with gradients that fit well with our themes, ...).
Comment 2 Olav Vitters 2009-10-29 07:54:03 UTC
Review of attachment 146240 [details] [review]:

::: gtk+-2.18.3/gtk/gtktooltip.c.fresh-tooltips
@@ +848,3 @@
 #ifdef DEBUG_TOOLTIP
   g_print ("event window %p (belonging to %p (%s))  (%d, %d)\n",
+	   gindow, event_widget, gtk_widget_get_name (event_widget),

Intentional?
Comment 3 Christian Dywan 2009-11-27 16:42:45 UTC
The current patch is just a hack, but I like the idea. What about adding style properties for "corner-rounding". Any plans for a proper patch?
Comment 4 Matthias Clasen 2009-11-27 19:08:27 UTC
Sure, you can call it a hack, but I'm not sure we can do much better than this. 

The window rounding has to be done at window creation time, so it can't be in the theme engine, and we really want to keep the window rounding code and the drawing code together, since they need to use the same rounding for things to work well.
Comment 5 Cody Russell 2009-11-27 23:33:25 UTC
If I'm able to get c-s-d into 2.20, that will likely include RGBA default windows and might help out here.
Comment 6 Cody Russell 2009-11-27 23:40:27 UTC
Disregard that, I was misunderstanding something. :)
Comment 7 Benjamin Berg 2010-02-25 14:55:34 UTC
One could just add the RGBA colormap if available for tooltips by default (there is also the bug to do this for menus).
Theme engines can easily check if a composition manager is available and switch to drawing nice and rounded corners. Shaping the GdkWindow from the theme engine is also possible (with the disadvantage that one cannot redraw when the theme changes).
Comment 8 Cosimo Cecchi 2011-03-15 20:43:35 UTC
Created attachment 183467 [details] [review]
Updated patch for GTK+ 3.0.

tooltip: add a modern tooltip look

This adds a tooltips-use-rgba style property to GtkWidget, which in turn
enables rounded corners and transparent tooltips.
Comment 9 Matthias Clasen 2011-03-18 04:33:28 UTC
I think this patch misses something. 

We don't actually want to set a shape if we are composited, to avoid aliased edges. Instead, we want to just make the corners fully transparent, and have a nice, antialiased shape.
Comment 10 Cosimo Cecchi 2011-10-06 21:10:30 UTC
Created attachment 198475 [details] [review]
tooltip: add support for opacity and rounded corners for tooltips

Rounded corners now will always work, using XShape in case we're not
running a composite manager.
Also, setting an RGBA visual (if available) on the tooltip toplevel
enables them to be transparent if the theme specifies so.
Comment 11 Cosimo Cecchi 2011-10-06 21:13:34 UTC
Another approach: no additional style property, and try to always "do the right thing", i.e.:

- if we're composited, the RGBA visual will be set on the window, allowing the theme to set a transparent background color
- if we're composited, clear the toplevel background to 100% transparent, and then draw frame/background
- if we're not composited, fallback to XShape, so using border-radius works both in normal and fallback modes
Comment 12 Cosimo Cecchi 2011-10-06 21:15:33 UTC
I'm using this CSS snippet in Adwaita to test the patch.

.tooltip {
    padding: 4 4;
    border-style: none;
    border-radius: 5;

    background-color: alpha(#212526, 0.90);
    color: #ffffff;

    text-shadow: 1 1 #000000;
}
Comment 13 Matthias Clasen 2011-10-12 15:33:17 UTC
Review of attachment 198475 [details] [review]:

::: gtk/gtktooltip.c
@@ +609,3 @@
+
+  cr = cairo_create (surface);
+  paint_background_and_frame (tooltip, cr);

Thats a clever trick indeed.

@@ +635,3 @@
+    {
+      /* fallback to XShape for non-composited clients */
+      update_shape (tooltip);

If you only set the shape in paint(), I expect that you'll get an ugly corner flash when the window is first mapped ? Have you tried the uncomposited code path ?
Comment 14 Cosimo Cecchi 2011-10-12 15:38:26 UTC
(In reply to comment #13)

> If you only set the shape in paint(), I expect that you'll get an ugly corner
> flash when the window is first mapped ? Have you tried the uncomposited code
> path ?

Yeah, I tried the patch in fallback mode and didn't see any ill effects. I guess adding a shape update in realize() won't harm anyway though.
Comment 15 Matthias Clasen 2011-10-12 15:41:07 UTC
(In reply to comment #14)
> (In reply to comment #13)
> 
> > If you only set the shape in paint(), I expect that you'll get an ugly corner
> > flash when the window is first mapped ? Have you tried the uncomposited code
> > path ?
> 
> Yeah, I tried the patch in fallback mode and didn't see any ill effects. I
> guess adding a shape update in realize() won't harm anyway though.

Yeah, should do that
Comment 16 Cosimo Cecchi 2011-10-12 17:59:01 UTC
Created attachment 198869 [details] [review]
tooltip: add support for opacity and rounded corners for tooltips

Updated to set the shape at realize; also, connect to the composited-changed signal to dynamically switch between the two modes in case a compositor appears later.
Comment 17 Matthias Clasen 2011-10-18 17:06:43 UTC
Review of attachment 198869 [details] [review]:

Looks good to me. I guess you've tested composited <> noncomposited changes ?
Comment 18 Matthias Clasen 2011-10-18 17:06:47 UTC
Review of attachment 198869 [details] [review]:

Looks good to me. I guess you've tested composited <> noncomposited changes ?
Comment 19 Cosimo Cecchi 2011-10-19 19:22:46 UTC
Attachment 198869 [details] pushed as febc298 - tooltip: add support for opacity and rounded corners for tooltips

Yes, it seems to work fine. I pushed this to master now, thanks for the review.