At 26.11.2009 23:36:04 Julien Danjou <[email protected]> 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
Yeah, these are the classes in C, I was listing the classes that would be
in Lua.
> 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).
I don't think its needed either.
> 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.
I don't have the insight like you... But is there no way to replace the function
these functions use to access the property of an object with one that would
use __index()? Surely there must be a (not too messy) way, is it not quite
common usecase for inheritance?
The userdata is just really awkward to work with in Lua, you'll end up
needing to implement this and that in C to get what you need in Lua...
> That's a though, but it seems kinda "hard" to reset things. Keep it mind
> it's a programming language we are talking about.
Yeah, it wouldn't 'reset' things. You'd define a function (or a set of
functions)
that would be called automatically after the configs (default, and then
custom) were loaded.
> 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.
I've thought about having modules too, but maybe its not needed, and
maybe it could case problems... some parts of the config are (or could
be for some users) interconnected. It could cause problems too.
I really wouldn't bring another format to this... Lua can do data definition
just well. And offers more flexibility of course (like defining your own
functions). With what i have in mind, the keybindings are the simplest
case, you'd just have:
globalkeys = {...}
root.keys(globalkeys)
In your rc.lua, the rest would be defined in system rc.lua.
> 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.
Sure, I thought of that too, just didn't think its even worth mentioning :)
I think all of the attributes should have defaults if possible, so that
ideally constructor can have no arguments. But all properties should
be settable through constructor as well as assigning a property
afterwards.
lukash
--
To unsubscribe, send mail to [email protected].
