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

Allow generic drawing effects #63

Open
danh32 opened this issue Apr 21, 2018 · 3 comments
Open

Allow generic drawing effects #63

danh32 opened this issue Apr 21, 2018 · 3 comments

Comments

@danh32
Copy link
Contributor

danh32 commented Apr 21, 2018

More use-cases are popping up with specific effects in mind. I'd like to make Spark able to handle these specific effects for folks more easily than either adding special cases and attributes for them in SparkView itself, or having to request them to subclass SparkView and do manual drawing.

A pluggable solution with a way for folks to easily override just the drawing of the spark should be a great first step.

@cammace
Copy link
Contributor

cammace commented Apr 25, 2018

subclass SparkView and do manual drawing

So if I understand correctly, similiar to how the Paint objects have getter, and more importantly, setters, you'd like the same accessibility for the Paths? I would think we'd want to keep these not mutable since everytime populatePath is called, the path is reset and drawn again using the data from the adapter.

If you mean setting the Paint objects like mentioned in #59, setSparkFillPaint is already exposed to the dev?

@danh32
Copy link
Contributor Author

danh32 commented Apr 25, 2018

My super-rough idea so far is to have a class something like:

interface SparkDraw {
  void draw(Canvas c, DrawArgs args);
}

class DrawArgs {
  public Path sparkPath;
  public Path sparkPaint;
  public float[] scaledPointsY;
  public float[] scaledPointsX;
  public float scrubY;
  public float scrubX;
  ...
}

Then users can override the draw there and mutate the paths/paints if they want crazier effects.

This isn't super well thought out yet, though, definitely open to ideas here!

@cammace
Copy link
Contributor

cammace commented Apr 25, 2018

DrawArgs sounds like it would clean up the SparkView significantly with all the getters and setters, we could even possibly throw in a createFromAttributes method which further shrinks the view class. I did something similar recently here.

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