-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating Oval to use new styles #736
Conversation
@@ -7,7 +7,7 @@ class Arc | |||
include Common::Clickable | |||
include DimensionsDelegations | |||
|
|||
attr_reader :app, :parent, :dimensions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed that many of these kinds of elements can access their gui so I figured I'd add this for uniformity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the consistency of doing that. I've run into a number of cases where I had to add the gui
to something just because no one had needed it quite yet.
Although I don't like meta-programming the world away, almost makes me wonder if one of our Common
modules ought to just enforce that everyone gets app
, parent
, gui
and maybe dimensions
... Food for later thought.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could do that. E.g. Shoes::CommonMethods or establish a base class. Something.
That wouldn't even need meta programming. You can just declare the readers in the module and bam they are there! (might be overridden in the actual class but hey no harm done!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also: good idea!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should I open an issue with this idea, or were you guys thinking to chunk that in with this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
separate issue please!
else | ||
supported_styles << style | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all of the above could/should go in a method that gathers the supported styles to avoid duplicating that code everywhere
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. One of the (meta issues to be addressed later) is about how to centralize styles better. So it seems to me that in this PR (and in similar ones i.e. rect or star) I'll need to put something together quickly to handle specs, and then redo it later when we attack the specs meta issue.
Is that right? I ask because I'm not sure to what extent I should tackle the duplication issue in this PR :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like to tackle duplication as soon as I see it. You know because otherwise the amount of work just gets bigger, e.g. in the next PRs you'd need to copy that same code... and then when you make it all good again you have to refactor all of them.
So I'd like to tackle this as early as possible.
Looks good overall! |
Agreed, this is definitely on a good path forward. 🚀 |
@@ -1 +1,18 @@ | |||
require 'spec_helper' | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, so this is the only thing I changed essentially with this last commit. Something tells me this is pretty unorthodox and therefore maybe bad, but I view it more as a quick patch until the meta-styles spec issue (the one where we don't want to use lots of it_behaves_like
s) gets addressed.
Whaddya think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm good with pulling these out in this fashion as long as it's an interim step, which seems to be your plan.
1 similar comment
def it_styles_with(*styles) | ||
#unpack styles | ||
supported_styles = [] | ||
styles.each do |style| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should not be indented
Wow, that's a big coverage decrease . . . just a sec |
@KCErb do you think this is ready for merge? |
Nearly, I just haven't been able to solve the issue in the first comment yet. Everything I've looked at seems to be working correctly so I don't know why oval won't listen to |
@KCErb I think the problem is in
In I can't get to it right now, but we should add a spec for this merging of styles, so we know exactly how we expect it to behave, and since it doesn't seem to be tested. |
Changes Unknown when pulling bc88438 on KCErb:oval_style into * on shoes:master*. |
1 similar comment
Changes Unknown when pulling bc88438 on KCErb:oval_style into * on shoes:master*. |
I think this is ready to merge. |
@@ -243,7 +243,7 @@ def oval(*opts, &blk) | |||
EOS | |||
raise ArgumentError, message | |||
end | |||
create Shoes::Oval, left, top, width, height, style.merge(oval_style), &blk |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wasnotrice The merging all happens in style now, so in the dsl we don't do any merging. I'm glad you pointed this out since it was the problem! :)
Read over this and code-wise things are looking good for a merge. I'm liking how the new styling is playing out... and nice catch on the manual as well! I decided to do some testing, and found one issue with
This looks a lot like the color string isn't getting translated into a Do you want to take a look at it @KCErb? Or I'm happy to debug and/or give you any assistance I can! Thanks again for all the hard work! Good work on |
OK, I think I fixed it. I just needed to normalize the styles before they go in. In my test cases I'd been passing arc and oval Shoes Colors like It does make me want to change this aspect of how Styles are handled . . . though I can't think of a better way. . . I'm just not a fan of creating a StyleNormalizer class, just so that we can pass fill and stroke arguments to pattern. I may put something over in style that does this. Any suggestions? PS. Now I think this is ready to merge :) |
Changes Unknown when pulling c9cb687 on KCErb:oval_style into * on shoes:master*. |
This is a good time to add a spec for this case 😉 |
Just building upon what Eric said: It is arguable the best time to add specs. If an error occurred once it sure can occur twice. Also it's a good way to practice TDD. You have a very concrete problem and you want to write a spec for it. Write the spec. Run it. It should fail. Then implement it, rerun. Spec should pass. Run a demo app to make sure et voila :) Regression specs are of utmost importance imo :) |
Get rid of "global" subject, and explicitly create the "oval" object in each describe block. We were creating a 'circle' object, but running specs against an 'oval' object that was inherited from a parent context.
Add specs for creating ovals with hex strings
Thanks @wasnotrice! I've been so swamped this last week, sorry for being slow! |
Changes Unknown when pulling 2437857 on KCErb:oval_style into * on shoes:master*. |
So anything missing here? Or is this ready to be merged in? Another review or so? |
I believe that everything is working except for the issues I just opened. 🚀 |
Update Arc and Oval to use Style module First step in a larger conversion of all styled DSL objects
Great work, @KCErb! Thanks for all of your hard work on this, and your perseverance! I noticed you had not yet been added to Team Shoes, so I also fixed that oversight! |
Hey great! I didn't know about teams. I'll try not to actually use any of those admin privileges. Sounds dangerous 💥 |
One handy thing is that you can create branches in the shoes/shoes4 On Mon, Jun 9, 2014 at 11:34 PM, KCErb notifications@github.com wrote:
|
This isn't quite ready yet. I've only found one problem (which really means two problems since in the meta issue #711 we plan to change the way style specs work )
The issue is in setting oval styles via the style method:
produces a black oval. I haven't figured that out yet, but figured I'd commit what I have and stick it up here until next chance I get to look at this.