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.
|
I had a eureka moment and this did suddenly inspire me to play around again with complete generic form generation for any type. We can now fully generate the form for any given type with fields while still having the dummy-widget fallback for all those unknown types e.g. See here a generic version of The expanding "delete" button on the right is an issue I couldn't quite get rid of and stems from the toFormField of |
|
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.
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.