Run-time "options"/configuration

Hi,

I'm trying to come up with an *intuitive* way of handling "options" as they pertain to run-time operation of "programs".

E.g., in a command-line driven environment, these would be "switches" specified on the command line which would follow the "program name" ("dir /AH /B", 'find . -NAME "*" -PRINT', etc.).

In a GUI environment, they would be checkboxes, radio buttons, listbox selections, etc.

There are several issues that are interrelated.

First, defining the "default" options and conveying those to the user. In a GUI, this could simply be "whatever the controls/widgets *appear* to indicate when you initially open the dialog". In a CLI, usage() can be crafted (by convention) to disclose the default "switches".

Second, differentiating these defaults from the user's "preferences". Depending on the application, it is likely that the "system defaults" are inappropriate for every user's needs. This could involve automatically

*loading* the user's preferences in much the same way as the system "defaults" are "loaded" (e.g., ENVARs and .rc files for CLI's; "registry settings" for GUI)

Third, handling the persistence of those preferences. Each invocation can resort to some preset configuration which might reflect the *last* (previous) invocation, the user's preferences *or* the system defaults. Of course, there is also the possibility of "named configurations" (i.e., templates) -- and the whole issue of defining those.

Finally, the interrelationships of options is, perhaps, the trickiest to convey to the user. I.e., making him realize the "consequences" of particular option choices. The 1960's approach is to just squawk after the user has chosen some "unsupported" combination of options. In a GUI, you could automatically adjust *other* options consequential to particular choices as they are made (and hope the user notices these changes!).

[This has a significant impact on how templates are supported and maintained!]

A more sinister aspect of this is ensuring that all the affected options are *visible* to the user. I.e., if an option on a different "page/dialog" is changed as a result of a selection made on *this* page/dialog, the user's attention must be drawn to that other page/dialog.

[E.g., imagine changing the "output file type" for an application and then having a whole slew of options PERTINENT TO THAT FILE TYPE that need to be addressed... often on a separate dialog/page that you have to manually explore]

The simple solution to this mess is just not to give the user any choices! :> The next less-mindless solution is to only have "system defaults" and force these to be restored each time the "application" is invoked. (Nero takes this approach -- making it far more tedious to use than it *should* be!)

For infrequently used applications, I think simple/mindless solutions are (marginally) acceptable. The user doesn't have to remember *why* he may have changed a particular option from its "system default". OTOH, it may be expensive for him to rediscover why that change *is* desired (arguing in favor of restoring user preferences).

But, for things that are used *heavily*, it seems that you really want/need a means of letting the user quickly and reliably getting to the particular option set that he wants

*without* having to study a series of dialogs, option pages, etc. (This is especially important of conveying the current settings to the user is an "expensive" operation -- remember, these aren't desktop applications!)

I'd appreciate pointers to any applications that seem to have addressed this sort of issue successfully. And, any suggestions as to other ways that might improve on this sort of thing!

Thx!

Reply to
Don Y
Loading thread data ...

Le 09/05/2012 22:05, Don Y a écrit :

I don't know how far you want to go with that.

I once worked in a company where we made substations remote units (RTUs). There were 4000 digital inputs,

2000 digital outputs and analog inputs and outputs. Each data point had some 20 settings, we used a database to configure the device, that was a specific application running on a PC and generating a binary object that was linked with the program.

On the other hand I made applications requiring a few user settings that went into an XML file that was edited manually with a text editor or with the use of a small GUI. The settings must ge grouped logically, i.e. related options in a "box".

I don't know if that answers your question.

Reply to
Lanarcam

I would assume those were more "configuration" choices. I.e., naming each input/output as to the particular field sensor/actuator to which it was attached, setting the gains/ranges of particular I/O's, etc.

I'm more interested in any "options" that the user might alter *after* this configuration stage. E.g., setting the "speed" that a motor might slew a mechanism at (within the constraints set by your CONFIGURATION). Or, setting the position to which the mechanism would be moved. Or, setting how many "units" would be produced before the process is terminated. Or...

Yes. Akin to how most "dialogs" present options to a user.

Imagine setting the exposure time of an X-ray. Or, the "volume" of a media player.

The X-ray probably wants to have a "default" of "not yet specified" (meaning, "you must take some conscious action to set a particular exposure before I will allow the emitter to be engaged... there is No 'safe value' for this setting!").

OTOH, the media player's volume might want to be "whatever it was LEFT AT last time". Or, dependent on the type of media being played, etc.

Reply to
Don Y

Start by reading some documentation about how it is done by other programs. There are two main methods - ad hoc, which is okay for simple systems, or using libraries that implement general command-line argument parsers.

Here are some links to the Python standard libraries for command-line argument parsing. You probably won't be using Python (although it is a good choice of language for PC programming, and this sort of stuff is vastly easier in Python than C), but maybe you can learn some of the ideas from here.

getopt is a simple library following the same style as the well-known C getopt() function:

optparse is a more powerful (and more "pythonic") library, handling positional options, optional/required options, automatic help text, etc.

argparse is a new library with even more features, covering lists of arguments, conditional arguments, etc.

Reply to
David Brown

Mmm... I also worked for a company that made RTUs for power substations. Usually, the "configuration" parameters were stored in EPROM. So, they were changed as less as possible. Then FLASH was invented, and with it, the possibility to change the parameters more often.

But what you name "options" we treated them as set / command values, that where issued by the operator whenever he wanted them to change. Those values were (are) typically stored in NVRAM, and remained operative "forever", even after hot re-boots (but not after a cold re-boot, which was issued whenever the "configuration" was changed).

What I'm trying to say is that those "options" (with the added management of sensible combinations, named groups of preferred values, etc.) where really managed by other device (the operator's terminal), not by the RTU itself. And that device was a PC or a workstation, not an embedded device.

