d6abc28b | 18-Jun-2013 |
Devin Teske <dteske@FreeBSD.org> |
Remove unnecessary loops, perform some code consolidation, and add some additional error checking/reporting. (same thing going on here as SVN r251905 -- just this time for the mouse module instead of
Remove unnecessary loops, perform some code consolidation, and add some additional error checking/reporting. (same thing going on here as SVN r251905 -- just this time for the mouse module instead of console)
show more ...
|
052f8969 | 02-Jun-2013 |
Devin Teske <dteske@FreeBSD.org> |
Standardize the way functions build their arguments leading up to a dialog invocation. Specifically, "top-load" your arguments and in the order in- which they will be displayed. For example, many [if
Standardize the way functions build their arguments leading up to a dialog invocation. Specifically, "top-load" your arguments and in the order in- which they will be displayed. For example, many [if not all] widgets display information in the following order, top-to-bottom (visually):
+ backtitle (displayed behind the widget at top-left) + title (at the top of the `window') + prompt text (just below the title and above whatever widget you choose) + Depending on widget, _one_ of the following: - menu list - radio list - check list - text input box with initial text - [Xdialog(1)] 2x or 3x text input boxes - [dialog(1)] a multi-part form - progress bar - etc. (many more widget choices) + buttons (right below the selected widget) + [dialog(1)] the hline (displayed at bottom of `window')
NOTE: Xdialog(1) accepts and silently ignores --hline
When building local arguments for your dialog invocation, if the value can't be cleanly loaded into a local, add "# Calculated below" to the end of the local declaration while retaining the block order of argument declarations.
Move other local declarations that are not associated with this top-loading the dialog arguments to right-above where they are first-used.
Also, standardize on the names of the arguments. For example, always use $prompt (instead of sometimes $msg and sometimes $prompt); use $menu_list or $shell_list or $radio_list for those respective widgets; ad nauseum.
While we're doing this, flush-out full arguments for many invocations that were passing NULL strings (making it unapparent if you were staring at this one invocation what argument that NULL string was supposed to represent).
Last, while we're in startup/rcconf let's remove the unnecessary use of a GLOBAL (RCCONF_MENU_LIST) for the menu_list.
show more ...
|
ec7120b5 | 02-Jun-2013 |
Devin Teske <dteske@FreeBSD.org> |
Similar to r251236, improve the portion of dialog(1) API in dialog.subr responsible for retrieving stored input (for the --inputbox and --password widgets).
When we (Ron McDowell and I) developed th
Similar to r251236, improve the portion of dialog(1) API in dialog.subr responsible for retrieving stored input (for the --inputbox and --password widgets).
When we (Ron McDowell and I) developed the first version of bsdconfig, it used temporary files to store responses from dialog(1). That hasn't been true for a very long time, so the need to always execute some clean-up function is long-deprecated. The function that used to perform these clean- up routines for these widgets was f_dialog_inputstr().
We really don't need f_dialog_inputstr() for its originally designed purpose as all dialog invocations no longer require temporary files.
Just as in r251236, redesign f_dialog_inputstr() in the following four ways:
1. Rename f_dialog_inputstr() to f_dialog_inputstr_fetch() 2. Introduce the new first-argument of $var_to_set to reduce forking 3. Create a corresponding f_dialog_inputstr_store() to abstract storage 4. Offload the sanitization to a new function, f_dialog_line_sanitize()
It should be noted that f_dialog_line_sanitize() -- unlike its cousin from SVN r251236, f_dialog_data_sanitize() -- trims leading/trailing whitespace from the user's input. This helps prevent errors and common mistakes caused by the fact that the new cdialog implementation allows the right-arrow cursor key to go beyond the last byte of realtime input (adding whitespace at the end of the typed value).
While we're centralizing the sanitization, let's rewrite f_dialog_input() while we're here to likewise reduce forking. The f_dialog_input() function now expects the first argument of $var_to_set instead of producing results on standard-out.
These changes greatly improve readability and also improve performance.
show more ...
|
fd962ac6 | 02-Jun-2013 |
Devin Teske <dteske@FreeBSD.org> |
Improve portion of the dialog(1) API in dialog.subr responsible for retrieving stored data (for the --menu, --calendar, --timebox, --checklist, and --radiolist widgets).
When we (Ron McDowell and I)
Improve portion of the dialog(1) API in dialog.subr responsible for retrieving stored data (for the --menu, --calendar, --timebox, --checklist, and --radiolist widgets).
When we (Ron McDowell and I) developed the first version of bsdconfig, it used temporary files to store responses from dialog(1). That hasn't been true for some very long time, so the need to always store the return status of dialog(1) and then call some function to clean-up is long-deprecated. The function that used to do the clean-up was f_dialog_menutag().
We really don't need f_dialog_menutag() for its originally designed purpose, as all dialog invocations (even when in a sub-shell) do not use temporary files anymore.
However, we do need to keep f_dialog_menutag() around because it still fills the need of being able to abstract the procedure for fetching stored data provided by functions that display the aforementioned widgets.
In re-designing f_dialog_menutag(), four important changes are made:
1. Rename f_dialog_menutag() to f_dialog_menutag_fetch() 2. Introduce the new first-argument of $var_to_set to reduce number of forks 3. Create a corresponding f_dialog_menutag_store() to abstract the storage 4. Offload the sanitization to a new function, f_dialog_data_sanitize()
NOTE: That last one is important. Not all functions need to store their data for later fetching, meanwhile every invocation of dialog should be sanitized (as we learned early-on in the i18n-effort -- underlying libraries will spit warnings to stderr for bad values of $LANG and since dialog outputs its responses to stderr, we need to sanitize every response of these warnings).
These changes greatly improve readbaility and also improve performance by reducing unnecessary forking.
show more ...
|