On Mon, 14 Sep 2009 15:48:19 +0200 (CEST) Julien Danjou <jul...@danjou.info> wrote: > There's 2 options: > 1. add .layout as you say. > 2. Let Lua handle that. > The layout function is just a function we call to rearrange > wibox/widgets on certain events. Like we do with client-layout. So > this can probably be done totally in Lua-land. If it's not, go back to > option 1.
2. - that would need the .widgets table where you would set the layout, which you (jd) want to remove. IMHO, you should have this information anyway, either only as an array in C that would list all child widgets belonging to the parent widget, and probably also as a read-only table in LUA. You need this in the layout function and maybe for other things too. The child list would be maintained by setting the .parent to the child. As it should be read only (or should it?) in lua, you'd need to go the 1. way anyway :) I think it would be good to have the layouts written in C, although it may be a bit harder to write them, but it will be faster, and there is no other reason to have them in lua? (except someone would wanna write his own, but it should not be needed :) Also, note that since you remove the nested tables in .widgets, you'll need to nest widgets to create complex layouts, eg. a window with a titlebar: window = wibox{ parent = screen[1].root, layout = topdown } titlebar = wibox{ parent = window, layout = leftright } icon = wibox{ parent = titlebar } title = wibox{ parent = titlebar } ... c = client{ parent = window } Here, the titlebar widget is just a container for the pieces... I guess its ok. (btw, .layout on widgets without children should be ignored, thats ok too I think) Lastly, if clients and widgets have common properties "inherited" from "windows", how will these properties be handled on, for example, the icon widget in the example above, ie. in a widget inside a widget? Seems like a bit of an inconsistency here (maybe top-level widgets should be differentiated after all... we could call them... a wibox, maybe? :D). Oh, and regarding screen[N] objects versus "fake" root windows to handle Xinerama, it all boils down to handling the offsetting ourselves or let reparenting do it, right? I'd say for better backwards compatibility screen[N] would be better, but for consistency with .parent being a window to which something is reparented, the "fake" (but I don't see it as fake, really) objects would be better. Also, jd, which one would be better to handle screen configuration changes more gracefully than restart() as someone just asked in the ML? (probably both the same, hehe) Anyway, I love the idea! I'm looking forward to it :) btw, I've been messing with the layouts that Gregor sent, now I'm not sure I should go on, as it seems it will be replaced soon now, and the basic layouts are working anyway.. I really need to go to sleep, hope I'm making some sense and its gonna be useful to somebody :) Cheers! lukash -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.