Use full hierarchy for clients drawable

[Elv13]

Instead of hardcoding set_titlebar, I propose having a fully hierarchy for clients

Use case:

• Implement tabs in a sane way
• Making titlebars more flexible for themes
• Drop the shape_clip API, it doesn't support antialiasing or complex borders.
• Drop clients border_width, use widgets instead

Complex border examples:

• http://i.imgur.com/th92K1o.png
• https://liquidat.files.wordpress.com/2007/10/plasma.png

[Elv13]

Something like:

c:setup {
    {
        {
            awful.titlebar(c, {args}).
            c.widget,
            { --[[some bottom widget]] },
            layout = wibox.layout.align.vertical
        },
        margins = 12,
        widget = wibox.container.margins,
    },
    fg = "unicorn pink",
    widget = wibox.container.background
}

The current titlebar API could be implemented on top of that to keep the compatibility, then deprecate it for v5 (the current titlebar API is a mess)

[psychon]

@Elv13 Is this something like what you have in mind? https://gist.github.com/psychon/ed4436cd5ad36da57c6dd81c69ac8e1c

[psychon]

@Elv13 What would the awful.titlebar widget in your example actually do? It cannot modify the client's geometry (e.g. feedback loop, but also: bad idea), so it can only change the size of the titlebars. However, that in turn requires a full relayout, which means that the awful.titlebar-widget gets assigned a new size which means.... and we end up with a feedback loop again.

In a wibox, the size of the wibox is given and the code "just" has to place widgets in there.
In a client, the geometry of the client is given, but the size of the titlebars is free. My example code from my previous comment does not resize the titlebars, but assumes that their size is given so that the same thing as in the wibox case can be done.

So, any idea how the size of a titlebar is computed? And what would your awful.titlebar widget actually do (it can only resize titlebars and that doesn't fit well with the widget API).

[Elv13]

@Elv13 Is this something like what you have in mind?

With some love, it will do just fine, thanks a lot. I feel ashamed I didn't see the obvious earlier. I will work on it later. I am currently busy finishing a PR serie that stretch back to october (the improved doc)

What would the awful.titlebar widget in your example actually do?

Don't worry, I think with some work on the hierarchy handler, it can behave exactly like the titlebar currently does.

[psychon]

I feel ashamed I didn't see the obvious earlier.

I came up with this approach after our discussion yesterday. It wasn't so obvious to me either (and I needed way too long to get the "math" right for computing the positions of the individual titlebars).
It is a bit like a mathematical proof: Once the solution is known, it seems to be obvious. :-)

I understand your comment as you will handle this from here on and I should not continue working on this. Feel free to point out things that you want me to do here (so far I am still quite unsure how to get this nicely into wibox.drawable, but I am sure that it has to be in there since no one wants to duplicate all the input handling code in there...).

[Elv13]

I understand your comment as you will handle this from here on and I should not continue working on this.

If you wish to spend time on it, feel free to do so. Otherwise, yes, I will add it to my todo list.

so far I am still quite unsure how to get this nicely into wibox.drawable

I also failed to integrate the copy/paste from my dynamic awful.layout branch. The reasons are similar, but on top of that my branch has to handle fake contexts, so your code above might be easier to integrate, but overall the drawable API wasn't designed with those use case in mind.