taming the arrogant dialog

12.5: adde/gui/taming the arrogant dialog:
. one reason some dialogs will block any other actions
is to not lose your selection
or anything you've already input to the dialog .
. suppose the dialog were a separate window
and the selection in your document window changes,
then it needs to check selection;
and, if it changed, the user is asked
"(do you want to resume it?);
if the doc is modified, user is asked:
"(does new selection still fit your intention
for this old dialog?).
. sometimes the specific content of the original selection
will have determined the dialog type
(this is like a context menu selection by you,
only the app is doing it implicitely;
eg, if the selection contains both text and graphics,
then choosing style from the menu
should bring up dialogs for both text and graphics).
. if the document or the selection has changed,
then the dialog typing should be redone .
. if the dialog must be changed,
then the app must return the data by
logging* the parameter values provided by user
or also apply those changes to a
subsequent use of the dialog .
*: ( the entire user session is logged,
so that user's can know in writing what they did
that had the given effect; they can also use this writing
as part of developing scripts to automate their chores).
history stack traversal:
. it could just store modifications with the dialog,
and have a browser control with a back button
for earlier dialog fillings .
(warning:
. that works only in a protected acct with one user
otherwise that is a new behavior that could get very rude )
. this is a very important generalization:
html gui's can mean more service not less .