In the past year (2013), I have noticed that U.S. TV programming seems to be adding more and more ads to almost all programs (except PBS).

In early 2013, it seemed to be the case that if I flipped through 10 channels, about 3 of 10 were showing advertising. Now, in early 2014, it seems that about 7 of 10 are showing ads.

I have become conditioned to grab the remote control and start 'channel surfing', whenever I hear the words "Stay with us" or "Stay tuned" or "We'll be right back" or "Don't go away".

The talking-heads don't seem to say "And now a word from our sponsors" anymore. They probably don't want to remind us of how much advertising they are going to dump onto us.

Nowadays, 'commercial segments' in a TV program are typically composed of about 4 to 12 individual ads.

The typical 'ads segment' is often split into TWO 'psuedo-segments' by an annuouncer saying something like 'Closed captioning is brought to you by' ... after about 6 ads are presented. Then another 4 to 6 ads are presented.

Who do they think they are kidding?

Out of frustration in hearing the same ads over-and-over, for

insurance

drugs

dating services

kitchen food-preparation products

home cleaning products

etc. etc.

none of which I am going to buy (especially now that they have wasted many, many hours of my life that I cannot get back), I decided to make a Tk GUI that facilitates gathering data on just how much time is being wasted on ads --- and to facilitate gathering data, over time, on 'advertising creep' --- and 'advertising creeps'.

I recently heard an older actor, who acted in situation comedies back in the 1970's, say that there were about 10 minutes of ads per hour in those days. I also recently heard, in an interview with a TV executive, that there are typically about 20 minutes of ads per hour nowadays.

So it is a known fact, by people 'in the biz', that there is much more advertsing per hour nowadays.

I wonder how soon we will have 30 minutes of ads per hour --- ON PAY CABLE TV CHANNELS. We are paying to be bombarded by all these ads!! (Watch your cable billing. There is cable-fee creep as well as ads creep.)

It is my hope the following Tk GUI may help in gathering data to support action, such as legislation or class-action suits, to put a stop to the 'ads creep'.

---

DESIGN OF THE GUI:

My first thoughts about the GUI concerned making it very easy to enter start and end times of 'ad segments'.

I decided to use 3 'scale' widgets --- to enter the hour:minute:second of the START of an 'ad segment' and to enter the END of the segment.

And below those 3 scale widgets, I envisioned having about 15 to 20 lines of START-time and END-time 'entry' widgets.

Since there are typically about 4 ad-segments per half-hour of programming ('content' plus ads), that means we need about 8 lines for an hour of programming --- and about 16 lines for a 2-hour movie.

I also wanted to have a 'Total' button, to generate the grand-total of advertising time.

I decided to show the Total time in the format 'mmm:ss' --- minutes and seconds --- no hours --- since, hopefully, we will generally not have more than about 60 minutes of ads, even in a long movie.

For the format in entering the START and END times, on the other hand, I wanted to make it easy to enter the times in an 'hh:mm:ss' format --- and allow the user to use 12-hour or 24-hour time specification.

To allow the user to specify AM, PM, or 24-hour (military/European) time, I decided to put 3 radiobuttons at the top of the GUI, over the 3 'scale' widgets.

I set to work making a GUI with these features, and I ended up with the GUI seen in the following image.

In the course of developing the GUI, I realized that I needed to add a 'Clear' button to the GUI --- so that the user can quickly clear all the entry fields (and fields showing calculated mmm:ss time data).

Also, besides the 'Total' button, I decided to add a 'Report' button --- to allow for generating a detailed report, listing all the start and end times for all the ad-segments --- as well as the grand total of my/our wasted time.

The 'Help' button on the GUI describes how to use the GUI. The following summary section from the Help text outlines the 'workflow'.

TYPICAL SEQUENCE OF OPERATIONS:

1) Set a radiobutton on the left of the 'ad-segment line' in which you want to make a start-time or end-time entry.

