On Wed, Jan 11, 2012 at 5:05 PM, Uli Schlachter <[email protected]> wrote:
> On 11.01.2012 09:50, Anurag Priyam wrote:
[...]
>> cpugraph:set_color("linear:0,0:8,14:0,#FF5656:0.5,#88A175:1,#AECF96")
>
> nice to know you managed to fight through that mess.
> Now that you saw the evil, any ideas how this syntax can be improved?
> Perhaps it makes sense to bury the idea of "this must be a string" and turn
> into tables again? Dunno.
I was initially very impressed by the string syntax. I still hold that
it is neat. But as soon as I had to define a linear gradient for my
memory usage graph (widget), picking color values from theme:
membar:set_color("linear:0,0:8,14:0," .. beautiful.fg_end_widget ..
":0.5," .. beautiful.fg_center_widget .. ":1," .. beautiful.fg_widget)
I found myself wishing tables were supported, so I could write as:
membar:set_color({gradient = 'linear", from = {0,0}, to = { 8, 14 },
stops = {{ 0, beautiful.fg_end_widget}, {0.5,
beautiful.fg_center_widget}, {1, beautiful.fg_widget}})
This gives me a lot of flexibility. For example, I could _easily_
rewrite `to = {8, 14}` as `to = { width, height }`, where width and
height are width and height of my progressbar. It is easier to store
presets in a global config table, etc.
So I am definitely +1 for allowing tables.
Here is another idea, borrowed from [jQuery][1]:
membar:linear_gradient(0, 0, 8, 14):add_stop(0,
beautiful.fg_end_widget):add_stop(...)
It is called method chaining. Essentially, each method call returns an
object on which the next method can be called. Not sure if it can be
done in Lua and how easy/difficult it would be to implement. Besides,
this would make the API inconsistent.
P.S: Your code is pretty neat actually. The way redundancy has been
minimized with automatic function generation is super sweet.
[1]: http://jquery.com/
--
Anurag Priyam
--
To unsubscribe, send mail to [email protected].
