shoes/shoes4 — pull request #683 by KCErb (2014-05-06 22:15:55+00:00)
Title: A First Approach at Fully Implementing Style  - Not ready to merge!

Hi all, based on our discussion (#623) and bit of study on meta-programming I've had a lot of ideas for different ways to do this.

I got the impression from that discussion that the idea is to change a little at a time making each thing work well before moving on. That approach seems best and makes a lot of sense, but when it came down to it
I'm afraid that my approaches to the problem all involve changing a lot at once. :grin:

So I apologize in advance and am looking forward to hearing your constructive criticism. Here's the general idea and please note the inline comments.

### Changes I made
1) Instead of supports_styles(see #623), I decided to go with a style_accessor method which would make the element aware of which styles it supports. I went this route hoping that in the future this will be able to help us implement method 3.

(This doesn't work right now, and isn't the focus of this PR so it is commented out, but as I hope you'll see by reading on I think it's pretty fundamental)

2) Next we needed a method to initialize the style variable. I called it `style_init`. I don't necessarily like the look / feel of naming every style with its default value, so I'm sure this could be improved, but functionally I'm leaning towards something that explicitly tells us everything we need to know about a given element.

An alternative approach is for each element to hand style_accessor a set of default values for this element, and then let the user override them either at the instance level (while calling the function) or at the class level (by altering the element_default_style).

3) Next, I'd like to get rid of `Common::Stroke` and `Common::Fill`. These files seem to do two things
* define getter and setter methods for stroke and fill
* define default values for stroke and fill

I'd like to bump both of those functions to `Common::Style` (for example see line 23 in shoes/arc.rb)

4) I changed the backend to read `@style[:angle1]` instead of @obj.angle1. With `style_accessor` implemented we can go back to `@obj`.

5) Lastly, dsl.rb used to normalize styles before creating the element. In the new paradigm, styles are always normalized during initialization so this step is unnecessary.

### Pros

1) The main reason I'm liking this route is that I really like the manual page on style. It lays out simply what each element can and can't do. I want the code to do the same thing.

2) I think this sort of functionality could be easily extended to widget so that folks can define custom styles for their widgets

### Cons

1) It's a little verbose

2) You tell me :)

Whew, sorry for the novel. Don't hesitate to be brutally critical, I can take it :no_mouth: