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

Some questions #1

Open
yglukhov opened this issue Sep 15, 2017 · 4 comments
Open

Some questions #1

yglukhov opened this issue Sep 15, 2017 · 4 comments

Comments

@yglukhov
Copy link

Hey, sorry, could not find you on irc or gitter, so writing here.
I am also interested in layout systems and layout definition languages. Have you considered the cases for constraint-based layout such as:

  • changing the widgets geometry programmatically. How would such changes be propagated to the solver and further to other widgets.
  • modifying the view hierarchy programmatically. How would addition/removal of widgets affect existing constraints of neighboring widgets?
  • animation? How would you animate widget geometry so that it propagates to constraints of other widgets?

Would you mind joining https://gitter.im/nim-lang/Nim or #Nim irc so its easier to chat?

@jangko
Copy link
Owner

jangko commented Sep 15, 2017

Hi @yglukhov, I'm so happy you also interested in layout systems. I'd like to thank you for your nice kiwi library.

I assumed programmatically means doing something from scripting language, in this case from lua side.

  • changing the widgets geometry programmatically. How would such changes be propagated to the solver and further to other widgets? the parsed document is stored as AST, much like programming language. The variable participated/used in constraint solver are represented as symbol to variable. The symbol have flags, and any changes to variable value don't necessarily have instant effect. After all changes be made, we can update the solver accordingly, then redraw the whole layout.

  • modifying the view hierarchy programmatically. How would addition/removal of widgets affect existing constraints of neighboring widgets? similar with point number 1, changes in the AST means the tree would go into another semantic pass, and the layout language have features to cope with this situation. The relationship between widgets is not rigid, the layout language use flexible relationship between widgets, and it also has choice mechanism in case the previous relationship failed. The layout language also has class system, the class can be added or removed from a widget programmatically, and the whole relationship among widgets can be changed.

  • animation? How would you animate widget geometry so that it propagates to constraints of other widgets? I only have vague ideas about this, not sure exactly how to implement animation, perhaps I will figure it out later. My experiments show it's not too difficult, the constraint can be relaxed.

Would you mind joining https://gitter.im/nim-lang/Nim or #Nim irc so its easier to chat?
err, no promise, I don't have much time to chat over there.
I don't mind answering questions here.

@yglukhov
Copy link
Author

I'd like to thank you for your nice kiwi library.

I'm happy it has found its user too =)

in this case from lua side

As a matter of fact, that was another question I wanted to ask. =) Why not go fully native and provide optional thinner bindings for foreign VMs?

  • changing the widgets geometry programmatically
  • modifying the view hierarchy programmatically

Ok, those make sense, thanks.

  • animation?
    As far as I imagine the animation system would need to be intertangled with the solver, if you want smooth transitions for all affected variables. The other option would be to resolve on every frame but that doesn't sound practical for performance reasons. I thought that we could ask the solver for the states of all variables given the last value of the animated variable. And then we could start linear animations for all the affected variables, and the linearness could be curved with the original animation curve. But like i said this would make the animation/solver connection more complex. Anyway, I would suggest to start thinking about animation before you've gone too far =)

@jangko
Copy link
Owner

jangko commented Sep 16, 2017

Why not go fully native and provide optional thinner bindings for foreign VMs?

Yup, not everyone need lua. Nim itself already comfortable to work with. and luckily it's only a matter of conditional compilation to enable/disable lua presence.

I would suggest to start thinking about animation before you've gone too far =)

Agree, if razcal has a functional animation system + freedom to draw anything to the rendering buffer, it would attract users. need to change my current roadmap. Thank you.

@jangko
Copy link
Owner

jangko commented Sep 18, 2017

turn out, these questions are valid issue.

  • changing the widgets geometry programmatically
  • modifying the view hierarchy programmatically
  • animation

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