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.