2) Check the AM/PM/24 radiobuttons at the top of the GUI to see if they are set according to the way you want to enter the time.

3) Set the hour, minute, second sliders to the time that you want to enter.

4) Click on the 'EnterStartTime' or 'EnterEndTime' button to transfer the time setting from the 3 scale widgets to an entry field on the 'ad-segment line' that you have selected.

5) Continue using steps 1 through 4 to enter start and end times for the ad segments in a TV program.

6) When finished entering start and end times, click on the 'Total-All-Ads' button to show a total time, beside the 'Total-All-Ads' button.

Use the 'Report' button for a more detailed report.

The code

Below, I provide the Tk script code for this 'tkAdsAdder' utility.

I follow my usual 'canonical' structure for Tk code for this Tk script:

0) Set general window & widget parms (win-name, win-position,
win-color-scheme, fonts, widget-geometry-parms, win-size-control,
text-array-for-labels-etc).
1a) Define ALL frames (and sub-frames, if any).
1b) Pack ALL frames and sub-frames.
2) Define & pack all widgets in the frames, frame by frame.
Within each frame, define ALL the widgets.
Then pack the widgets.
3) Define keyboard and mouse/touchpad/touch-sensitive-screen action
BINDINGS, if needed.
4) Define PROCS, if needed.
5) Additional GUI initialization (typically with one or more of
the procs), if needed.

This structure makes it easy for me to find code sections --- while generating and testing a Tk script, and when looking for code snippets to include in other scripts (code re-use).

I call your attention to step-zero. One thing that I started doing in mid-2013 is using a text-array for text in labels, buttons, and other widgets in the GUI. This can make it easier for people to internationalize my scripts. I will be using a text-array like this in most of my scripts in the future.

Experimenting with the GUI

As in all my scripts that use the 'pack' geometry manager (which is all of my 100-plus scripts, so far), I provide the four main pack parameters --- '-side', '-anchor', '-fill', '-expand' --- on all of the 'pack' commands for the frames and widgets.

That helps me when I am initially testing the behavior of a GUI (the various widgets within it) as I resize the main window.

In this particular GUI, I allowed the user to resize the window.

However, one could un-comment the statement

wm resizable . 0 0

and then the user would not be able to change the size of the window from its initially built size.

With the window resizable, you can experiment with the '-side', '-anchor', '-fill', and '-expand' parameters on the 'pack' commands for the various frames and widgets --- to get the widget behavior that you want as the window is resized.

Actually, I fixed the y-size of the window, but allowed the x-size to vary, with the statement:

wm resizable . 1 0

___

Additional experimentation: You might want to change the fonts used for the various GUI widgets. For example, you could change '-weight' from 'bold' to 'normal' --- or '-slant' from 'roman' to 'italic'. Or change font families.

In fact, you may NEED to change the font families, because the families I used may not be available on your computer --- and the default font that the 'wish' interpreter chooses may not be very pleasing.

I use variables to set geometry parameters of widgets --- parameters such as border-widths and padding. And I have included the '-relief' parameter on the definitions of frames and widgets. Feel free to experiment with those 'appearance' parameters as well.

Some features in the code

That said, here's the code --- with plenty of comments to describe what most of the code-sections are doing.

You can look at the top of the PROCS section of the code to see a list of the procs used in this script, along with brief descriptions of how they are called and what they do.

The main procs are simply

'enterStartTime_fromScales' - called by the 'EnterStartTime' button.
'enterEndTime_fromScales' - called by the 'EnterEndTime' button.
'calcSEGlength_mmmss' - called by the 2 procs above, if
both entries in the current line are
available.
'clear_all' - called by the 'ClearAll' button.
Clears all the start & end 'entry' fields
and the seg-length and total 'text' fields.
'total_all_ads' - called by the 'Total-All-Ads' button.
'Report' - called by the 'Report' button.
'popup_msg_var_scroll' - called by the 'Help' and 'Report' buttons.

