-
Notifications
You must be signed in to change notification settings - Fork 12
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
Refactor playground to not use toListFormField + Remove unused imports from examples #131
Refactor playground to not use toListFormField + Remove unused imports from examples #131
Conversation
This changes how this all works. Previously we generated expressions that act directly on `state` to manipulate its values. Now we fetch a pointer to each field on state or each field of an instance in a seq and act on that. This gets rid entirely of "toFormField", which can now be used for an individual field as well as a field of an instance in a seq.
Nim 1.6.12 appears to not like the `ptr enum` type. ptr[enum] seems okay though, so it just doesn't like the notation.
This required moving open to widgets.nim as due to being part of playground that proc was not available there (?).
Fixed all outstanding remarks. Sidenote, 1 more addition I made was: Apparently range is not covered by current toFormField procs. So I made one that works for all ranges. That required introducing a |
This requires introducing a `Range` concept as `range` is not a valid typeclass to use as a generic parameter.
This is done in order to avoid any of the following proc bodies accidentally missing out on a proc that was provided befor e it. This helps with not needing to care about the order that the procs are defined in.
And just like that I think I cracked the last piece. Therefore we can fully auto-generate forms for the vast majority of nim-types. I guess any type that nim provides via magic would not be possible to represent like this. |
Err maybe just for reference: I do not plan on doing anything else on this unless there's feedback, I'm happy with the current level this is at and can't see anything right now myself that I'd change. Not sure if that was clear or not... I guess it makes sense to ask what typically indicates to you that a PR is not getting any further work done on unless there's feedback requests it 😅 |
Anything else? |
This import is relevant when -d:pixbufAsync is set
This adds a new overload for toFormField to specifically handle object variants. Object Variants are hard to handle and thus by default shall receive the placeholder field that reminds the user to define their own toFormField proc for their variant. The Overload works via having a ObjectVariant concept, which catches all toFormField invocations for object variants. It simply checks on a technicality if a type-field can be assigned to itself. This is never true for kind fields on object variants as it results in compiletime errors.
The new name is ObjectVariantType. This serves as an important distinction that his is a concept that covers **types**, not **instances**. The doc comment was adjusted to clarify this as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ref object
variant types do not work correctly.
To do so the proc that checks it just needs to also accept ref objects and use the `getIterator` template to decide on whether or not to deref before using fieldPairs.
Great work! 😄 |
This takes care of the refactoring we had discussed for playground and for which I had written up a reminder in #106 : #106 (comment)
Does exactly what the heading states.
This PR should be mostly independent from the other 10. I distantly recall one of the other 10 requiring me to implement another toListFormField proc, but I can adjust that.
While I was at it I also noticed a couple examples importing modules they no longer need, so just cleared that up to remove those warning messages.
I also did a slight change to the Scale example, as it really does not look pretty when you add a mark with position top/right to it if it takes up the entire Window. So I put it in a Box() widget with expand: false.