common.xml - remove display="bitmask" (#2215)#385
common.xml - remove display="bitmask" (#2215)#385hamishwillee wants to merge 1 commit intoArduPilot:masterfrom
Conversation
|
Not sure about that pymavlink change, @IamPete1 |
Definitely not - don't know how I picked that up. Will remove. |
hamishwillee
force-pushed
the
pr_pull_upstream_removal_bitmask
branch
from
d7405a6 to
d9dbe77
Compare
|
Done. |
|
This is out of sync. I can resolve conflicts, but loath to do it until I know it is going to be looked at. |
hamishwillee
force-pushed
the
pr_pull_upstream_removal_bitmask
branch
from
d9dbe77 to
3944817
Compare
hamishwillee
force-pushed
the
pr_pull_upstream_removal_bitmask
branch
from
a6641a9 to
cce1d51
Compare
| <message id="192" name="MAG_CAL_REPORT"> | ||
| <description>Reports results of completed compass calibration. Sent until MAG_CAL_ACK received.</description> | ||
| <field type="uint8_t" name="compass_id" instance="true">Compass being calibrated.</field> | ||
| <field type="uint8_t" name="cal_mask" display="bitmask">Bitmask of compasses being calibrated.</field> |
There was a problem hiding this comment.
This one should stay unless we can get a better display than a bitstring somehow
There was a problem hiding this comment.
As per #385 (comment) this makes sense provided you are happy that rendering would just be a group of un-labeled checkboxes?
| <field type="int32_t" name="lat" units="degE7">Latitude of SW corner of first grid</field> | ||
| <field type="int32_t" name="lon" units="degE7">Longitude of SW corner of first grid</field> | ||
| <field type="uint16_t" name="grid_spacing" units="m">Grid spacing</field> | ||
| <field type="uint64_t" name="mask" display="bitmask" print_format="0x%07x">Bitmask of requested 4x4 grids (row major 8x7 array of grids, 56 bits)</field> |
There was a problem hiding this comment.
This is useful displayed as a bitmask.
print format could do with fixing, 'though
There was a problem hiding this comment.
@peterbarker So as I understand it, you are using display="bitmask" to know that things are bitmasks and render as binary number rather than integer - right?
So that is the purpose of print_format="0x%07x". Why do we need the bitmask setting? That is true for all the other cases too - unless you're actually generating a non numeric UI?
There was a problem hiding this comment.
As I said somewhere else I think, the use of an enum tag to define a bitmask makes sense because the values you expect the bits to take are documented. You can therefore reasonable render a checkbox group UI for them with labels.
Whether or not you can reasonably generate a UI like that for something without an enum assignment using display="bitmask" depends on the data in the mask.
In this case a rendering as a checkbox group would be less than useful - and if you want to just format it as a number then print_format is the right approach.
For other cases it might make sense - i.e. I might reasonably use this to list a checkbox group for a button definition - and not show any labels.
But I'd say that you could only do that if you only apply it to cases where such a button definition makes sense.
So in other words, yes maybe, but not this one.
| <description>Message appropriate for high latency connections like Iridium</description> | ||
| <field type="uint8_t" name="base_mode" enum="MAV_MODE_FLAG">Bitmap of enabled system modes.</field> | ||
| <field type="uint32_t" name="custom_mode" display="bitmask">A bitfield for use for autopilot-specific flags.</field> | ||
| <field type="uint32_t" name="custom_mode">A bitfield for use for autopilot-specific flags.</field> |
There was a problem hiding this comment.
Agreed on this one - we shouldn't have copied that "bitfield for use for" thing from HEARTBEAT.
| <field type="uint32_t" name="timestamp" units="ms">Timestamp (milliseconds since boot or Unix epoch)</field> | ||
| <field type="uint8_t" name="type" enum="MAV_TYPE">Type of the MAV (quadrotor, helicopter, etc.)</field> | ||
| <field type="uint8_t" name="autopilot" enum="MAV_AUTOPILOT">Autopilot type / class. Use MAV_AUTOPILOT_INVALID for components that are not flight controllers.</field> | ||
| <field type="uint16_t" name="custom_mode" display="bitmask">A bitfield for use for autopilot-specific flags (2 byte version).</field> |
| <field type="uint32_t" name="time_boot_ms" units="ms">Timestamp (time since system boot).</field> | ||
| <field type="uint32_t" name="last_change_ms" units="ms">Time of last change of button state.</field> | ||
| <field type="uint8_t" name="state" display="bitmask">Bitmap for state of buttons.</field> | ||
| <field type="uint8_t" name="state">Bitmap for state of buttons.</field> |
There was a problem hiding this comment.
the attribute is very useful on this one
There was a problem hiding this comment.
As per #385 (comment) this makes sense provided you are happy that rendering would just be a group of un-labeled checkboxes?
| <message id="375" name="ACTUATOR_OUTPUT_STATUS"> | ||
| <description>The raw values of the actuator outputs (e.g. on Pixhawk, from MAIN, AUX ports). This message supersedes SERVO_OUTPUT_RAW.</description> | ||
| <field type="uint64_t" name="time_usec" units="us">Timestamp (since system boot).</field> | ||
| <field type="uint32_t" name="active" display="bitmask">Active outputs</field> |
There was a problem hiding this comment.
As per #385 (comment) this makes sense provided you are happy that rendering would just be a group of un-labeled checkboxes?
2 participants
This attempts to pull the upstream changes from mavlink#2215
It doesn't pull everything, because common.xml here is missing a lot of relevant changes.