Make_user_manual.r ?
[1/28] from: sunandadh:aol at: 22-Jan-2002 5:24
I've just shipped a prototype of an application.
The prototype is in Rebol, and consists of about 45K of code. Tiny by any
standards.
But it shipped with a 3 meg PDF consisting of 6000 words of text and a load
of screen shots.
Once I congratulated my self for getting out the door--and on deadline day
too--I started thinking there has got to be a better way.
Suppose I redid those 6000 words of text in (say) make-doc format. And
embedded in them was a "click-stream" to run the application, add data,
scroll, etc; and then capture the screen image and insert it in the printed
document.
If I had been able to do that, the whole shebang would have been under 100k.
I've got no idea how to go about doing something like this, but I would
suggest it would need something like:
-- Some way to "play" a script from a "make-doc" script. I've got no idea how
this could be done.
-- Some re-engineering of the target application to make it "make-doc"
friendly (perhaps giving a name to every Layout and VID element that is to be
clicked
so we can dispense with simulating mouse moves).
-- Some re-engineering of the target application (or the shipping of a
special "documentation" copy) because I don't want to be running keystrokes
into someone's live data.
-- The ability to capture screen shots in Rebol of VID windows. (This bit's
not so hard)
If this was possible, the same code base could also:
-- run demos
-- automate data entry
-- allow the end user to record "macros" for any Rebol application.
So if anyone has any idea of how to play a script from another, feeding it
keystrokes or equivalent, and capturing all or part of its VID windows, I for
one would be grateful for some help....
....I have another iteration of the prototype in a few weeks and I'd much
rather be impressing the world with a 100K download that apologising for what
will be closer to a 6meg monster.
Thanks!
Sunanda.
[2/28] from: brett:codeconscious at: 22-Jan-2002 23:44
Hi Sunanda,
> Suppose I redid those 6000 words of text in (say) make-doc format. And
> embedded in them was a "click-stream" to run the application, add data,
> scroll, etc; and then capture the screen image and insert it in the
printed
> document.
What a wonderful idea! I'd say everyone that uses Rebol/View would love it.
It seems to be to be very closely related to those training wizards that
demonstrate the actions and the results. It is probably also closely related
of those recruitment tests that meaure a user's performance in completing a
task in an application.
A dialect for presenting a series of named topics could be useful. Each
topic could include field setting statements, simulated user actions and
commentary. The same dialect could be used for producing web pages, or for
doing a real time demonstration.
<snipped very good comments>
The only really concrete thing I can contribute right now you probably
already know:
to-image
e.g
view layout [image to-image layout [text "this is an image"]]
Building on your naming idea. You could write functions to search the layout
to find specific elements and call actions as needed. You wouldn't
necessarily have to name buttons - just use their text to refer to them.
Though subsquent changes to the text could cause problems.
Another line of thinking.
insert-event-func. It provides the ability to intercept every event, but
working out
how such events are treated by VID and your program could be tricky.
Another alternative, ratbag idea, is to write a brute of a program that will
take a layout and replace every action function it can find in the layout
(all the way down) with a new function that (a) fires some recording event
and (b) calls the original action. The problem with this is what scheme can
be used to identify the action recorded so it can be saved and loaded later?
Your name idea might be useful here. I wonder if there are others - path to
face?
Another problem could be that some fields don't have actions. In which case
the program might have to insert them in order to provide the recording
hook.
Again, great idea!
Brett.
[3/28] from: m:koopmans2:chello:nl at: 22-Jan-2002 14:10
> > Suppose I redid those 6000 words of text in (say) make-doc format. And
> > embedded in them was a "click-stream" to run the application, add data,
> > scroll, etc; and then capture the screen image and insert it in the
> printed
> > document.
>
> What a wonderful idea! I'd say everyone that uses Rebol/View would love
it.
> It seems to be to be very closely related to those training wizards that
> demonstrate the actions and the results. It is probably also closely
related
> of those recruitment tests that meaure a user's performance in completing
a
> task in an application.
I agree. And would bow deeply ;-)
<....>
> Another alternative, ratbag idea, is to write a brute of a program that
will
> take a layout and replace every action function it can find in the layout
> (all the way down) with a new function that (a) fires some recording event
> and (b) calls the original action. The problem with this is what scheme
can
> be used to identify the action recorded so it can be saved and loaded
later?
> Your name idea might be useful here. I wonder if there are others - path
to
> face?
Isn't it better to change the behaviour of View there?
Make an action2 field that contains the action field, and set the action
field to [record action2],
where record records and does action2. Or is this what you mean?
My 0.02 eurocents ;-)
[4/28] from: brett:codeconscious at: 23-Jan-2002 0:54
> Isn't it better to change the behaviour of View there?
> Make an action2 field that contains the action field, and set the action
> field to [record action2],
> where record records and does action2. Or is this what you mean?
Yup. :)
Brett.
[5/28] from: robert:muench:robertmuench at: 22-Jan-2002 15:29
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 6>>
> scroll, etc; and then capture the screen image and insert it in the printed
> document.
Hi, I already asked about a snapshot button to add to applications for capturing
screenshot as I wanted to include these graphics into make-doc-pro documents.
:-)) So it's on my to-do list for make-doc-pro but I didn't made it yet.
> -- Some way to "play" a script from a "make-doc" script. I've got no idea how
> this could be done.
To play it as VID? There is a presenter script that uses make-doc documents as
input.
> -- Some re-engineering of the target application to make it "make-doc"
> friendly (perhaps giving a name to every Layout and VID element that is to be
> "clicked" so we can dispense with simulating mouse moves).
There should be snapshot button laying around you can press to get the graphics
from the actual view. Maybe a keyboard short-cut will do the same. Robert
[6/28] from: sunandadh:aol at: 22-Jan-2002 12:04
Sunanda:
> > Suppose I redid those 6000 words of text in (say) make-doc format. And
> > embedded in them was a "click-stream" to run the application, add data,
> > scroll, etc; and then capture the screen image and insert it in the
> printed
> > document.
Brett:
> What a wonderful idea! I'd say everyone that uses Rebol/View would love it.
> It seems to be to be very closely related to those training wizards that
> demonstrate the actions and the results. It is probably also closely
related
> of those recruitment tests that meaure a user's performance in completing a
> task in an application.
Thanks to Brett, and to Maartin and Robert who have also responded.
I think it's a great idea too. After all, if it existed today, it'd save me a
whole bundle of work. And, if it is technically feasible (and that is what I
don't know) and within my compass as a Rebol dabbler, writing it will be a
lot more fun than working for a living.
Let me throw in a concrete example, and as if anyone can find a way to do it
in this mini-application.
Here's an application that displays two windows:
= = = = = = = = = = = = = = Rebol []
unview/all
View/new/offset L1: layout [
l1-choice1: choice "red" "white" "Blue"
[l1-box1/color: get to-word first value
l1-box1/font/color: 255.255.255 - l1-box1/color
show l1-box1
]
l1-box1: box 300x200 red "box 1 on layout 1"
] 100x100
View/new/offset L2: layout [
l2-choice1: choice "pink" "wheat" "maroon"
[l2-box1/color: get to-word first value
l2-box1/font/color: 255.255.255 - l2-box1/color
show l2-box1
]
l2-box1: box 200x300 pink "box 1 on layout 2"
] 300x300
do-events
= = = = = = = = = = = = = I want to run this application automatically, change the two
boxes to blue
and maroon respectively, and then capture:
1. The image of Layout1
2. The image of L2-box1
To do this, we can instrument / reengineer the application in any way, e.g.:
-- a Script Arg might tell it to Return to the invoking script rather than
issue the do-events).
--The invoking script might run down the layouts changing the Actions, or use
insert-event-func to add control magic.
The method used should be sufficiently general so it can be extended to
handling typing values into text fields, setting check boxes and so on.
I'm happy at this stage to ignore modal actions like request-date.
Any ideas?
Sunanda.
[7/28] from: brett:codeconscious at: 23-Jan-2002 10:45
Here's a quick idea. Just to play with. Test-app01.r is your example.
Regards,
Brett.
Rebol []
; Needs to be fleshed out with all styles
; Useful for other situations.
set-data: func["Set the data of a VID element."
face value
/action "performs the associated action"
][
switch face/style [
choice [
face/text: value
face/data: find face/texts face/text
if action [do-face face none]
show face
]
]
]
ctx-view-player: context [
play-app: func[app][
do bind load/all app 'self
]
do-events: does [
; Get L1 to the state we want
set-data/action l1-choice1 "Blue"
; Now save the image
save/png %l1.png to-image L1
; Get L2 to the state we want
set-data/action l2-choice1 "maroon"
; Now save the image
save/png %l2.png to-image L2
unview/all
]
]
ctx-view-player/play-app %test-app01.r
[8/28] from: sunandadh:aol at: 23-Jan-2002 5:12
Brett:
> Here's a quick idea. Just to play with. Test-app01.r is your example.
Outstanding stuff! It just shows what can be down with a powerful tool like
Rebol in the hands of someone who knows how to use it.
I'm thinking about how I can extend (and probably butcher) your work to get
towards something that would work for me. Initial things are:
1. Extend the switch face/style to include many other styles
2. As you suggested in your earlier email, we need a function that finds and
actions a face according to its /text or /texts facets....It is not feasible
to name every item.
3. Handle alt-action ("right click")
That gives us something that generates the screen shots. Then
4. (If it doesn't already) modify pdf-maker or make-doc or an html dialect to
embed the named images into their output
5. I rewrite my user manual, and I'm done!
And of course, it'd be nice to then recast it into a dialect, and have
control structures too ("if this is showing in that text box, then do x. If
button y is not hidden, click it")
And it'd be even nicer to capture the initial raw click-stream
("action-stream"?) while running the application by hand. I've no idea how
that could be done (modify the basic VID behaviour of action and alt-alction
facets as Maartin suggested?). That'd be almost all that was needed for
demo-runner.r
But that's more than enough for me to be going on with. Thanks again,
Sunanda.
[9/28] from: brett:codeconscious at: 24-Jan-2002 0:11
Hi Sunanda,
Thanks for you overly kind email!
As for the searching functions we talked about, try these (which are totally
due to the fact that I looked at the source of find-key-face):
; Used logic of find-key-face.
find-face: func [
"Search faces - returns first that results in the function evaluating to
true."
face [object!]
funct [block! function!] "A function or a function body block"
/local w f result
] [
if block? :funct [funct: func [face] funct]
either funct face [face] [
w: in face 'pane
either block? w: get w [
result: none
foreach f w [if all [object? f f: find-face f :funct] [result: f
break]]
result
] [
if object? :w [find-face w :funct]
]
]
]
find-faces: func [
"Search faces - returns those that result in the function evaluating to
true."
face [object!]
funct [block! function!] "A function or a function body block"
/local w f result
] [
if block? :funct [funct: func [face] funct]
result: copy []
if funct face [append result face]
w: in face 'pane
either block? w: get w [
foreach f w [if all [object? f] [append result find-faces f :funct]]
] [
if object? :w [append result find-faces w :funct]
]
result
]
; Example - find one face
fce: find-face lyo: layout [
text "one"
text "two"
box "three"
] [equal? face/text "two"]
fce/color: red
view lyo
; Example - find multiple faces
repeat fce find-faces lyo: layout [
text "one"
text "two"
box "one"
] [equal? face/text "one"] [fce/color: yellow]
view lyo
So searching is pretty much done.
> 3. Handle alt-action ("right click")
DO-FACE-ALT should do it.
Will keep the other of your points in mind.
Brett.
[10/28] from: sunandadh:aol at: 23-Jan-2002 10:51
Brett:
> Thanks for you overly kind email!
I don't think so! This list is sometimes like a magic-lamp genie. You ask you
something and--no matter how unlikely it is--hey presto! and one of the list
djinns
drops it in your lap.
I gotta get my head down for a few days, do some more obviously real work.
But I'll definitely be playing with your code asap. Thanks again.
(I must have used up my three wishes by now, or I'd be idly speculating about
the pressing need for an /osama refinement to 'find <g>).
Sunanda.
[11/28] from: mario:cassani:icl at: 23-Jan-2002 17:14
Hallo Sunanda,
> And it'd be even nicer to capture the initial raw click-stream
> ("action-stream"?) while running the application by hand.
<<quoted lines omitted: 4>>
> needed for
> demo-runner.r
Uhm can't help as Brett did but reading the above an Idea came
to me: redefining VID in user.r, calling an external dialect,
can be the solution:
8<--------------------------------------------------------
REBOL [
Title: "VID Redefined"
]
capture_VID_anyfunc: func [] [
]
original_VID_anyfunc: :VID_anyfunc
VID_anyfunc: :capture_VID_anyfunc
8<--------------------------------------------------------
REBOL/view starts, load user.r that calls VID-Recorder.r,
the interpreter switches to the script using the wrapper
and no changes are required to the script!
Looks like is less than 2cents...
Nihao
Mario
[12/28] from: sunandadh:aol at: 23-Jan-2002 16:53
Hi Mario,
> Uhm can't help as Brett did but reading the above an Idea came
> to me: redefining VID in user.r, calling an external dialect,
> can be the solution:
Thanks for your thoughts. It got me thinking I could redefine Layout and then
insert some logging into action facets.
That would work for any application which neither used make-face nor replaced
an action facet after layout. I know that's not all applications, but it
would be a start.
Unfortunately, I fell at the first hurdle in cloning Layout.
Layout, it would seem, contains the words vid-face and vid-styles. These
belong to a context that cloning the Layout function breaks. There is
probably an easy way round this, so if anyone could tell me I'd be grateful.
To demonstrate the problem:
Lay: :layout
View/new Lay [Button "this works"]
Lay: do load mold :layout
View/new Lay [Button "this does not work"]
equal? :lay :layout
equal? mold :lay mold :layout
(the sources are identical but the contexts are not).
Thanks,
Sunanda.
[13/28] from: rotenca:telvia:it at: 24-Jan-2002 0:47
Hi, Sunanda,
> Layout, it would seem, contains the words vid-face and vid-styles. These
> belong to a context that cloning the Layout function breaks. There is
> probably an easy way round this, so if anyone could tell me I'd be grateful.
Are not the only words of the svv context used by layout.
> Lay: do load mold :layout
Try:
Lay: do bind load mold :layout in svv 'self
---
Ciao
Romano
[14/28] from: brett:codeconscious at: 24-Jan-2002 10:51
> Thanks for your thoughts. It got me thinking I could redefine Layout and
then
> insert some logging into action facets.
>
> That would work for any application which neither used make-face nor
replaced
> an action facet after layout. I know that's not all applications, but it
> would be a start.
Can't help you with cloning Layout. But I thought about logging action
facets:
Try this:
do-face: func [face value][
print "attempt action"
do get in face 'action face either value [value] [face/data]
]
do-face-alt: func [face value][
print "attempt alt action"
do get in face 'alt-action face either value [value] [face/data]
]
do load-thru http://www.rebol.com/view/tools/../demos/rebodex.r
I have also extended the set-data function I made earlier. I've had some
small successes with the Rebol demo effect-lab.r
but hit a brick wall with Rebodex.r due the suppy function of the LIST
style.
Brett.
[15/28] from: brett:codeconscious at: 24-Jan-2002 12:12
> Are not the only words of the svv context used by layout.
>
> > Lay: do load mold :layout
>
> Try:
>
> Lay: do bind load mold :layout in svv 'self
Smart :)
Site note:
svv is an abbreviation for system/view/vid
[16/28] from: sunandadh:aol at: 24-Jan-2002 4:33
Hi Romano
,
> > Lay: do load mold :layout
>
> Try:
>
> Lay: do bind load mold :layout in svv 'self
>
Thanks! I'd'nt've got that in a million years,
Sunanda.
[17/28] from: sunandadh:aol at: 25-Jan-2002 6:22
Brett:
> As for the searching functions we talked about, try these (which are totally
> due to the fact that I looked at the source of find-key-face):
Thanks for that.
Just to show I'm contributing something to this project rather than Oliver
Twist-like just asking for more, here's an extended version of your example.
The find-faces is the same, I've changed the example to:
-- correct a couple of typos
-- make it more emailable friendly ({...} rather than "...")
-- show how to find a Choice box
-- show how flexible find-faces is as it returns a Block.
This last part is particularly useful to me as my prototype application runs
off a tree viewer. To run it successfully, we need to be able to click the
nth "+" or "-" box to close/open a branch.
Rebol []
find-faces: func [
{Search faces - returns those that result
in the function evaluating to true.}
face [object!]
funct [block! function!] {A function or a function body block}
/local w f result
] [
if block? :funct [funct: func [face] funct]
result: copy []
if funct face [append result face]
w: in face 'pane
either block? w: get w [
foreach f w [if all [object? f] [append result find-faces f :funct]]
] [
if object? :w [append result find-faces w :funct]
]
result
]
do-it: func [] [
;; Change first (should be only) face whose text is "two"
;; to red
fce: first find-faces lyo [equal? face/text "two"]
fce/color: red
show fce
;; get a block of all faces whose text is "+"
;; and turn them pink
faces: find-faces lyo [equal? face/text "+"]
foreach f faces [f/color: pink show f]
;; Change the last "+" box to a blue "-"
if (length? faces) > 0 [
set in last faces 'text "-"
set in last faces 'color blue
show last faces
]
;; get first item whoses TEXTS is ["alpha" "beta"]
;; and change selected option to "beta"
fce: first find-faces lyo [equal? face/texts ["alpha" "beta"]]
fce/text: "beta"
show fce
return true
]
;; Display the layout
unview/all
view/new lyo: layout [
Button "Click to do it" [Do-it]
text "one"
text "two"
box "three"
Box "+" 25x25 olive
box "+" 50x50 wheat
box "+" 60x60 ivory
c1: choice "alpha" "beta"
c2: Choice "alpha" "beta" "gamma"
]
do-events
In the real world, of course, there'd be a lot more error trapping ,
Sunanda.
[18/28] from: brett:codeconscious at: 26-Jan-2002 0:01
Hi Sunanda,
I played around with the view player to handle scripts where a plain "view"
call is used. I'm still not sure
how robust this is but for now it seems like it could be useful.
Attached is a script to simulate a calculator session with a new version of
play-app
Brett.
-- Attached file included as plaintext by Listar --
-- File: view-player.r
Rebol [
Title: "View Player"
Date: 24-Jan-2002
Purpose: "An experiment in dynamically altering a View application."
Author: "Brett Handley"
Comment: {
Assumes only one wait in the target application.
}
]
play-app: function [
app [file! block!]
script [block!]
][was-error][
process-events: :wait
wait: does script
if was-error: error? err: try [do app][disarm err]
wait: :process-events
if was-error [print mold :err halt]
]
-- Attached file included as plaintext by Listar --
-- File: play-calculator.r
Rebol []
; Use-script is my local script manager.
; Define it if we are in another environment.
if not value? 'use-script [
either value? 'load-thru [
use-script: func[script][do load-thru join http://www.codeconscious.com/rebol-library/
script]
][use-script: :do]
]
use-script %face-searches.r
do %view-player.r
app: load-thru http://www.rebol.com/view/demos/calculator.r
play-app app [
; Set up the calculation
foreach [btn] ["6" "*" "9" "+" "4" "6"] [
do-face fce: find-key-face system/view/screen-face to-char btn none
]
save/png %calc1.png to-image first system/view/screen-face/pane
; Calculate the result
do-face fce: find-face system/view/screen-face ["=" = face/text] none
save/png %calc2.png to-image first system/view/screen-face/pane
]
[19/28] from: brett:codeconscious at: 26-Jan-2002 12:19
Hi,
Still been playing. I've now managed to get the following applications
scripted
including a picture
of request-file in action.
Calculator - two images.
Effect Lab - one image.
Rebtris - one image.
Message Export - three images.
You can see the demos on my rebsite "Code. C." under the folder "Play Apps".
These generate the images and just
display them on screen.
I had problems trying to script:
Splash - does wierd stuff :)
To Do - difficult to find the faces to target
BTW, I changed the definition of the face search functions I sent earlier.
There is no longer a need
to specify a face to start the search. You can use the /from refinement if
you need to search from a
specific face down.
I feel that the scripting should be made into a dialect to make things
easier, but I'm not sure how to go about that. If there
is some kind soul who would do that I'd be grateful, particulary if they
could explain the various steps of analysis, design and implementation for
the dialect. I think that would be really helpful to everyone.
I'm guessing the dialect should:
* attempt to make addressing of screen elements easy.
* attempt to make setting of values and calling of actions easy
* take pictures
* have embeddable rebol expressions (for specific cases where the dialect
has no pre-defined solution)
nice to have:
* allow expectations to be verified "application should be in this state"
It think that is the next most useful step in getting this into a active
documenter (with click stream).
Testing would be helpful too.
After that a methods for image highlighting (drawing arrows, boxes on the
images) and cropping typical of documentation type images would be useful.
Also, I've put an updated "set-style-data" function (formerly set-data - the
one that sets the data for a VID style while it
is on screen) on my rebsite. It is incomplete, likely to have bugs, but
works for some things. If haven't been able to go
through every standard vid-style. If any one can take a moment to fix bits
of it or validate it - that would be wonderful too.
Brett.
[20/28] from: brett:codeconscious at: 26-Jan-2002 12:50
> hmm not working for me => try:
Should be ok now. See the "Play Apps" folder in the main "Code. C." rebsite
folder.
Brett.
[21/28] from: jason:cunliffe:verizon at: 25-Jan-2002 21:17
Brett
> Should be ok now. See the "Play Apps" folder in the main "Code. C."
rebsite
> folder.
yep thanks: wow very cool..
but 'PlayExporter' gives me an error
http://www.codeconscious.com/rebsite/play-messageexport.r
** Script Error: in expected object argument of type: object
** Where: set-style-data
** Near: do any [
all [in face 'style if find [radio check] face/style [related]]
all [in face 'style if equal? 'text-list face/style [picker]]
all [in face 'style if equal? 'toggle face/style [toggle]]
all [in face 'style if equal? 'list face/style [list]]
if found? face/texts [multi-text]
if found? face/text [single-text]
single-non-text
]
if action
>>
Also, can you enable ordinary color..?
./Jason
[22/28] from: jason:cunliffe:verizon at: 25-Jan-2002 20:39
> You can see the demos on my rebsite "Code. C." under the folder "Play
Apps".
> These generate the images and just
> display them on screen.
Hi Brett
hmm not working for me => try:
http://www.codeconscious.com/rebsite/library-catalog.r
..then scroll down to %view-player.r
but awkward to load/copy/run it from there..
Can you post a more direct link please?
thanks
./Jason
[23/28] from: greggirwin:mindspring at: 26-Jan-2002 15:54
Hi Brett,
I've just been lurking on this thread.
<< I feel that the scripting should be made into a dialect to make things
easier, but I'm not sure how to go about that. If there
is some kind soul who would do that I'd be grateful, particulary if they
could explain the various steps of analysis, design and implementation for
the dialect. I think that would be really helpful to everyone. >>
I think the functions you've defined are a good starting point.
<< * attempt to make addressing of screen elements easy. >>
FIND <criteria>
- or -
FIND-FACE <criteria>
IN <face/pane>
WINDOW <title> ???
<< * attempt to make setting of values and calling of actions easy >>
CLICK <face, string!(caption)>
ALT-CLICK <face>
SEND-KEYS <keys>
SET-DATA <face> <word> <value>
GET-DATA <face> <word>
ENGAGE <face> <action> <event> ???
<< * take pictures >>
TAKE-SNAPSHOT <file!>
Should there be an easy way to buffer snapshots, or have them
automatically saved, so you don't have to worry about those details
in your play script?
Other commands:
WAIT <integer!, time!>
<< * have embeddable rebol expressions (for specific cases where the dialect
has no pre-defined solution) >>
DO <block!> ???
<< * allow expectations to be verified "application should be in this state"
>>
EXPECT <criteria>
Should people submit ideas for what seems natural to them, and then we can
distill a dialect from that? I.e. have people write sample scripts for
imaginary apps. For example:
play-app [
; Make sure we have the main window to start with
expect window "pick-a-part"
take-snapshot "main"
; Click on the button that displays the part-selection dialog
click find "Select" button in find "Parts" panel in window "pick-a-part"
; The part-selection dialog should now be up
expect window "select part"
take-snapshot "parts-dialog"
; ??? How would we locate a list reliably?
; Alt-clicking should display details for a part
alt-click find first text-list
take-snapshot "part-help"
; hide the part detail display
send-keys "(escape)"
; Make option selection to hide out-of-stock parts
click second option in first panel in window "pick-a-part"
take-snapshot "hide-if-out-of-stock"
; Close the dialog
click "OK"
; Make sure we're back at the main window
expect window "pick-a-part"
click "Quit"
]
--Gregg
[24/28] from: sunandadh:aol at: 26-Jan-2002 19:07
[greggirwin--mindspring--com]:
> I think the functions you've defined are a good starting point.
I think Brett's onto a winner too. I like your list of dialog functions. I'd
add (maybe in version 2.0) things like:
PAUSE -- Stops executing the script, perhaps with a message telling the user
to do something in the playing-app and then hit resume in the player, e.g.
PAUSE "Please enter the FTP password and press Okay. Then click Resume "
DISABLE UPDATES -- We redefine 'Write, 'Delete, 'Make-dir and 'Send (and
probably more) to do nothing so demos can run "safely" (not all played-apps
could lose their i/o and still work -- some will fall over rereading data --
but many could).
We may also want to disable other things, such as 'Wait within the played-app.
ENABLE UPDATES --
HALT -- with options to leave the played-app running, or to have shut it down.
INCLUDE xxx.r -- take next set of playback commands from xxx.r so we can
build complex scripts from simpler ones
Dare I suggest a name for this application....?
Either the obvious Reboil --- as you can automatically bring any application
to the boil as often you like with a script.
Or the archaicly poetic Reboant --- to echo, loudly (with hints of a Rebol
worker ant beavering away for us).
Sunanda.
[25/28] from: greggirwin:mindspring at: 27-Jan-2002 12:01
Good thoughts Sunanda,
I think building the dialect will be the easy part. The harder part will be
figuring out the underlying logic, which Brett has made a *really* good
start on. As we come up with new features we want to add, extending the
dialect shouldn't be difficult.
--Gregg
[26/28] from: brett:codeconscious at: 29-Jan-2002 0:35
Hi Gregg and Sunanda,
I liked Gregg's dialect suggestions and particular some of the example.
It was really instructive for me and helps clear somethings up.
The ideas related to WAIT is problematical for me at the moment. I already
have a problem with network activity too. I have used
WAIT as my "hook" into the application. The logic is that when the
application waits, it is a sign for some user input - in this case time to
run the
play-app script supplied by the developer. So I redefine wait as a way for
the app to call play-app code when it wants some imput. Now this has been
ok, but network activity does an implied wait so if I want a load-thru to
work I have to allow the actual wait to happen, but then I don't know if
the wait was for the network or for the screen or both... Hmm.... :-/
Brett.
[27/28] from: brett:codeconscious at: 31-Jan-2002 22:14
Hi Gregg and Sunanda,
> So I redefine wait as a way for
> the app to call play-app code when it wants some imput. Now this has been
> ok, but network activity does an implied wait so if I want a load-thru to
> work I have to allow the actual wait to happen, but then I don't know if
> the wait was for the network or for the screen or both... Hmm.... :-/
Fingers crossed, I think I have solved this problem now.
Brett.
[28/28] from: greggirwin:mindspring at: 31-Jan-2002 12:43
<<
> So I redefine wait as a way for
> the app to call play-app code when it wants some imput. Now this has been
> ok, but network activity does an implied wait so if I want a load-thru to
> work I have to allow the actual wait to happen, but then I don't know if
> the wait was for the network or for the screen or both... Hmm.... :-/
Fingers crossed, I think I have solved this problem now.
>>
Great new Brett!
Let me know when you get things nailed down where you want them to be. I'm
totally buried at the moment (in rehearsals for two shows on top of normal
life stuff) so it may be few weeks before I have time to attack the
dialect. You never know though. :)
--Gregg
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted