Enumerated values for config options

Description of Patch

This patch improves the handling of config options which take a small number of values (like a C 'enum' type).

Many Motion options take integer values which correspond to a handful of settings, which the user has to remember or look up. Many of those have been changed to take string values; arbitrary strings are accepted and then converted to integer equivalents elsewhere in the code. This patch adds an optional table of integer/name mappings to each config option and extends the config parser and printer to use them.

• Simplifies code elsewhere in Motion since it only has to deal with validated integer options
• Errors in config files are detected early
• Users can still use either numeric or textual values (does not break old config files)
• Web interface renders fully-enumerated options as a popup button instead of a text field
• Easy to add new string options, new named values, or see what the valid strings are

Installation of Patch

Download the patch file. Then copy it to the motion source directory and issue the command (assuming the patch file is called enumoptions.patch)

patch < enumoptions.patch

Then re-build Motion and test the patch.

Change History of Patch

• 1.0 Initial version. Tested to apply on top of ConfigTweaks on svn rev 526, but should also work without ConfigTweaks.

Discussion and Comments

---

Almost all config settings today are simple values as plain text. I do not understand how this patch makes anything more user friendly. As I read the patch it just becomes more geeky.

I have not tried to apply the patch but as I understand it the config files would use geeky strings instead of human strings for most settings. I want Motion to remain a program for humans. And I want the config files to be in a human format.

We may have a few parameters where the values are geeky today and it may make sense to improve these. But I cannot understand why simple values like on and off should be replaced by geek strings.

I would need a lot of convincing arguments to accept this patch. It seems to be more targetted at making things more easy for the programmers than for the end users.

-- KennethLavrsen - 21 Mar 2011

---

Huh? No, it makes things easier for the users by replacing cryptic numbers by meaningful strings. In the case of parameters which are already strings, there is no change to the config file --- the strings are the same (I have no idea why you think the new strings are geekier than the old; they're the same text. In fact the boolean options (on and off) aren't touched by this patch at all.).

The advantages are that it makes the web UI easier to use --- if there are only a few valid possibilities for an option, you get a popup instead of having to type the exact right string (or a mysterious number) into a text field --- and of course it makes the code itself easier to deal with. (It could potentially help improve error messages when there's an error in the config file, since Motion will detect the error early instead of later, and would be able to say what the allowable options actually are.)

This patch was motivated by two things---

one, the v4l2_palette option which you used to have to look up a number in a table and enter that (essentially meaningless) number, now you can just enter the name of the pixel format

two, an earlier released version of Motion required cryptic numbers for a lot of options that can now be strings. Meanwhile, the development version took a different path towards allowing those config file entries to be strings, but the string-to-number code was scattered throughout the program. This patch keeps all the benefits of that but eliminates some of the code complexity it incurred (plus it makes the web UI less cryptic).

(And third, my local fork of Motion has some other string-valued config options and it was simpler to solve the problem once than to write ad-hoc string->number code a few more times. )

-- WimLewis - 24 Mar 2011

---

In that case I have not understood your change. I have not read your code in detail and I should not have to.

I agree that the palette numbers are silly and should be replaced. But I understood that you change much more than that.

Can you describe the exact change in human words the?

-- KennethLavrsen - 01 May 2011

---