Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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