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, ...).

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?

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?

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.

If I'm able to get c-s-d into 2.20, that will likely include RGBA default windows and might help out here.

Disregard that, I was misunderstanding something. :)

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).

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.

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.

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.

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

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;
}

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 ?

(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.

(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

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.

Review of attachment 198869 [details] [review]:

Looks good to me. I guess you've tested composited <> noncomposited changes ?

Review of attachment 198869 [details] [review]:

Looks good to me. I guess you've tested composited <> noncomposited changes ?

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.