How about something simple like: MyVar =parameter(index,list_of_values); Where the simplest in-program interpretation is: function parameter(index,list_of_values)=list_of_values[index]; ...but it may encapsulate alternate functionality based on arguments provided, such as range-checking, interpolation, etc. It could/would also provide the breakout hooks to dynamic UI generation/configuration, most likely in the same panel as the animation/time-stepping interface. Andrew. Sent from my iPhone > On Dec 15, 2014, at 8:44 AM, Torsten Paul <Torsten.Paul@gmx.de> wrote: > > As the big and interresting discussion in the "OpenSCAD 3000" (http://forum.openscad.org/OpenSCAD-3000-td8431.html) showed, there's quite some interrest and lots of knowledge about languages in general on the list. > > The "Customizer-like GUI" issue on github (https://github.com/openscad/openscad/issues/722) is trying to provide a parameter GUI to simplify some cases of interaction with OpenSCAD scripts. More details can be found on the project page: https://github.com/openscad/openscad/wiki/Project%3A-Form-based-script-parameterization > > The main question regarding the language is how to encode the information into the scripts. The Thingiverse Customizer uses comments as a workaround so it did not need to change OpenSCAD itself. While this is probably a reasonable choice for an external tool, I think a native implementation should be properly integrated. Personally I also see some additional use-cases that I think should be covered by the way we add this type of information (listed with some examples in the github issue) even if we will implement that (hopefully) at a later time. > > So any ideas and suggestions are welcome even if in the end only a single solution can be implemented :-). > > ciao, > Torsten. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

I'm a bit confused now. First I thought this list is where the internal discussions take place. Then I noticed most of the dev talk is happening on git hub. Now back to the mailing list. Anyways One thing to note about the Customizer like parameter definition is it would be very easy to implement. I could hook this up to the existing OpenSCAD code base in just a few hours coding and testing and - as you can see in my code branch already - it would touch the existing code only in two points. That means it would be a clearly defined code module with a very simple interface and thus less likely to interfere with other parts of the code. (Well actually I'm not 100% certain it won't interfere with other parts of the code because there seems to be some feature which references the last compiled document but without an in dept analysis of the code it is unclear which feature it is. I suspect it's the 'automatic reload' feature but I can't say for sure because the code for this feature seems to be all over mainwin.cc ) Now lets look at the function style definition: xyz = select( name="your parameter", default = 1.0, values = [ 10:2.0:30 ] ); I think this one would be more intuitive for the user. But it would be much more difficult to parse. Regular expressions won't do it here. This needs to be processed by the lexer. Now the question is when and from where to invoke the lexer? From the Parametric UI module after each change of the source in the editor? I think this would be preferred as it would result in a 'snappy' ui but what to do with syntax errors then? This definition is already somewhat prone to syntax errors like mismatching brackets, typos, etc. Then there is the annotation style. It might have benefits to do it this way. I'm not seeing them atm but I haven't read through all issues on github yet. So I might be missing something here. What I do see is the same problematic as for the function style definitions. If you plan on rewriting most of the code anyway then this might be the way to go I don't know. Otherwise personally I probably would go with the customizer comment syntax since that could be considered the standard right now and it's not a big deal to implement. ----- lazy.scad - http://www.thingiverse.com/thing:512443 -- View this message in context: http://forum.openscad.org/New-Language-Feature-Parameter-Information-to-generate-GUI-Forms-tp10544p10546.html Sent from the OpenSCAD mailing list archive at Nabble.com.

Hi! On 12/15/2014 05:41 PM, mx wrote: > I'm a bit confused now. First I thought this list is where the internal > discussions take place. Then I noticed most of the dev talk is happening on > git hub. Now back to the mailing list. Anyways > Yes, internal details, very specific to an issue, are good on Github. Things like discussions about GUI or language changes can reach a much wider audience on the mailing list and provide more ideas. E.g. the pointer Felipe posted does sound interesting. > One thing to note about the Customizer like parameter definition is it would > be very easy to implement. I could hook this up to the existing OpenSCAD > code base in just a few hours coding and testing and - as you can see in my > code branch already - it would touch the existing code only in two points. > True, but what's the point? It's a dead end, we can't extend it in any way. Or if we extend it, it will be again incompatible with Customizer. So the benefit is pretty limited to one specific solution. I'm sure that with a little more effort we can get a solution that will allow extension and integrates nicely with the parser. This opens the path for a huge list of interesting things. Yes, all that might take a while, like the text() feature is now at one year discussions and refinements and it's still not 100% finished yet. > Now lets look at the function style definition: xyz = select( name="your > parameter", default = 1.0, values = [ 10:2.0:30 ] ); > I think this one would be more intuitive for the user. But it would be much > more difficult to parse. Regular expressions won't do it here. This needs to > be processed by the lexer. Now the question is when and from where to invoke > the lexer? From the Parametric UI module after each change of the source in > the editor? I think this would be preferred as it would result in a 'snappy' > ui but what to do with syntax errors then? This definition is already > somewhat prone to syntax errors like mismatching brackets, typos, etc. > I don't see a big parsing problem here. The current parser could handle the syntax already. Picking out the values would be possible and the trigger could be the same as it is in your code. I see the problem that the user visible part is limiting it to just the variable assignment case and that it will pretend an interactive behavior that is simply not there. The function is _not_ called when evaluating the assignment, the function syntax is only used as container for meta data. > Then there is the annotation style. It might have benefits to do it this > way. I'm not seeing them atm but I haven't read through all issues on github > yet. So I might be missing something here. What I do see is the same > problematic as for the function style definitions. If you plan on rewriting > most of the code anyway then this might be the way to go I don't know. > Yes, it would need a small extension to the parser. But so did the list-comprehensions, and those are an awesome new feature. > Otherwise personally I probably would go with the customizer comment syntax > since that could be considered the standard right now and it's not a big > deal to implement. > In my completely personal view it's not a standard but an ugly hack that does serve a useful purpose and works reasonably well for that. Defining that as official language would make me sad as I don't see any way for it to evolve. ciao, Torsten.