-
Notifications
You must be signed in to change notification settings - Fork 1
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
Proposal for state handling. #1
Comments
Looks like a sound approach, go for it :-)
…On June 2, 2019 8:58:17 PM GMT+02:00, Stuart Axon ***@***.***> wrote:
I'm a big fan of this sort of API:
```
with fill((1,1,0)):
# do drawing here
with stroke((0, 0, 0)):
# do drawing here
```
or even some sort of generic
```
with settings(fill=(1,1,0), stroke=(0, 0, 0), scale=2.0):
# do drawing here
```
Which got me thinking about a different approach for a State node.
A State Node could be a group that can hold other nodes.
This script:
```
with fill((1, 0, 0)):
rect(...)
```
Could result in a graph like this:
```
SceneGraph:
StateNode(fill=(1, 0, 0)) # fill((1, 0, 0)
PathNode(....) # rect(...)
```
It solves the problem of how to have initial settings for fill and
stroke, since you make the root node be a State Node:
```
SceneGraph:
StateNode(... initial state...) # set background and initial state
StateNode(fill=(1, 0, 0)) # fill((1, 0, 0)
PathNode(....) # rect(...)
```
I'll try and put together a notebook to demo this.
I think it should make certain things simpler.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#1
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
Check out the rough cut of this in the notebooks dir. |
It adds the idea of context (this is just the current state). The name context is copied from cairo. |
I haven't convinced myself entirely of this - on the one hand it works, on the other it seems a little odd. |
Hi @rlafuente immutability is great for avoiding bugs. Things that we add to the graph should be immutable, otherwise you can:
When you render there will be identical copies with the extra node. Draw seems to correspond to adding things to the graph. (There is no reason to add a path that is never drawn to the graph). I'm still not quite sure how APIs that get feedback (e.g. extents of a path) will work, I guess we need to work out what they are first. |
I'm a big fan of this sort of API:
or even some sort of generic
Which got me thinking about a different approach for a State node.
A State Node could be a group that can hold other nodes.
This script:
Could result in a graph like this:
It solves the problem of how to have initial settings for fill and stroke, since you make the root node be a State Node:
I'll try and put together a notebook to demo this.
I think it should make certain things simpler.
The text was updated successfully, but these errors were encountered: