At 1252397880 time_t, Uli Schlachter wrote: > But: > The wibox code updates wiboxes via XCopyRect() (I forgot the xcb name of that > and atm I'm too lazy to look it up). This would overdraw the child window > AFAIK > which is a bad thing. I'm not sure this is correct, jd do you know more?
No, we won't draw over it since we just copy a pixmap in a the wibox window, and then the client window is placed on top of the wibox. :) > But this wibox would again need a lot of special case code. The lua code would > need a way to reserve a [X] pixel large area between parent wibox window and > the real client and then it needs something to put widgets there. Wiboxes > with a > hole in their center sound complicated. :( Clearly. :( > > Plan A: client widget > > Thinking about this, we could need something like this: > > capi.client.new(wibox, client) > > This should somehow associate the wibox with the client or create a new client > which refers to that wibox or something like this. (Call manage hook etc?) > > This "wibox client" can then be managed normally by the existing code, but > requests for properties like c.class on that "wibox client" would be forwarded > to the real client. Only things like c.hide and c:geometry() would really > affect > the wibox. So that's basically plan B, everyone has a wibox and it's a proxy to the client. -- Julien Danjou // ᐰ <[email protected]> http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Life is life. Lalalalala.
signature.asc
Description: Digital signature
