Conditional Drop Down Box ?
Regarding the Customizer. I create 3 Drop Down Boxes:
// Do you want a bottom on the design?
has_bottom = "no"; // [no:No, yes:Yes]
// Do you want a box?
has_box = "no"; // [no:No, yes:Yes]
// Do you want dividers?
has_dividers = "yes"; // [no:No, yes:Yes]
In case has_bottom and has_box are both false ("no") and has_dividers true
("yes")...
I want a fourth Drop Down Box to appear:
if (has_box == "no" && has_bottom == "no" && has_dividers == "yes") {
// Do you want divider stabilizers? (RECOMMENDED)
has_divider_stabilizers = "yes"; // [no:No, yes:Yes]
}
This doesn't seem to work. Any way to make the has_divider_stabilizers
appear (if some condition) ???
--
Sent from: http://forum.openscad.org/
On 08/26/2018 10:58 PM, quix wrote:
This doesn't seem to work. Any way to make the has_divider_stabilizers
appear (if some condition) ???
No, that is not supported.
Setting the value for use in the model later would also need to use
the ternary operator, the "if" will just create a new variable inside
that "if" scope.
has_divider_stabilizers =
has_box == "no" && has_bottom == "no" && has_dividers == "yes")
? "yes"
: "no";
ciao,
Torsten.
Have never used this ternary operator :) Might wanna read up on it...
So you're saying that what I'm trying to achieve is actually not doable in
the current version of OpenSCAD? I could see the definite value in such a
feature, whereby users could click through a series of option boxes, with
the design only showing relevant options and gradually guiding the user
through choices.
Too bad. Guess I'll have to get the job done some other way. Feel free to
give me some recommendations :)
--
Sent from: http://forum.openscad.org/
The origins of the customiser is from work done on the thingiverse
site(?) and the forms there are not dynamic.
Its an interesting idea to basically allow a css-like hide operation for
parameters but then pretty soon we'd need
conditional ranges too and then its an entire UI system. So in all
likelihood the UI capability will IMHO stop about where it is now.
So just accept that there are UI options which will remain in teh UI but
not be used if some conditionals are not set.
I put these in separate menus. Like Text menu /* [Text] */ to indicate
that the options for text are in that pane and in the
main pane I might have a checkbox for text - visually indiciating that
its a conditional option.
I.e. if you didn't check Enable text then there's not much reason to
be setting text options in the text pane.
Cheers...
On 8/27/2018 9:18 AM, quix wrote:
Have never used this ternary operator :) Might wanna read up on it...
So you're saying that what I'm trying to achieve is actually not doable in
the current version of OpenSCAD? I could see the definite value in such a
feature, whereby users could click through a series of option boxes, with
the design only showing relevant options and gradually guiding the user
through choices.
Too bad. Guess I'll have to get the job done some other way. Feel free to
give me some recommendations :)
On 26.08.2018 23:31, Mark Schafer wrote:
The origins of the customiser is from work done on the thingiverse
site(?) and the forms there are not dynamic.
correct
Its an interesting idea to basically allow a css-like hide operation
for parameters but then pretty soon we'd need
conditional ranges too and then its an entire UI system. So in all
likelihood the UI capability will IMHO stop about where it is now.
Here is working code for conditional groups:
https://github.com/openscad/openscad/pull/2359
including the discussion why we are not going that route.
Conditional ranges: Sure, that is technically doable, but thingiverse
compatibility speaks against it.
(note that show_if would fail silently, where as conditional ranges do
not have a fail safe)
I mean, we can always discuss things.
Anyone can pickup my code.
Maybe we could make it an experimental feature within an experimental
feature for show_if -
but saying that: I personally consider getting the customizer stabile
and the inputdriver experimental in the main branch more important.
With kind regards,
MichaelPFrey
Hi Michael! You began OpenSCAD? I absolutely love it. I think the future is
customizable designs. Everything from shoes to the weird box divider thingie
I'm currently working on... we as consumers generally want choices, because
we want to showcase our individuality through our stuff.
I don't know to what extent it would be a hazzle to incorporate this
feature... it just seems obvious to me that some options / parameters are
dependent on others already having been activated and it doesn't make sense
to show options, unless their relevant.
Example:
You want a certain type of shoe. You choose the Velcro / self tying design.
Now all the shoelace related options should disappear... otherwise it
becomes needless clutter.
--
Sent from: http://forum.openscad.org/
On 28.08.2018 14:32, quix wrote:
Hi Michael! You began OpenSCAD?
No, OpenSCAD was began by Marius Kintel and Clifford Wolf.
(Marius Kintel still beeing the maintainer)
I am just /a/ developer that is working on various things.
Any one can at any time start developing on OpenSCAD and open a pull
request.
(open OpenSCAD and take a look at about scrolling down to patches - it
is a long list of people that have worked on this and that)
In all Open Source Projects, there is the principle that when you
/really/ want a feature, the best way of getting it is to implement it.
My goal is to get the customizer stable and the inputdriver experimental
in the main branch.
On 28.08.2018 14:32, quix wrote:
I don't know to what extent it would be a hazzle to incorporate this
feature... it just seems obvious to me that some options / parameters are
dependent on others already having been activated and it doesn't make sense
to show options, unless their relevant.
The hazzle is philosophical. The comment syntax is from
https://www.thingiverse.com/ and there is some interest of keeping it
compatible.
The comment syntax is also pretty complicated when you start digging
deeper into the source code.
This syntax was and is responsible for various crashes.
Extending this syntax would make this even worse.
Example:
You want a certain type of shoe. You choose the Velcro / self tying design.
Now all the shoelace related options should disappear... otherwise it
becomes needless clutter.
I understand the use.
The problem is somewhere else:
-
Getting the customizer stable is more important then adding features
(even when you think it is stable: No it is not, we "regularly" find
crashes) -
adding features necessarily breaks thingiverse compatibility
(which was the initial reason why the OpenSCAD customizer was
implemented in the first place) -
there is a discuss about adding a native annotation syntax, that could
be even more power full.
The more work we put into the comment syntax, the more constrains we
have later for the native syntax.
OpenSCAD as an Open Source Project is slowly moving - it moves forward,
but do my knowledge, this is a hobby project for all involved developers.
With kind regards,
Michael Frey
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org