Hello, Subject: Question about the future direction of the timing protocol decoder
I tend to get annoyed with the stock timing protocol decoder (PD). It sounds trivial - but its major problem is that it constructs annotations that are too wide - and the PD lacks (configuration) flexibility. >From within PulseView - with multiple values (timing and frequency plus their SI-units) concatenated into a single annotation row - user will have to zoom quite "deep" into the samples before the annotations gets so wide that all text/values of an annotation are visible. Sure - the "Times" row can be changed into one of its "terse" output modes - but that does not help the the width of the other concatenated rows (Averages and Deltas) Because of the above annoyances - I have over the years made multiple incarnations of the timing PD. Some of them are multipurpose timing PDs - displaying samples, time, freq, delta_time, delta_freq, avg_time, avg_freq in separate annotation rows (to keep the annotaions narrow) The multi-purpose timing PDs has config properties to hide/unhide and change units of every annotation row - highly flexible. Other mutations of the timing PD are single purpose PDs - where each of the above mentioned annotation rows are served by a separate PD - again the key is to keep the annotations narrow. Single- versus multi-purpose ? Both of the above approaches have each their advantages and/or disavdantages. With the multipurpose-purpose timing PDs - I need only to insert one timing PD and configure its properties once - that feels nice to me. With the single-purpose timing PDs - I find myself inserting and configuring lots of small single purpose timing PDs - which is a quite tedious work to do. Also as a programmer - it annoys me to know that the many single-purpose timing PD all do (almost) the same work - only the units are different (mostly). In other words it does not feel right that I need to execute multiple single-purpose timing PDs to do the work that the multi-purpose timing PD easily could do withing its existing execution context. As you can hear my favourite timing PD is the multi-purpose one :-) Right now the timing PD is somewhere in limbo between what I outline as multi-purpose and single-purpose timing PD. One annotation row (Times) is high customizable - the two others (Averages and Deltas) are not (and their concatenated contents are too wide in to be really useful - in my opinion) Personally I would like to see the stock timing PD evolve into somethimg more usable (and get rid of my local customizations that I carry from system to system) :-) What direction should future changes to the timing PD take ? Single- or multi-purpose ? - right now it is in a mixed state. What I'm really asking about here is - if I should begin to submit pull requests that: 1) extends the existing timing PD into a more configurable multi-purpose timing PD OR 2) splits the existing timing PD into smaller single-purpose PDs (for example separate PD for samples, timing, frequency - and their delta and average combinations (permutations)) PS: it is not my intention to offend anyone that has contributed to the existing timing PD - my intentions are only to improve the usefulness of "stock" sigrok in general. Thanks in advance Kind regards Uffe Jakobsen :-) -- Sent from: http://sigrok-devel.175694.n8.nabble.com/ _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
