[Alephmodular-devel] On Dialogs

[Br'fin <br...@ma...>]

The external view of a dialog is something like this
	Setup dialog
	Fill dialog with preliminary necessary info
		Think a list of maps for instance
	Fill dialog with current options
	Process the dialog
		During dialog processing, certain elements may perform callbacks to
		code the originated the dialog.
		Think a network dialog polling for people
	If Ok is hit
		then extract info from dialog into options
	Tear down the dialog

Taking a peak through Woody's A1 code reveals what he said before. Most 
specifically the fill_dialog and extract_dialog routes are mostly 
handled by cross-platform code under A1 for the network game options.

I do find myself wondering if fill_in_game_setup_dialog as presented is 
too... verbose?

It sets values from player prefs and network prefs.
It refers to controls of roughly a specific type

Now, I might be over-designing things. But wouldn't one abstraction be 
to treat all controls the same? For each control we're setting a value. 
And as a second element deciding which controls are enabled. And 
wouldn't a second abstraction treat the options we're dealing with as 
some kind of dictionary or hash?

Which ends up translating into a list of SetMyWidget(iControl, 
options->valueFor('icontrol_setting'); commands. Regardless of which 
are check boxes, menus, text boxes or radio groups.

Now, I admit, going the dictionary route (completely generic incoming 
options hash) could indeed be going too far. On the other hand, it 
might be appropriate to have such a dictionary anyhow in a re-handling 
of preferences to be more flexible.

-Jeremy Parsons