---

One rather unique thing about this GUI is that whenever the user clicks on the AM/PM/24-hour radiobuttons, the '-from' and '-to' parameters of the HOURS scale widget is set to 1-and-12 or 0-and-23.

This is the first time I have ever found a need to allow for changing the max and min values of a 'scale' widget. You can see how easily that was accomplished by looking at the 'BINDINGS section' of the code.

It is my hope that the copious comments in the code will help Tcl-Tk coding 'newbies' get started in making GUI's like this.

Without the comments, potential young Tcler's might be tempted to return to their iPhones and iPads and iPods --- to watch videos that are often prefixed by unavoidable ads. (They're everywhere!)

I have tried to make it a bit difficult for the user to accidentally wipe out some previously entered data for an ad-segment while trying to enter some data for a new ad-segment.

When both the START and the END times are entered on a line, the LENGTH of that ad-segment is calculated and shown. Also, at that time, the ad-segment radiobutton setting is advanced a line so that the user is unlikely to wipe out data on previously entered lines.

However, it may still be the case that the user can accidentally wipe out data. If that proves to be a problem, a warning popup could appear, whenever the user clicks on the 'EnterStartTime' or 'EnterEndTime' buttons and there is already Start or End time data on the 'currently active' line (as indicated by the radiobuttons at the start of the lines).

I plan to be using this GUI in coming months, so if data-wipeout turns out to be a problem, I may add warning-popup logic to the code and replace the code here.

---

Subtraction Logic - Lurking Bugs?

There is special arithmetic processing involved in dealing with situations when the Start-time is being subtracted from the End-time --- such as when Start-seconds are greater than End-seconds.

In that case, the End-seconds are augmented by 60 seconds and a minute is deducted from the End-minutes.

There may be a situation like that that I have not anticipated.

In coming months of using this utility, if I discover a case like that that needs some special logic added, I will add the logic and replace the code here.

IN CONCLUSION

It makes me smile that I can use Tcl-Tk to make GUI utilities like this --- utilities that make a tedious task much easier. This utility can perform all that subtraction and totalling up (with carrying operations between seconds and minutes and hours) in a fraction of a second --- compared to my multiple minutes for 'manual' recording and calculation. Hundreds of times faster.

As I have said on quite a few other code-donation pages on this wiki ...

There's a lot to like about a utility that is 'free freedom' --- that is, no-cost and open-source so that you can modify/enhance/fix it without having to wait for someone else to do it for you (which may be never).

A BIG THANK YOU to Ousterhout for starting Tcl-Tk, and a BIG THANK YOU to the Tcl-Tk developers and maintainers who have kept the simply MAH-velous 'wish' interpreter going.

"In coming months of using this utility, if I discover a case ... that needs some special logic added, I will add the logic and replace the code here."

In fact, on a first test of this utility (after not looking at it in the month after publishing the code), not only did I find a bug (an 'invalid octal number' error), but I found some confusion in using the utility because the 'Start:' and 'End:' labels looked like buttons, since I used '-relief raised' to make those labels.

I found that I needed to change the relief of those labels so that they do not look like 'button' widgets --- to be clicked upon.

The new look of the GUI is seen in the following image.

I made the following changes to the code and replaced the code above with the new code.

1) I used 'scan' with '%d' to convert some hh:mm:ss text data to decimal --- to avoid 'invalid octal number' errors when trying to do arithmentic with '08' and '09'.

2) I made logic changes so that times between midnight and 1AM show as 00 hours, rather than 24 --- in the start-and-end entry fields.

3) I added 'RELIEF_label_lo' and 'RELIEF_numtext' and 'RELIEF_radbutt_hi' variables --- to be able to easily set the relief of some of the 'label', 'text', and 'radiobutton' widgets --- so that 'label' and 'text' widgets do NOT look like 'button' widgets (which they did when they were hard-coded to be 'raised') --- and so that 'radiobutton' widgets stand out as buttons to be clicked-upon.

