Hi, As you may be aware or not, the current titlebar code is the piece of code I hate the most in awesome code. I hate it so much than I regret I've added it.
In order that everybody can participates in this flamewar, let's recap
what the code the implementation looks like as of today:
+--------+ +-------+
| client | .titlebar -------> | wibox | .widgets
+--------+ +-------+ |
|
v
{ widget1, widget2, ... }
This design a lot of problem:
* It exports totally the titlebar handling to Lua, but cannot export its
position.
Meaning all positioning is down in C;
* Unable to really implement shading in a clean way:
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2456800
* Create sub-class of wibox, AKA "titlebar", which have to be handled
differently in various codepath;
* Complexify a lot the client geometry handling. See all the
titlebar_update_geometry() and stuff called everywhere;
* Generally, second class citizen.
So, I'm requesting/proposing a plan for 3.5 to get rid of the current
code.
Basically, I plan to totally remove the old code if nothing come good
until 3.5-rc1 is ready.
Now, my plans. I'll expose them so everyone can think, propose, comment
or implement them.
I've got 2 idea in mind. The basics behind is the same used in all
window managers, aka reparenting the client window with another
window/frame.
Plan A: client widget
---------------------
The idea of this implementation is to have a "widget" that would draw a
client. We already have a thing that looks like that: systray!
Except that this time you'll have a widget that "draws" (move at its
place) the client, so the client is inside the wibox.
Implementation:
Each client has a widget_t * pointing to NULL or the wibox it is
attached to. Each client-widget has a client_t * pointing to NULL or
the wibox it is attached to. A client cannot be attached to more than
one widget_t * and a widget_t * cannot have more than one client.
Problems:
Well, nothing disallow in awesome to have a widget on 3 wibox_t. In
that case, that's not possible, so we need to block that. It's the
same case with systray, but I'm not even sure systray uniqness is
correctly handled.
Resizing a client would resize the whole wibox? or not? don't know,
but that complicates the thing a little.
Plan B: everyone has a titlebar
-------------------------------
The idea of this implementation is that all client_t have a wibox_t
attached to them.
Don't misread.
Currently, the titlebar is attached this way:
+----------+
| titlebar |
+----------+
| |
| client |
| |
+----------+
With a X hiearchy being:
root window -> titlebar
`--> client
This Plan B is to have
+----------+
| titlebar |
|+--------+|
|| client ||
|| ||
+-+-------++
With a X hierarchy being:
root window -> titlebar -> client
Implementation:
So basically, the wibox-titlebar has a geometry identical to the client,
so you can't notice there's one frame-wibox-titlebar behind it. If you
want to draw things around, we have to find a way (did not think about
that yet) to add space around between the client and the frame.
Problems:
Well, again, moving the client should move the wibox-titlebar-frame.
Maybe moving the wibox would be forbidden, as detaching/attaching it
to a client (anyway all client would have always one wibox).
Plan C
------
Do nothing. Haha. I'd vote for that. :]
Cheers,
--
Julien Danjou
// ᐰ <[email protected]> http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// My root password is
signature.asc
Description: Digital signature
