titlebar tooltips cover buttons in maximized windows when placed on the top right

[ff2000]

Output of awesome --version:

awesome v4.2 (Human after all)
• Compiled against Lua 5.3.3 (running with Lua 5.3)
• D-Bus support: ✔
• execinfo support: ✔
• xcb-randr version: 1.5
• LGI version: 0.9.0

How to reproduce the issue:

• add buttons for titlebars on the top right
• maximize a window
• hover one button (e.g. close)
• (try to) click it

Actual result:

tooltip comes up rather quickly and places itself over the button. This is quite sure due to the tooltip getting placed above and right of the cursor, but as there isn't enough space it gets moved down/left until it is fully visible.
That tooltip will eat the click leaving the user (me) quite irritated. Two clicks are needed to close the window.

Expected result:

Let me trigger the action with just one click!

Solution could be to either (1) change the way the tooltip is positioned in such constrained cases (e.g. swap top/bottom and left/right) or (2) just to pass the click through the tooltip to the underlying widget. I would prefer (1): It can be irritating if the button gets covered, even when it's a describing tooltip.

[psychon]

@Elv13 Ideas? Since tooltips delegate placement to awful.placement (By default it seems to call awful.placement.left and then awful.placement.no_offscreen), I am not quite sure what to do here.

[Elv13]

Maybe we could use the input_passthrough?

[psychon]

I agree with @ff2000 here that his (1) seems better than (2), so I'd prefer better placement, but I guess we can also do both.

[Elv13]

The next_to placement is the closest to something designed for this purpose (it's for sub-menus). However (I think) it isn't smart enough to distinguish between the titlebar and it's client. So it makes things worst and send the tooltip below the client or some other of such absurdities. The bug would be making sure to properly detect the titlebar geometry. The problem with fixing it that way would be making #650 harder to implement properly. Another half unsexy solutions would be to use a custom placement function. The problem with that would be that it would add client specific code to the tooltip modules (given next_to is perfectly adapted for wibars and wiboxes, but not titlebars).

[psychon]

Can we make next_to work for widgets? mouse::enter gets information about the widget's placement as its second argument. From that we can work out the widget's geometry in screen coordinates (well, an over-approximation of that if the widget is rotated by non-multiples of 90°, but whatever). If something like this gets passed to next_to...?

Let v be the argument to mouse::enter. The widget's geometry relative to the drawable should be in v.x, v.y, v.width, and v.height. The drawable's geometry is available as v.drawable:geometry(). The rest is two simple additions. ;-)

Edit: Actually, the argument to mouse::enter is the entry for the widget in the result of wibox.drawable:find_widgets, so this is a little more generic than just mouse::* signals.

Edit: awful.placement.next_to already defaults to using capi.mouse.current_widget_geometry which is implemented by get_current_wibox and `:find_widgets?! I kind of doubt that this code works since the widget positions here are relative to the drawable's top-left corner and not in screen coordinates.

Edit: Okay, that code does work thanks to $MAGIC done later...

[Perlovka]

I've fixed this in the following way:

awful/titlebar.lua

function titlebar.widget.button(c, name, selector, action)   
    local ret = imagebox()                                   

    if titlebar.enable_tooltip then
        ret._private.tooltip = atooltip({ objects = {ret}, delay_show = 1 })
        ret._private.tooltip:set_text(name)
+        ret._private.tooltip:set_mode('outside')
    end

[ff2000]

@Perlovka somehow I missed your reply.
And thank you, that seems to work fine here.
Could this be merged?

[psychon]

@Elv13 What do you think about "outside" mode for tooltips on titlebars?