An Alternative design (proposed by RLE)

RLE (2014-03-10): This is an interesting concept, but I think you might consider a radically simplified GUI if your plan is to utilize this GUI while actually watching a TV show. My reason is that the time it will take to use sliders to pick a start and end time will rapidly result in one getting tired of collecting the data, or result in one missing a few minutes of the show when it returns to the air after the ad. break.

The "really big start stop button" (RBB) would begin with a label of "Start" or "Segment Start" or "Commercial Start", whatever is appropriate. Pressing the button causes the code to capture a clock seconds value (a begin value) and store it away somewhere.

Once pressed, the button label would toggle to say "Stop" or "End of Segment" or "End of Commercials", whatever is appropriate. Pressing it again would capture a second clock seconds value (an end value).

Now, with a begin and end value, you can do several things:

Compute a duration by subtracting the end from the begin value and using clock format to format a human readable MM:SS value for the text widget log. By using Tcl clock seconds values you avoid having an end prior to a begin, and have no need for [scan %d] to remove leading zeros.

Internally store the raw clock seconds values as a list of lists (lappend data [ list $begin $end ]). This internal list of lists can be what you save to disk, by simply puts'ing the list to an open file. As it contains all the data you can use it to recreate the human readable log lines at any time by simply iterating across it, subtracting, and clock formating.

The advantages you get are:

Easy to use while watching tv. As long as the mouse cursor is over the RBB, you just have to hit the mouse button at the start, and again at the end, of the commercial breaks. No need to spend time adjusting sliders to wall clock values, let Tcl handle the "what time is it now" factor internally. If you are using a laptop with a touchpad, then tracking might be as easy as just tapping the pad once at both boundaries.

Avoidance of math errors from odd data entry values. The worst case is a zero difference, and then only if you click the button twice within the same second of time. Otherwise the end value will always be later than the start value.

A compact save format. It just stores the raw clock values. No need to save the human readable elements when they can be regenerated. Plus the save format is suitable to being combined with other saved files into larger totals over days/weeks of time.

Very easy totaling. Just iterate the internal list, subtract the two sub-list elements, and accumulate a total. If you are using tcl 8.6 totaling the list would likely be a one line lmap operation.

Nice idea. Why don't you code it up and start a new page for it. (This one is getting pretty long.) It's your idea. I don't want to steal it.

(If you have not coded it up by 2015 March, is it OK if I provide a version --- if I am still around then? In the meantime, I have about 100 scripts on my 'to-do' list to keep me busy --- as seen on my 'bio' page at uniquename.)

By the way, I don't find the scales very hard to use --- especially since changing to the next time (a start or end time) usually means just clicking on one side (often the right side) of the 'slider button' and holding mouse-button-1 down to quickly advance the slider. I usually have to do that on just the minutes and seconds sliders --- not the hour.

Besides, this approach works even for those people who never set the proper date and time on their computers --- which seems to happen pretty frequently judging from emails that I have seen with totally erroneous years in their Sent-Times (not to mention the month, day, and time-of-day).

---

RLE (2013-03-14): I might, provided I find time to do so. I'm fine if you want to code up a version as well.

You are quite correct, I am assuming a correctly set computer clock. But as I've kept all my computers slaved to NTP internet time for 10+ years now, I've long since forgotten about having a computer clock that is out of sync with real time.

---

uniquename 2014mar16: I won't be coding your design anytime soon. You are making another assumption. You are assuming that the user will never accidentally make an erroneous click. If you assume that, it would be like proceeding to make a database application that only does 'adds' --- but no 'changes' or 'deletes' --- the other two crucial operations needed for a database system.

To me, the time-consuming part would be in designing and coding a nice way for the user to apply 'changes' and 'deletes' to that 'internal list' that you mention.