Change how customizer params are applied #529
Reference in New Issue
Block a user
Delete Branch "kurt/customizer-tweaks"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Very interested in your thoughts on this @franknoirot, I hope I've been able to articulate properly what the problem is. Very open to other ideas too.
When I mention unexpected behaviour in OpenSCAD this is what I'm referring to
https://github.com/openscad/openscad/pull/3864#issuecomment-926471312
But the solution I'm currently running with I came to because even if the above issue is fixed there is still didn't like the idea of updating the customizer values when initial values change in the script because it will require double renders and that seems messy to me.
https://user-images.githubusercontent.com/29681384/134760054-b7b8978b-a6e0-4f49-aee9-d9868e107200.mp4
Ugh, that sounds bit off to me. If I minimize the parameters to better see, and change code. I would get confused when my values reset without changing them.
Do you use the customizer during dev @hrgdavor?
It just seems to be that the customizer values should always be treated as fairly ephemeral. When ever I added customizer values, its normally always for other people consumption and not values I care about saving or losing but that is just me so getting an explanation of how you use it would be useful.
I think the "value that last change" either in customizer or script is the one to be applied is a really great idea, but the double-render really kills it. And yeah I guess switching between the customizer and script for values depending on the open or closed state of the cutomizer is a little implicit. We could add an explicit toggle for "customizer enabled" but it seems like a bit much, we'd than have two toggles for auto update and enabled (maybe it could be a select
[disabled, enabled, auto-update]). I guess I'm worried that being too timid to make bold choices for work flow means we clutter the UI with toggles for every little thing when making a good choice could will suit 99% of use-cases and only inconvenience some fringe workflows and intern keep the UI simple for those who are using it for the first time.Well, I do not know what others would expect....
I do use parameters from customizer during dev, as I test edge cases. But I could get used to the flow you are proposing so don't take my suggestions here as must, just ideas.
The double render for openscad could be resolved by having openscad produce both screenshot and parameter definitions in single call.
You could also tweak the script in your labmda to call OpenSCAD twice in one run: 1 generate preview, 2 call parse (I think you should not notice any slowdown versus normal case when you only render preview)
In the future if you implement presets, this could be solved elegantly, with a select box for presets with choices:
This would allow user to go through this single select box and have available both cases we were talking about and also presets.
I would be bold and suggest you make the presets ui that has only the 2 options for now
that way our dilemma is solved, and u have basis for presets(that is also useful right away). No need to implement presets fully right away. And as a bonus there is no awkward transition from some custom solution you make now to the shiny future with presets.
I want to avoid adding complexity to the OpenSCAD Lambda, at least I think the trade off now is not worth it. especially since the CQ folks have shown interest in implementing customizer metadata too and since it's also a network package want to keep it simple.
You're right that having the presets changes things, and likely worth circling back to this when it comes to implement that, but not going to do that right now.
so here's my next iteration, is basically just using the simple mental model of you're either in customizer mode or not
https://user-images.githubusercontent.com/29681384/134787593-3738161e-39bc-47e3-8e53-35bca6b2f74c.mp4
@Irev-Dev I really like this latest mental model.
well, I love the reset button,
but with it, the parameters not being applied when hidden is a bit unnecessary.
My problem it that I am forced to look at the model through the parameters form ☹️ or pan it upwards to see properly.
That is the "bug" that kicked off these changes lol
https://github.com/Irev-Dev/cadhub/issues/488#issuecomment-913249793
and
https://discord.com/channels/775984095250612234/775984095250612240/890731580052615169
It's important to be able to turn off the customizer, I get that the reset value takes the job some what, but it's extremely confusing to have the model not update when variables change when the customizer is closed and the reset button is not visible.
Maybe we could put customizer into it's own panel instead of combined with the view (only in the IDE not the details page), but I'm leaning towards merging this iteration to give it 5 minutes as it mostly seems fine to me unless it's being used on a tiny screen.
I think is good to address the initial issue.
I'd like to sketch out a layout idea now that we have 3 buttons/toggles up in the customizer pane, but I like what you've done with the Update button deactivating when Auto Update is on.
I hear @hrgdavor's concerns about the pane overtaking the viewer navigation and think it might be worth trying out a branch in the near future that makes the Customizer a tab like the CAD Package info tab has been made. Another nice knock-on affect of that would be the opportunity to sync the code and the param defaults when switching between tabs, as you'd never see both the code and the params at the same time.
For me this is usable, but still awkward personally.
I would not want to lose the parameters custom values just by switching tabs. The reset button would be enough to fix the initial issue, with author in full control, and without the extra automation based on customizer visibility, :)
Keen to see what you come up with after having a bit more of a think about it @franknoirot . Sorry about the proliferation of buttons. I think the reset button needs to stay there, but maybe the auto-update could even be moved into the side-tray? just a thought.
Moving the customizer to the editor tab as you suggested Frank or some other kind of layout is definitely worth considering since you was initially designed it for the project profile and it got thrown into the IDE too, so a rethink for how it fits in best can't hurt.
Last commit removes the re-render on customizer open/close in project profile, as it shouldn't behave the same as in the IDE.