So they're out of scope in this group :-)

--
Saludos.
Ignacio G.T.
Reply to
Ignacio G.T.

Persistence of options is fine for GUI applications with two caveats:

a)In any output produced by the application, it should indicate clearly what options were selected. This way, the application's behavior can be reproduced.

b)There should be a "restore defaults" or similar button so that a user can get back to defaults if he wishes.

Persistence of options is NEVER fine for command-line applications. Each and every invocation of the program with the same command-line options or lack of command-line options has to provide the same results. There can't be any persistent state.

As with GUI applications, including the option settings in the output is advisable so that the program's behavior can be reproduced.

If the options selections are complex, a configuration file or command file or something similar is fine, but again the options selected there have to be indicated in the output so the output and/or behavior can be reproduced.

DTA

Reply to
David T. Ashley

For the first RTUs I made, the settings were stored in "bubble memory", that was in 1984. We could use them like flash today but they could also be organized along sectors to mimic disks.

"It was the rage: bubble memory?an invention that promised to replace the hard disk. Invented by Bell Labs in the 1970s, it was commercialized by Intel, and heavily marketed in the early 1980s as the ultimate answer for microcomputer memory storage.

Bubble memory would replace the hard disk, said its proponents. Not only would it retain its memory after the computer had been turned off, unlike Dynamic Random Access Memory (DRAM) chips, but it wouldn?t have any moving parts."

formatting link

We later used for the next RTU battery backed up SRAM (1991). Flash only appeared several years later.

Reply to
Lanarcam

Ad hoc isn't a solution. It's a *problem*. It's too easy for people to get lazy and "inept" and implement poor interfaces if there is no framework in which they will operate.

I'm already familiar with getopt(3) -- as just about anyone who's had to maintain FOSS would be :>

These seem largely to provide the same *sort* of functionality that getopt(3) does.

None, however, deal with anything more than the "system defaults" issue that I raised.

For example (ignoring GUI issues, here), none have made the obvious (?) decision to allow specific, named ENVARs to supply the "user default" values for individual switches/options (IMO, a trivial extension to any of the above). Conceptually, this would cause the "system default" value for the option in question to be overridden with the contents of the ENVAR named *for* that specific option -- prior to parsing the actual command line for even *more* specific overrides. I.e., (pseudocode):

commandline.options = parseoptions();

if (option.system_default != nil) { option.value = option.system_default; } if (option.envar_name != nil) { option.value = getenv(option.envar_name); } if (commandline.options.option != nil) { option.value = commandline.options.option; }

// repeat for all options ...

// test if current option suite makes sense ...

Nor have any added support for .rc files (which could provide a more persistent mechanism for holding user preferences, "templates" and "most recent usage").

Granted, one could source a suitable script to set ENVARs from some persistent medium. Or, source the contents of a "command line extension" (i.e., read command line from file).

Though you would still need a mechanism to allow those persistent stores to be updated from the *current* settings for the command's invocation (e.g., to implement a "most recent usage" mechanism). Something like:

