2 thinks I would like in awesome related to this. - empty clientwidget : this will allow to create tag with a fixed layout, and could allow to focus empty tag on another screen. (handling two screen without mouse is not trivial atm and require tweak and tricks here and there) - real tab: with the current version of awesome it's impossible to make tab work properly. I know it's not the philosophy of awesome to use tab, but as a framework window manager I think it make sens. In fact I will really like to mix both fixed layout+tab and current awesome windows handling.
For the empty clientwidget think, the proposition A seems better. For tab I can think of plural solution. One can be to allow sublayout, using a suit.max layout in a frame would just create tabs. Another could be a clientwidget that can handle between 0 and more clients. In both case the proposition A seems better for tabs too. On Mon, Sep 7, 2009 at 3:31 PM, Julien Danjou<[email protected]> wrote: > 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 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAkqlC0UACgkQpGK1HsL㎳Ÿ䉶㤈㴥Ὴ붴良 > FvkAoI0gZSDNBlYww400OmSFv6Ly84NE > =PtlN > -----END PGP SIGNATURE----- > > -- To unsubscribe, send mail to [email protected].
