Module Labels

[shookie]

It would be nice if it was possible to label modules, i.e. if the name of the modules would pop up as a tooltip if you mouse over it in the preview window.

An additional view option would be "Show Labels" to show them all the time.

And as a final iteration, it would be nice if you could define arbitrary strings for the label.

Define a builtion $label variable for modules that can be set as a default parameter to a module or within the module as an assignment, but also can be given as a parameter on instantiation to overwrite the default.

It may be beneficial to be able to export those labels into the export formats too.

Keep up the good work. But labels and bezier curves is what I miss most so far working with openSCAD.

Regards

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[kintel]

Having an optional string label per instance would be interesting.
Note: It shouldn't be a $-variable as those have a special meaning in OpenSCAD (dynamic scope).
We could just use label=, e.g. MyModule(label="mylabel");
This would, however, potentially shadow user parameters. We could introduce a different syntax for built-in parameters, alternatively a different syntax altogether for labels:

MyModule(__label__ = "mylabel");
MyModule<mylabel>();
mylabel: MyModule();

etc.

This sounds a bit like a discussion for OpenSCAD2. @doug-moen did this ever cross you mind?

[t-paul]

Even more meta-data like discussed in #722 :-).

[doug-moen]

In OpenSCAD2, "objects" are a general mechanism for associating metadata
with geometric shapes and "module instances". An object contains a set of
named fields, and a list of shapes. So a "label" would be just another
named field. It wouldn't need special treatment in the language, there
would just be a naming convention that people would agree to use. OpenSCAD2
doesn't care if the agreed name is 'label' or '$label' or 'label'.

An object literal has the syntax { ...statements... }, where each statement
is either a geometry statement, or a definition that adds a new name/value
pair. So you could write:
{ label="mylabel"; cube(10); }
and you've got a labelled cube.

If you are calling a module M that returns an unlabelled object, and you
want to add a label to that object, then you could write:
M() overlay { label="mylabel"; }
Here, 'overlay' is an infix binary operator that extends the object on the
left with some additional fields specified by the object on the right,
returning a new object. If 'label' is already defined within M(), then it
is overridden with the new value "mylabel".

On 15 November 2015 at 02:06, Marius Kintel notifications@github.com
wrote:

Having an optional string label per instance would be interesting.
Note: It shouldn't be a $-variable as those have a special meaning in
OpenSCAD (dynamic scope).
We could just use label=, e.g. MyModule(label="mylabel");
This would, however, potentially shadow user parameters. We could
introduce a different syntax for built-in parameters, alternatively a
different syntax altogether for labels:

MyModule(label = "mylabel");
MyModule();
mylabel: MyModule();

etc.

This sounds a bit like a discussion for OpenSCAD2. @doug-moen
https://github.com/doug-moen did this ever cross you mind?

—
Reply to this email directly or view it on GitHub
#1450 (comment).

[doug-moen]

I looked for documentation on the syntax of customizer annotations. All that I've found so far is this example: https://github.com/openscad/openscad/blob/model-meta-data3/examples/Parametric/sign.scad How this fits in to OpenSCAD2 is that name/value pairs within an object can have customizer annotations. For example, here's an object literal: { @description("Height of the cube") @parameter([1 : 10]) height = 5; cube(height); }

[doug-moen]

I said "OpenSCAD2 doesn't care if the agreed name is 'label' or '$label' or 'label'."
Almost true. OpenSCAD2 treats names beginning with _ specially in one case: they aren't exported from libraries via the 'use' operator. Although I don't know why you would label a library, it might make more sense to use '_label'.

I showed how to use the 'overlay' operator to add a label to a geometric object. As an alternative, we could wrap that up inside a 'label' function, which would add label metadata data to a geometric object:

     label(x)(y) = y overlay {_label = x};
     label("mylabel") cube(10);

This is just like the syntax for adding color metadata to a shape.

[t-paul]

I've collected some use cases there: https://github.com/openscad/openscad/wiki/Meta-Data-Use-Cases

Main point of meta data is that it's not evaluated by the script itself, but by some code in the OpenSCAD application itself (or maybe later by some kind of plugin).

[doug-moen]

In OpenSCAD2, meta data is evaluated by the script itself, can be queried
at run time by the script (this is an important feature), and is available
in the CSG tree for use by the OpenSCAD application itself, or by some sort
of plugin.

Bill of materials is quite easy to do in OpenSCAD2 using object metadata.

On 15 November 2015 at 14:10, Torsten Paul notifications@github.com wrote:

I've collected some use cases there:
https://github.com/openscad/openscad/wiki/Meta-Data-Use-Cases

Main point of meta data is that it's not evaluated by the script itself,
but by some code in the OpenSCAD application itself (or maybe later by some
kind of plugin).

—
Reply to this email directly or view it on GitHub
#1450 (comment).