Open stuaxo opened 5 years ago
Looks like a sound approach, go for it :-)
On June 2, 2019 8:58:17 PM GMT+02:00, Stuart Axon notifications@github.com 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: https://github.com/shoebot/toybot-scenegraph/issues/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.