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

Change arguments of an Action #216

Closed
Wikunia opened this issue Oct 1, 2020 · 6 comments · Fixed by #234
Closed

Change arguments of an Action #216

Wikunia opened this issue Oct 1, 2020 · 6 comments · Fixed by #234
Labels
enhancement New feature or request
Milestone

Comments

@Wikunia
Copy link
Member

Wikunia commented Oct 1, 2020

Is your feature request related to a problem? Please explain.
Currently each action has access to video, action, frame but maybe the user would like to change a parameter.
We can use scaling for changing the radius of a circle as an example but maybe one would like to draw a line that gets longer for some frames which can currently be done hard coded with frame but that's not intuitive.

Describe the solution you'd like
One option would be:

Action(1:100, (args...; x=0, y=0)->draw_line(O, Point(x, y)); subactions=[
     SubAction(10:50, change(:x=>100))
])

So one can define keyword arguments that can be changed in an animated way. The change would always be from the last value to the next. I'm not sure whether Javis has internally access to the x=0 though 🤔
I think we need :x as x itself is not defined.

Describe alternatives you've considered
If we don't have access to the default value we can maybe use:

change(:x, 0, 100)

or

change(:x, 0 => 100)

Additional context
In general this should of course also work with Animations.jl such that one can write an Animation and just call change(:x) to apply that change to the variable x.

@Wikunia Wikunia added the enhancement New feature or request label Oct 1, 2020
@Wikunia
Copy link
Member Author

Wikunia commented Oct 16, 2020

Seems like it's not that easy to or even possible to get access to the default value.

@Wikunia Wikunia added this to the v0.2.x milestone Oct 16, 2020
@codejaeger
Copy link
Contributor

Seems like it's not that easy to or even possible to get access to the default value.

@Wikunia This turns out to be a bug with respect to documentation for the change function. I also tried to look for a way to extract the defaults from the keyword arguments but no success yet. Apart from that, I think the other issue this feature might help to solve is passing relevant keywords to drawing functions. Pulling in issue #313, if multiple draw functions are to be composed together to form the object drawing function then it makes sense to let the individual draw functions access keywords only specific to their purpose.
.

@Wikunia
Copy link
Member Author

Wikunia commented Jun 21, 2021

Can you clarify what you mean? I can't see anything wrong with the docstring for the change function. It either sets a value without animation or animates when a pair of values is given. I also don't understand the second part of your point can you give an example?

@codejaeger
Copy link
Contributor

codejaeger commented Jun 21, 2021

Sorry I termed it as a bug, it is actually more of a feature request 😄 . My assumption was that change would interpolate between the present default value used in the drawing function and the new value passed. Now I see it clearly mentioned in the docstrings that it just changes the keyword value, apologies! If the change keyword is not available to the object then I presume interpolating is difficult.

I was trying out a way around for issue 313. Consider the following

function Line(p1, p2)
  return (args...; line_width=12) -> custom_line(p1, p2, line_width)
end
function Circle(r)
  return (args...; radius=r) -> circle(O, radius, :fill)
end

obj = Object(1:50, [Line(p1, p2), Circle(r)])

Now, animating the line using line_width and circle via radius would lead to an error since all the change arguments are passed to the drawing function. Again, it is not decided yet how the multiple draw functions will be implemented but I guess the issue would result nonetheless.

@codejaeger
Copy link
Contributor

The reason I mentioned it in this thread is since, if there is a way to know what keywords a particular drawing function requires it will be possible to store the default from the change keywords themselves. Then probably interpolation could be done for a subset of keywords using change(:radius, 13).

@Wikunia
Copy link
Member Author

Wikunia commented Jun 21, 2021

One thing that would make this possible is to introduce a macro which then takes the defaults and writes them into the object metadata or similar.
The problem is that we would loose some dispatch functionality for the Object.

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

Successfully merging a pull request may close this issue.

2 participants