Bug 1216 - PV probably shouldn't sort any autogenerated UI elements
Summary: PV probably shouldn't sort any autogenerated UI elements
Alias: None
Product: PulseView
Classification: Unclassified
Component: UI (show other bugs)
Version: unreleased development snapshot
Hardware: All All
: Normal normal
Target Milestone: PulseView 0.6.0
Assignee: Nobody
Depends on:
Reported: 2018-06-03 20:01 CEST by Uwe Hermann
Modified: 2018-06-10 09:01 CEST (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Uwe Hermann 2018-06-03 20:01:02 CEST
Currently e.g. input/output module options seem to be alpha-sorted by PV in the respective dialogs. The same probably applies to other areas, like PD options, channel names, whatever (haven't checked, though).

IMHO this should not be sorted by the frontends, but rather the extact driver/module/PD ordering should be used in the UI dialogs.

That allows the driver/module/PD authors to pick a "useful" ordering that makes most sense for the specific driver/module/PD or use-case, which rarely will be the alpha-sorted one. Even if that were the case, the author can make it alpha-sorted in the driver/module/PD then.

Example: Some options might depend on each other, or be related somehow, and the author can use that and sort them in a way that makes sense (e.g. more important ones at the top, more optional ones lower; or group related ones together, etc).
Comment 1 Soeren Apel 2018-06-10 09:01:20 CEST
There is no sorting, however the C++ bindings (and also PV internally) use the std::map type to store the format options:

map<string, shared_ptr<Option>> InputFormat::options()
map<string, shared_ptr<Option>> OutputFormat::options()

maps store their entries in random order, so iterating over their contents to create the UI elements yields unpredictable results.

Fixing this bug requires a C++ binding API change, so postponed to the next libsigrok release.