On 11.01.2012 15:13, Anurag Priyam wrote: > 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.
You might be interested in the following commit: commit 2216b6a341ddb840200ea85207f8a59a5b3d61a6 Author: Uli Schlachter <[email protected]> Date: Fri Feb 17 17:48:11 2012 +0100 gears.color: Add table-based color definitions Signed-off-by: Uli Schlachter <[email protected]> The syntax is almost identical to what you proposed above. The only difference is that I went with "type" instead of "gradient". Oh and in case anyone is following cairo development: There is not the slightest possibility that I will add a string-based syntax for mesh patterns. That would be crazy! > 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. I did something like that with obvious' widget API. However, I don't think I'll add something like that to gears.color. If someone wants, he can write the needed wrapper around oocairo for himself. :-) > P.S: Your code is pretty neat actually. The way redundancy has been > minimized with automatic function generation is super sweet. Thanks! The above mentioned commit removed that. :-) Uli -- Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? -- To unsubscribe, send mail to [email protected].
