You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The child objects of a soft key are not scaled according to "softkey-scalefactor", but scaled according to the "datamask-scalefactor". This leads to inconsistency when there is a great difference between the 2 scaling factors. E.g. when the datamask should be scaled by x2 and the soft key by x0.5. Then we'll end up with the contents of the soft key being four times the intended size.
This one could be tricky, because objects that are children of a key object can be children of things on the data mask also, so both approaches are incorrect, haha
This one could be tricky, because objects that are children of a key object can be children of things on the data mask also, so both approaches are incorrect, haha
Ahh dang, I see how that wouldn't work... We could make a copy of those objects with seperate id's and then that wouldn't be an issue... But that is rather complicated and has lots of other side effects that need to be considered with not much to gain I feel like :/
Any ideas welcome here, if the standard just left the scaling part to the VT server this all would be alot easier 😛. But they probably have good reasons to not do that I guess
This one could be tricky, because objects that are children of a key object can be children of things on the data mask also
Hmm, now that I think about it... I think, to make this all easier, we can set as a condition for auto-scaling that an object cannot be a child of a key mask and data mask. Otherwise we make life way too hard for this niche occurence
Describe the bug
The child objects of a soft key are not scaled according to "softkey-scalefactor", but scaled according to the "datamask-scalefactor". This leads to inconsistency when there is a great difference between the 2 scaling factors. E.g. when the datamask should be scaled by x2 and the soft key by x0.5. Then we'll end up with the contents of the soft key being four times the intended size.
Supporting Documentation
In this snippet we can see that it only checks whether the object is softkey when applying the "softkey-scalefactor":
https://github.com/ad3154/Isobus-plus-plus/blob/44a2941ca23f50f0a7ed07b4f74b460c91db0815/isobus/src/isobus_virtual_terminal_client.cpp#L3469-L3480
Possible solutions
These are my initial thoughts, but there could be better alternatives?
The text was updated successfully, but these errors were encountered: