[Tfug] Poor man's GUI
Bexley Hall
bexley401 at yahoo.com
Mon Mar 10 16:37:40 MST 2014
Hi Don,
On 3/10/2014 3:40 PM, Freeman, Don wrote:
> Sorry, it's not clear to me what the end game is here. How do the new
> settings get sent to the application?
I am *speculating* (I have no experience writing HTML) that the
"Save As" causes the *created* .html file to encode the current
state of each "setting" as modified by the user while *viewing*
that original HTML file.
So, if the initial file contains a fragment to the effect:
<HR><H2>Indicate which output files you would like the compiler
to generate<\H2>
<INPUT TYPE="checkbox" NAME="files" VALUE="asm">.s
<INPUT TYPE="checkbox" NAME="files" VALUE="object" CHECKED>.o
<INPUT TYPE="checkbox" NAME="files" VALUE="symbols">.b
</HR>
This would initially appear as a set of three checkboxes labeled
".s", ".o" and ".b". Only the ".o" checkbox would be enabled
("checked") when the user first views this file.
Now, assume the user decides he wants the .s and .b files to
be generated and NOT the .o. He would have used the mouse (etc)
to click on the corresponding checkboxes to toggle their respective
states to indicate his wishes.
ONCE DONE WITH ALL HIS CHOICES, he tells the *browser* to
"File | Save As" this form as "mychoices.html".
[He could, conceivably, save it using the same name as the
original file...]
I am *hoping* that the saved file now looks like:
<HR><H2>Indicate which output files you would like the compiler
to generate<\H2>
<INPUT TYPE="checkbox" NAME="files" VALUE="asm" CHECKED>.s
<INPUT TYPE="checkbox" NAME="files" VALUE="object">.o
<INPUT TYPE="checkbox" NAME="files" VALUE="symbols" CHECKED>.b
</HR>
I.e., the .o choice has been UNchecked while the other two
have been checked.
Now, the application reads this "mychoices.html" file looking
for the widgets/controls having the previously determined,
recognizable names "asm", "object", "symbols", etc. and determines
if they are "CHECKED" or not. I.e., if the options corresponding to
those "switches" have been enabled, or not.
> What form of config file does the
> "little application" want to see?
The "mychoices.html" could suffice as that configuration file.
It would just "coincidentally" have lots of other cruft in it
(e.g., the heading "Indicate which output files you would like
the compiler to generate")
> Can you run it with command line options?
You would be significantly taxed trying to sort out which command
line switches to add. Unlike GCC (which was just an example I chose
thinking folks would have some familiarity with it), there are
literally *scores* (100+) of "options" that could be independantly
enabled/disabled. Trying to make sure you had all of them
individually specified on the command line would be a Rx for
screwup.
OTOH, a (scrollable!) form that presents all these options -- with
textual annotations alongside each -- is a lot easier to interact
with. Having *saved* the form (required to actuate the application!),
you can also more readily review what you did/did not specify
without having to decode dozens of command line switches.
> Do you need to save a text file with old and new settings?
I think saving the "most recent settings" would suffice. This
would eliminate the need to specify an "output/save_as" file name
(and, communicate that to the application so the application
knows which file to parse to determine the settings *requested*.
I.e. I am replacing "submit" (which would post the form back to
the SERVER) with "save as" (which just updates it on the local
media where the application can directly examine it).
I want to leverage the browser's ability to present "pretty
forms" -- and in a structured manner (that makes it easy for
the application to parse the saved results!) without having
to incur the cost of serving the form via a genuine server!
> Seems like it
> would be easy enough to scan the controls on the webpage and save whatever
> you need into a text file or xml, etc.
I was just going to let the application parse it directly
and "save" it internally -- as if the html file was just a
messy set of command line switches...
More information about the tfug
mailing list