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.

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.

Edited by user 12 November 2024 07:01:47(UTC)  | Reason: Not specified

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.

Edited by user 12 November 2024 08:57:15(UTC)  | Reason: Not specified

https://en.smath.com/forum/yaf_p...ot-Region.aspx#post86081

@Davide,

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

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

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.

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 (8kb) downloaded 17 time(s).
xyplot-drawimage-tag.sm (68kb) downloaded 18 time(s).
xyplot-drawimage-mat.sm (9kb) downloaded 17 time(s).
xyplot-drawimage-mat-rgb.sm (19kb) downloaded 14 time(s).

Edited by user 17 November 2024 04:21:32(UTC)  | Reason: Not specified

Plugin updated.

Changes:

- fixed filling for lines.

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.

Edited by user 18 November 2024 09:39:50(UTC)  | Reason: Not specified

Plugin updated.

Changes:

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

Edited by user 18 November 2024 21:00:58(UTC)  | Reason: Not specified