command -use_rc_file= \ -update_rc_file= \

Finally, none of the getopt()-ish tools make any significant provisions for handling even trivial option interactions. Sure, "--long" and "--short" can be marked as mutually exclusive (though how/when you complain about this to the user is debatable -- what if an ENVAR specifies "--long" and the command line specifies "--short"?).

But, how do you deal with more complex interactions? E.g., partition_disk -parta=123 -partb=456 -partc=789 when the total number of partition units available is less than 123+456+789?

Or, in a more appropriate example, setting the operating conditions for a programmable power supply that is *power* limited: if ( (volts*amps > POWER_MAX) || (volts > VOLTS_MAX) || (amps > AMPS_MAX) ) { // bad combination of options }

Of course, there are other cases where this sort of non-trivial interaction comes into play. For example, the speed at which a mechanism can be slewed depends on the mass that it is moving at the time. Or, the precision with which it can be moved can be dependant on the speed at which it is moving. The resolution of a sensor can vary inversely with the range it supports, etc.

Conveying these constraints to the user is another issue. I.e., assuming POWER_MAX is 50, in response to: set_power_supply -volts=10 -amps=8 which do you emit: "amps setting too high" "volts setting too high" "too much power requested" And, if you actually want to *help* the user (instead of chiding him on his mistake), wouldn't you want to issue messages more like: "amps must not exceed 5" "volts must not exceed 6.25" "power must not exceed 50" or similar?

Remember, I'm not *just* talking about CLI's but also GUIs! There, it seems lazy *not* to update the choices available to the user *interactively* as his/her requirements are communicated to the application (via a dialog, etc.).

For simple relationships (e.g., --long vs. --short), this is implicitly conveyed with an appropriate choice of GUI widget -- perhaps a set of radio buttons to convey the "one_or_the_other"-ness of these settings. For more complex relationships, certain dynamics are required: e.g., as the "volts (amps)" dial is increased, the range of valid "amps (volts)" values could be updated so the user sees that he is trading one against the other.

[this is how I currently do things. But, it involves specific coding for each set of constraints -- something that I consider too easily prone to error (and in a very visible way!)]

But, even this approach isn't without flaws. It relies on the user being able to understand/internalize the interrelationships between options/settings -- based on "control (widget) behaviors" that he may not notice (or comprehend).

E.g., if the amps knob is currently set at 8, the volts knob will show a max limit of 6.25. Do you *prevent* the volts knob from being increased above this value? (if so, then the user has to pause to think: "How do I get the machine to let me increase volts *above* 6.25? What other setting is interfering with my goal?") Or, do you allow the user to set the volts knob as desired and (silently?) adjust the amps setting downward? (What if he then turns the volts setting back down? Does the amps setting climb back to it's previous value??)

[Think about actually *using* those controls and the sorts of things that might "surprise" you. I've been victimized by Windows apps that changed certain settings (that I had already *specified*) as a consequence of some other option choice -- relying on me to *notice* this fact -- even though the changed setting was on a different display page!]

Imagine how this works when you have more than two settings related to each other. E.g., screen resolution and color depth. And, frame rate.

The interrelationship between the two components of screen "resolution" -- height and width -- mimics that of the "power" relationship, above. I.e., for a given aspect ratio, specifying one of these parameters effectively specifies the other.

Tying color depth in can have a similar, but subtler, relationship. E.g., if the GDU is bandwidth limited, then resolution*depth*frame rate must not exceed some constant. So, increasing the size of the displayed image can cause the color depth choices to be reduced. Or, frame rate.

[Note that MS has *one* way of approaching this problem]

Email from a colleague with knowledge of the environment I'm coding in has suggested a potential solution. I will try coding it up and then seeing how different input and output modalities can be related to its mechanisms (I suspect that will prove to be the more difficult issue to address!)

Reply to
Don Y

I recall "watching" those little magnetic domains hugging the chevrons as they moved around the "chip". (and arguments about whether chevrons, T's, etc. were the most appropriate choice for guide pieces).

I think a big problem with bubble was physical size (there is a large, physical *minimum* device size) and power requirements. IIRC, the device had to be *heated* to work (?).

I suspect there would also be limitations (much LOWER than solid state memory) on random access data rates -- since you had to "march" an entire track of bubbles from initiator to annihilator. (how fast can you rotate that field?)

I suspect that photolithographic processes for solid state memory have probably surpassed the practical limits that would have been capable with bubbles (??) [Though nanotechnology might render this assumption moot]

Reply to
Don Y

That assumes there is "concrete" output medium. E.g., if your "output" is a mechanical process, then it doesn't really make sense to put the options "in (the) output". (of course, log files can give you that same sort of thing)

Ah, but restore *what* defaults?

(thinking in GUI terms...)

A "cancel" button allows changes to the "current settings" (as presented in that "dialog") to be discarded -- thereby "avoiding a change" (turning around and reinvoking that dialog then, effectively, shows you what the "defaults" were at the time you had previously invoked the (canceled!) dialog. (So, you could opt for a "undo my changes" button that restores the settings to their values before you *started* to change them).

"Restore defaults" could reset the settings to their initial state when the "program" was invoked (THIS SESSION!). E.g., if invoked as: program -use_rc_file=myrcfile then it might restore the settings in evidence in that rc file.

*Or*, it might discard those and restore the *system* default settings (or, if there are hardwired options in the executable!)

What if the user, *during* the session, invoked the "load template" command (to bring in a set of preconfigured settings -- like "setup the CNC machine for the Acme job for Mr. Wile E. Coyote")? What do you "restore" to in that case?

In CLI's, I suspect options are always passed either on the command line itself or in an rc file (either explicitly or implicitly specified). So, the program would need to have a mechanism to update those "external" entities when commanded. E.g., program -updatercfile=myrcfile

The user then explicitly chooses when to do this or scripts the invocation, as desired (depending on what sort of shell is available).

A GUI can be viewed as a mechanized implementation of this same sort of thing. I.e., the option "dialog" feeds information about your choices to something that bundles those options to be passed to the actual "program". (this despite the fact that the dialog is probably initiated from *within* the actual program, itself!)

The problem with configuration files, rc files, etc. is similar to that of the CLI environment -- only worse!

With a CLI, the user can be told that his choice of options is "defective" *when* he issues the command ("--short and

--long are mutually exclusive options. Pick one or the other!"). With configuration files or any other thing that is prepared "off-line", there is no way of informing the user of the problems with his choice of options. I.e., you almost need a "parse_my_configuration_file,_ONLY" option and a self-enforced discipline of using this to check your files each time they are altered!

[anyone who has ever done RJE-type work knows the despair that comes with the belated realization that a required JCL card was omitted or out-of-order... and, as a result, the job needs to be resubmitted. Ditto for very long command lines (an argument against long identifiers in option/flag names!) where you discover a typo or incompatible option AFTER having typed 100+ characters!]
Reply to
Don Y

I don't think so. If I have a print design program, I don't want the same persistent options for a microprocessor board design, and a power fet board design.

Huh? I like it that if I check in to cvs (same command line) the editor that is used is specified by my VISUAL setting, such that I can use a more primitive editor if I have a remote connection.

At least we agree that considerations go into this!

Groetjes Albert

--

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
 Click to see the full signature
Reply to
Albert van der Horst

IMO, the difference between GUI and CLI applications is that there is most often (or easily made available!) a way to view the options in effect for a GUI in a more condensed form than is available in a CLI.

E.g., "... | Options | Preferences" often throws up a (often complex!) dialog that first *shows* the current settings and then allows them to be changed. It's so common that is almost de rigeur!

Also, GUI applications seem more likely to support simple mechanisms for creating "options sets", storing them (i.e., as a named configuration) and *loading* them at a later date. CLI's tend to push this sort of activity onto the user in whatever ad hoc means *he* deems appropriate.

CLI's also tend to be inconsistent in their support of simple mechanisms to override built-in defaults (e.g., ENVARs). So, the user's only practical alternative is to script

*everything* -- or, be left with a hodge-podge of different mechanisms as dictated by the individual applications.

Sure! But the ENVARs used for one tool often are *shared* with other tools ("programs") -- even if you don't want them to be! Or, *aren't* shared and can't be EASILY made to be so.

[again, without putting the onus on the user to come up with mechanisms to, for example, copy EDITOR to VISUAL, etc.]

The point of my original post was to identify the different types of "defaults" that are present in (most) "programs" E.g., those compiled in, those defined by the system/site, those defined by the user, those defined by a particular

*instance* -- or type of instance (like "microprocessor" vs. "power fet"), etc.

And, doing so in a *consistent* manner so the user knows how *every* "program" (or, "portion of the application") is "driven" (and *can* be driven).

Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.