Proposal for state handling.

[stuaxo]

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.

[rlafuente]

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.

[stuaxo]

Check out the rough cut of this in the notebooks dir.

SceneGraph 3 - State node as a group.ipynb

[stuaxo]

It adds the idea of context (this is just the current state).

The name context is copied from cairo.

[stuaxo]

I haven't convinced myself entirely of this - on the one hand it works, on the other it seems a little odd.

[stuaxo]

Hi @rlafuente immutability is great for avoiding bugs.

Things that we add to the graph should be immutable, otherwise you can:

• add a path the graph
  • add a new point to that path
  • add the path to the graph again

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.