1093- New Models useful for graphics section

[KRLango]

This is to add 2 new models that I am finding will be useful for the graphics section of the inspector work:

TuplePropertyElementModel - many of the graphics sizes and positions are stored in tuples, this model is to access a single element of that tuple and to update the tuple when the value is changed.

DisplayItemCalibratedValueModel - the sizes and positions of the graphics can be displayed in a number of different units and this model watched for the calibration to be changed to update the values in the UI

[cmeyer]

The problem you mentioned in chat was caused by the binding not keeping a reference to the source. This was a historical choice and I've changed it in nion-software/nionutils@f9ff65b.

I still show a couple tests failing.

Also, one minor change request I noted in the code: can you use double underscore for most private fields and callbacks? I recommend only using single underscore for protected fields, and even in that case I usually try not to expose the variable directly and instead provide a read-only property.

Example of method that will never be called in subclass and should be private (double underscore):
DisplayItemCalibrationValueModel._on_calibration_changed -> DisplayItemCalibrationValueModel.__on_calibration_changed

Example of field that should not be used in subclasses and should be private:
TuplePropertyElementModel._listener -> TuplePropertyElementModel.__listener.

By default I would make almost all fields private unless there is a compelling reason that a subclass needs access.

Once you make the private fields, let me know if you want me to merge or want to keep adding to this PR.

[cmeyer]

NOTE: you will want to merge from the main branch before pushing another PR, to get the numpy 2 changes, which are required to utilize the new nionutil changes. Or rebase and force push.

[KRLango]

Should be all good now. If possible I would like to get this one merged quickly as it will be useful with the Graphics Inspector section that I am currently working on.

[cmeyer]

Squashed and merged here f3e67d8

Thanks! This looks like a good approach going forward (using models instead of custom bindings). We may want to move TuplePropertyElementModel to nionutils.Model eventually, but let's keep it in nionswift until the inspector project is complete. I'd also rename it to TuplePropertyModel if we did that - is there a reason for the Element in there? (no need to answer here, just something to consider)

[KRLango]

@cmeyer the reason I put element in there was because the model was to access an element of the tuple property rather than the whole tuple.

[cmeyer]

Wouldn't it be called TupleElementPropertyModel then? I don't think there would be any ambiguity with just TuplePropertyModel since there isn't any difference between a "whole tuple property model" and just a "property model", but I guess I can kind of see the logic. But TuplePropertyElementModel just seems incorrect to me.