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
Added ponoko-specific changes to color and line width. #105
Conversation
That's clearly going in the right direction. I would prefer if self.ctx would be encapsulated with both the saved() context manager and the new color handling. This should not be too difficult. Just make saved a method of the Boxes class and add a method for setting the color. I would probably move all the generator over to the new saved method. But this is out of scope here and can be done later on. |
saved() should probably also do the get_current_point() move_to() dance. cts.restore() can't as it's just a cairo function. For most cases a Boxes.moveTo() call is following the ctx.restore(). So the ctx.move_to() is not needed. But just a few days a go I had someone running into this pitfall. |
I would be happy to take your direction on rewriting my changes. I can
implement it as three separate pull requests to be considered serially
because I don't have as much familiarity with git to do it any other way.
If you see a different way of doing this, please point me to more info; I
appreciate the instruction.
Thanks! I'm looking forward to this.
…On Fri, Dec 14, 2018 at 6:26 AM Florian Festi ***@***.***> wrote:
saved() should probably also do the get_current_point() move_to() dance.
cts.restore() can't as it's just a cairo function. For most cases a
Boxes.moveTo() call is following the ctx.restore(). So the ctx.move_to() is
not needed. But just a few days a go I had someone running into this
pitfall.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#105 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADAVqZT7AqNbfRl27vHS3mKvWuNzowqvks5u44rigaJpZM4ZPpgb>
.
|
https://stackoverflow.com/questions/6217156/break-a-previous-commit-into-multiple-commits explains how to split up patches. |
I have created a new pull request. I hope it is to your liking; as for the
other things you wanted to see done, I'm happy to do them after this is
approved. I was concerned about regressions, since there's a lot of code
without test cases. If this is accepted, I'd like to propose another
feature.
Thanks for your lending your experience and giving me the opportunity to
learn.
Wayne
…On Fri, Dec 14, 2018 at 6:26 PM Florian Festi ***@***.***> wrote:
https://stackoverflow.com/questions/6217156/break-a-previous-commit-into-multiple-commits
explains how to split up patches.
After the *git reset* you can *git add -i* the pieces you want in the
commit and then just commit the new patches one after the other. It's not
hard. Just a bit scary at first. I often create a new branch that I split
up and keep the old one around to be able to easily look at the original
patch.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#105 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADAVqY88wnsO6yUNEO08BreUnElvh9jdks5u5DOygaJpZM4ZPpgb>
.
|
Ok, this PR is superseded by #112 Closing here. |
This feature adds support for creating boxes destined for Ponoko. The user's workflow is to specify
scripts/boxes --format=svg_Ponoko
The user will then import the resulting svg into one of the three Ponoko-supplies templates.
In order to support this feature, I used a python generator for saving and restoring the cairo context around color changes so there won't be a need to remember the previous color. I kept other refactoring to a minimum.