Time Display Consistency

[BryanEnneking]

I propose making some minor changes, but want to get others' (particularly Francesco's) thoughts before I go making them.

In my own experience, I regularly match pre-wait and post-wait times to media timecodes. For this usecase it would be more convenient to view and edit wait times in HH:mm:ss.zzz format rather than just seconds. This format would also be more consistent with the corresponding Pre/Post wait columns in List Layout. I would like to make this UI change if it fits other people's uses. For compatibility, I would keep the underlying data in seconds.

Unfortunately, the QTimeEdit widget does not handle "z" or "zz" gracefully, so I propose using "zzz" (like Media Cue start and stop times.

Since Media Cue start and stop times have dots as separators for all sections, I propose changing the hour-minute and minute-second separators to colons in order to match.

Then there is the matter of accuracy. Currently, the cue settings page allows hundredths of seconds (two decimal digits) for pre-wait and post-wait times. However, the List Layout columns effectively only have tenths of seconds (the hundredths place has a constant zero). Is there some history or a reason behind this unused digit? My guess is that the original intent was to use the hundredths place, but it was changed for performance reasons. Is that right? I would be inclined to eliminate the zero altogether and just have tenths of seconds displayed.

To summarize, these are the changes I propose:

• Change pre-wait and post-wait in cue settings to QTimeEdit widgets with HH:mm:ss:zzz as the format. Internally, the data will still be seconds, but rounded to the millisecond.
• Change the format of Media Cue start and stop times to HH:mm:ss.zzz
• Change the strtime utility function to eliminate the constant zeros for accurate (and non-accurate?) time

I realize others may use things differently, so feel free to weigh in on whether you think this is a good idea or not.

[FrancescoCeruti]

I'm on board with the first two, we could also default the selection to the seconds, so if you use the +/- buttons that's what is incremented by default, it should be possible via the setSelectedSection method.

On the hundredths of seconds, the reason it's partially because of performance (the current refresh rate is 30Hz), but mostly it's because I find it distracting when looking at the running time, it also doesn't add much value while the cue is running. The extra "0" is there to keep the text symmetrical, to me, it looks a bit weird without. I think we can keep the current behavior.

[BryanEnneking]

Okay. I will go ahead and make the first two changes.

Regarding the hundredths place, I have a different idea that I believe will address your concerns as well as some of the points s0600204 brought up. Specifically, it might be helpful to handle rolling time differently from the duration that is statically displayed when the cue is not running. For the rolling time, I agree with you that the hundredths place is distracting (and it uses unnecessary CPU), so it should just be zero. However, when the duration is displayed, it should be accurate to the hundredths place because it's confusing to show .30 in the column if you specified .37 in the cue settings. I'm trying this out and it's actually a pretty simple change.

[FrancescoCeruti]

I agree that displaying the correct time when cue is not running is a good thing 👍

[s0600204]

I, too, vote for consistency across time edit widgets; and agree that using : as the separator between hours-minutes-seconds would be an improvement.

I will note that file duration and start/stop times are stored in show files as milliseconds, whilst fade-in/-out duration and pre-/post-wait are stored in seconds. (strtime expects milliseconds.)

Would it perhaps be possible to add an option somewhere for users to decide whether they wish to display the hundredths (or even thousandths) or not?

[BryanEnneking]

See my reply to Francesco. I think I have a solution that will address most of these concerns.

[FrancescoCeruti]

Implemented in #346