Hi all, On Mon, 07 Sep 2009 17:08:31 +0200 (CEST) Julien Danjou <jul...@danjou.info> wrote: > There's probably a lead to follow in what you say about sublayouts. > Making 2 clients tabbed is just arranging them with suit.max (or > something else, why not?) were the area is not the full screen but > probably the coordinates of ones of the 2 clients.
I think the similarity of suit.max layout to how the tabs behave might be a bit misleading here...I don't see why anyone would want to use different layouts on clients embedded in a wibox and change them dynamically. Sounds too complex to be useful to me. > Another plan (let's call it Plan D) I forgot to mention is to remove > titlebar from C code and let Lua handle it with wiboxes following > clients. But that's also has drawbacks IMHO, like getting client > width/height does not count the titlebar following it. Yes, seems to me that since the titlebar wouldn't be part of the client's geometry, the titlebars would often end up offscreen or covering something they shouldn't (as it happens now sometimes too). On Mon, 07 Sep 2009 15:31:49 +0200 (CEST) Julien Danjou <jul...@danjou.info> wrote: > 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. I really like this plan :) It is by far the most flexible one, it is also described in #FS542 and Cedric mentioned it in one of his emails dealing with tabbing. It has great flexibility in that you can use it for tabbing, draw fancy stuff around your windows and whatnot (not that you would want to, but it would be possible;). Another great thing you could do with it is embedding other windows, like xclock or gkrellm in your panel, the way fvwm does it. Ok, so just to make sure we understand each other I'll use my own words to sum up my view on the idea: Make a widget that will contain the contents of a client window. Then, to make use of it, there must be an option to make wiboxes act as normal (client) windows. That way, you can make a wibox, put a client widget, a titlebar or anything else inside and move the whole thing around, etc. Obviously, this needs the layouts to be working, in this case, the client widget would have the "flex" layout, while the titlebar would have "toptobottom" (I'm not sure I completely understand the layouts as I haven't found much info about them, but I think I got the idea, hopefully :). Regarding the resizing, well the functionality is given by what you expect of it...of course you need to be able to resize the wibox :) I don't wanna go into details here cos I only have a faint idea of it now anyway, but I think it should be possible to work it out along the way so that it won't be too complicated, yet flexible :D Looking forward to comments :) I'd like to give it a go and try to implement the client widget, as it is described in #FS542 or in any way that's agreed here... Although it will be quite a challenge for me, if anyone really feels like doing it fast, go ahead :D Cheers! lukash -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
