On Thursday, November 26, 2009, Julien Danjou <jul...@danjou.info> wrote:
> At 1259273372 time_t, lukash wrote:
>> We agreed on a class inheritance system that will allow the user to
>> make his own classes inheriting from whatever he wants
>> (textbox/imagebox/graph/tag/...) with the base model being something
>> like this:
>> - wibox
>> - imagebox
>> - progressbar
>> - graph
>> - textbox
>> - wiboxbox (dunno...whats your idea? I'd call the parent widget and
>> this one wibox)
>> - taglist
>> - tasklist
>> - screen
>> - tag
>> - client
>
> This has a bit evolved since our last discussion. Here the state of art
> in next at that data:
> - window
> - ewindow (not instanciable)
> - wibox
> - client
> - tag
> - image
> - screen
> - timer
>
> And so far I can't see more. There may be more class if someday I start
> multiple inheritance. Not decided yet. (I'd prefer not to need it).
>
>> Did you think about having these as tables and not userdata? I had a
>> look at luaclass.c and I don't understand it too well, but it looks
>> like the code implementing class inheritance for userdata. If tables
>> were used, none of this would be needed (pushing SLOC under 10k? :D)?
>> Or am I missing something (again)?
>
> Yes.
> We can in theory replace wibox object with a table rather than a
> userdata (C struct), of course.
> Problem is that it's gonna be a fucking mess to get property of a table,
> lua_getfield(), lua_towhatever, etc, and we just don't use the C
> compiler checks anymore, etc. So this is not a road I'll take.
>
>> One idea that may be worth a thought (but might also be impossible)
>> would be loading the default rc.lua before the custom as a way to
>> preset defaults. The custom rc.lua could be empty, or contain custom
>> keybindings only, replace just a few things or be a full config
>> replacing everything. I just didn't figure a clean way to do it...
>> There may not be any... Just something you might have thought about
>> before, or might wanna think a bit now :)
>
> That's a though, but it seems kinda "hard" to reset things. Keep it mind
> it's a programming language we are talking about.
>
> OTOH, I was more wondering if keeping things in module wouldn't be
> simpler.
> Fact is, most users edit the big key binding tables, and that's it. They
> don't do fancy thing with it.
> So, I think we need a Lua module converting some datastructure (maybe
> not a Lua datastructure, I don't know, a YAML data structure !)
> and building keybindings.
yeah, basic configuration could be separate in a simple file. This
will allow to configure basic stuff : wallpaper, tag's name, tag's
layout, keybinding with a format that do not change between version.
that is for simple use case. Part of this configuration file could be
loaded by rc.lua, for example tag handling code get the tag's name
from the configuration file. Power user can continue editing rc.lua to
construct the wm they want, normal user just edit the config file.
Splitting data from code seems a pretty good idea :-)
my two cents..
>
> Another example: reality is most users won't write their own label
> function to set window title in tasklist. So a tasklist object, like all
> object IMHO, should be instanciable with tasklist {}, and that's it.
> So building a status bar is simply as:
>
> mystatusbar = statusbar
> {
> position = "top",
> childrens =
> {
> taglist { },
> tasklist { }
> }
> }
>
> Point. If you want to modify taglist, well, do assign it a variable, and
> modify its properties, whatever. But that should be kept simple.
>
> --
> Julien Danjou
> // ᐰ <jul...@danjou.info> http://julien.danjou.info
> // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
> // This is the end of my signature.
>
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
