Skip to content
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

Open
stuaxo opened this issue Jun 2, 2019 · 5 comments
Open

Proposal for state handling. #1

stuaxo opened this issue Jun 2, 2019 · 5 comments

Comments

@stuaxo
Copy link
Contributor

stuaxo commented Jun 2, 2019

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
Copy link
Contributor

rlafuente commented Jun 2, 2019 via email

@stuaxo
Copy link
Contributor Author

stuaxo commented Jun 2, 2019

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

SceneGraph 3 - State node as a group.ipynb

@stuaxo
Copy link
Contributor Author

stuaxo commented Jun 2, 2019

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

The name context is copied from cairo.

@stuaxo
Copy link
Contributor Author

stuaxo commented Jun 3, 2019

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

@stuaxo
Copy link
Contributor Author

stuaxo commented Jun 6, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants