There's no better option than having choices.

Procrustes solution must be banned:

https://en.wikipedia.org/wiki/Procrustes ...

You should understand that the flexibility of implementation (the ability to choose) is limited by future compatibility. It's like in the structure of DNA - you drag all the garbage of evolution along with you and must support it. Each new "mutation" of the component must be compatible or include all the previous ones, so as not to break thousands of documents. This is especially true for the appearance, which must always be unambiguously restored from the saved document.
You can now use the UseDefault property, but when transferring a document to another user who doesn't have a new version of the component or doesn't want to install it, the appearance should not change much. The other user will not see your settings, because the old version of the plugin doesn't know anything about it.

You should understand that your request to restore the standard behavior of the component will break the appearance of already created documents. I think about this for you, but next time you should also imagine how your preferences will affect thousands of already created documents. I showed examples above.

So freedom of choice is to allow many users to work as they are used to and not break their work, ensuring compatibility in both directions. This is a difficult task. That is why I sometimes refuse to make changes, because the overall picture of the consequences may not be clear and require significant research.

Right,
Compatibility - great feature and hard task. Thanks to Andrey and to all the developers.

While talking about freedom, what about the creation of a user’s function totally encapsulated. This must be simpler than the graphical tools (?)…
This could produce “happiness” to more than one…

Have a nice day.

Wrote

While talking about freedom, what about the creation of a user’s function totally encapsulated. This must be simpler than the graphical tools (?)…
This could produce “happiness” to more than one…

Have a nice day.

I don't think it is completely possible plugin-side, as there is no direct connection with the evaluation operator (I.e. a sandbox(...) function on the RHS won't be able to connect to the arguments of a function on the LHS); also I'm not sure you can keep sealed the assignments from the global context without some very strict rule.

Wrote

I imagine that there are many peoples annoyed to perpetually decorate the local variable with @; #; $ etc.

It's a safe approach but it's not really needed since the introduction of the built-in Clear() function. You can place a Clear(all_variables_I_want_local_used_in_the_function) and you are done; it's also very similar to declaring the local variables before using them.

Plugin updated.

Changes:

- added support for copying a set of properties.

The following properties are not currently supported: Name, Points, Traces.

The property set contains the current values ​​of the component settings. They can be used as a template. To control the component, they must be located above it in the document.

File not found. File not found.

https://en.smath.com/forum/yaf_postsm86081_X-Y-Plot-Region.aspx#post86081

@Davide,

I also use Clear, but, IMHO, the use of Clear can destroy values useful later.

Plugin updated.

Changes:

- added support for copying a set of properties (Points, Traces#n).

The following property is not supported: XYPlot.Name. This is for safety.

The property set contains the current values ​​of the component settings. They can be used as a template. To control the component, they must be located above it in the document.

When copying the properties of a curve, the component name must be corrected by yourself, since it is equal to "XYPlot". It's hard to automate this part.

File not found. File not found.

Should we assume these new Copy options are not working on linux?

Wrote

Should we assume these new Copy options are not working on linux?

Should work under Linux, I can't check.

This is not a new feature, but a feature that has been used for some time to manage the component. The copy feature was added to avoid having to remember the full names of the component properties.

Yes, now I see, everything is different in Mono. I haven't launched the program in Linux for a long time.
There needs to be some research done here to find out why Linux is so bad.

Copying doesn't work, but managing component properties does.

Plugin updated.

Changes:

- fixed the problem with drawing images;
- some demo examples are inserted from looped lists, these examples are separated from constant ones.

xyplot-drawimage-file.sm (7 KiB) downloaded 43 time(s).
xyplot-drawimage-tag.sm (67 KiB) downloaded 42 time(s).
xyplot-drawimage-mat.sm (8 KiB) downloaded 44 time(s).
xyplot-drawimage-mat-rgb.sm (18 KiB) downloaded 40 time(s).

Plugin updated. Experimental build

Changes:

- added fill properties for LineStyle.

Plugin updated.

Changes:

- fixed filling for lines.

Plugin updated.

Changes:

- filling support expanded.

Plugin updated.

Changes:

- added hatch properties for LineStyle.

I will probably move the filling into a separate property (FillStyle). So do not rush to publish documents with new properties.

Some Basic Image Manipulations.



Image-Basic.pdf (3 MiB) downloaded 26 time(s).

Image-Basic.sm (2 MiB) downloaded 37 time(s).

Best regards.
Alvaro.

Plugin updated.

Changes:

- fixed hatch with disabled filling (transparent background is used).