Make WithStyle behave as a stack #78
Conversation
Demonstrates how the first 'okay' label renders with the default - rather than the "normal" style, and the subsequent ResetStyle reconfigures to "normal".
This allows testing of color behaviors to testSurface, and therefore of Style application more generally.
This adds a test for the improper behavior shown in 7e7a180; WithStyle doesn't provide a stack of styles, it just resets the style (ResetStyle) after WithStyle is complete.
Without this commit, WithStyle makes a Painter reset to the default rather than going back to the style it had before. This means if a a Widget within a styled Box is also styled, the Widgets after it in the Box would not inherit the Box's style. Previous commits demonstrate this bug; this gets the tests to pass.
|
Looks good to me! Good idea with the One interesting thing I noticed though is that in the color example, the |
Missed some of these when merging in marcusolsson#78.
|
Yeah, I noticed that issue as well- I haven't stepped through to figure out what's up with it. Uninformed speculation: re-using a Yes, request went through after some poking; you may see some more PRs coming up, as I'll be on vacation for a couple weeks -> time for personal projects :-) |
Missed some of these when merging in #78.
The current behavior is that
WIthStylesets aStyleon thePainter; but when thefuncsupplied toWithStyleis done, it resets to the default style of the entire program.This is, IMO, the wrong behavior- and a cause behind at least why my attempt at resolving #60 wasn't working.
This uses the call stack of drawing to push/pop styles when
WithStyleis called. Within the scope of aWithStyle, the style is applied; outside, it's whatever style was previously part of thePainter. It adds a demo (inexamples/) of the issue, new functionality totestSurfaceto allow testing of colors, and a test for the expected behavior. This also removesResetStyle, since that would essentially break the notion of style inheritance.