ranjit@eniac.seas.upenn.edu (R. Bhatnagar) (11/24/88)
Do there exist any animation playback tools - on the order of The Director - that have an AREXX port? Or any fairly good ANIM players that are available in source form so someone could add external control? All I really want to do is be able to synchronize the start of an animation with some sort of external signal, but I can imagine that something like The Director with an AREXX port could have applications so nifty that one's niftometer would need recalibration. (A database, word processor, and animator linked together with a nice AREXX kernel could put Hypercard to shame...) Oh yeah, that reminds me of an idea I had. What do you think of a generic user interface? That is, a program which allows you to graphically manipulate menus, buttons, dialogs, etc. and attach them to arbitrary AREXX scripts. This would allow one to build custom user interfaces to at least some of the features of AREXX capable software (some things would still be best handled by custom code, of course), and would also allow one to develop software without any user interface at all, and then add the interface later. Any number of such programs could be operated by one integrated interface; such custom interfaces could be traded on the net like hypercard stacks. Question: is it good AREXX style to pass private data like window structures around, so that a user interface could ask a program whether it has a custom window/screen, and if so, use it? Of course, I don't even own AREXX yet, so I don't have any idea what I'm talking about. - Ranjit "Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... If you throw a rock into the night and something barks, you know you hit a dog.
lphillips@lpami.van-bc.UUCP (Larry Phillips) (11/27/88)
> ... > that something like The Director with an AREXX port could have > applications so nifty that one's niftometer would need recalibration. > (A database, word processor, and animator linked together with > a nice AREXX kernel could put Hypercard to shame...) I can't think of a single use for those three program types being connected through ARexx, but I am heartened to see you say that it would be nifty. It shows that no matter what capabilities an author incorporates into a program, there is no way that all possible uses can be taken care of, or even envisioned, before the users get their hands on it. > Oh yeah, that reminds me of an idea I had. What do you think of > a generic user interface? That is, a program which allows you to > graphically manipulate menus, buttons, dialogs, etc. and attach > them to arbitrary AREXX scripts. Without a doubt a great idea. Don't limit it to graphical interfaces though. Think of all manner of interaction, and allow for as many as you can. Think small to think big. A collection of programs, each providing some services, without being too large in either code size or in complexity and number of functions, can combine in ways limited only by the end user's imagnation. > This would allow one to build > custom user interfaces to at least some of the features of AREXX > capable software (some things would still be best handled by > custom code, of course), and would also allow one to develop software > without any user interface at all, and then add the interface later. Even programs that don't speak Arexx can be incorporated into an integrated application. I often use various Amigados commands to do some function as part of a script, using either a pipe or temporary file to hold results. Better that we have programs that speak ARexx, of course, but the rest can be useful as well. I have two programs nearly finished (the display module is done to the 'alpha test' stage, and the serial module is nearing completion), that speak ARexx. In fact, they really ONLY speak Arexx, in that they are operated fully from messages passed: 1. from a script to a module 2. from a module to a script 3. from a module to a module. As a simple example, I can tell the serial port that all data received is to be passed to the display module in the same manner that I would pass text to the display module from a script, ie. with a message that looks just like an ARexx message (which in turn can be looked at like a standard Amigados message with a particular format). Likewise, the display module can be told by the script (or another module) to pass any keystrokes to the serial module, again, via the same type of message that the script might use to 'SEND' data out the serial port. Both modules can also send their data to the controlling script, if the need should arise, allowing data to be sent to multiple other modules, depending on content or time or a match on incoming data or whatever criteria suits the application. It occured to me during testing of the display module that I had just created something that would be useful for updating something in a database (or a simple, 'flat file' type of database that would benefit from a user interface and from various Amigados commands, such as SORT or SEARCH). It could be used as a CHAT window in conjunction with a BBS, and probably a number of other uses I won't even try to think of. > Any number of such programs could be operated by one integrated > interface; such custom interfaces could be traded on the net like > hypercard stacks. Question: is it good AREXX style to pass private > data like window structures around, so that a user interface could > ask a program whether it has a custom window/screen, and if so, use > it? I don't know if it's good practice or not, but I will be attempting to find out (empirically, unless someone can point out a fallacy before I try it). Both the modules mentioned above have a 'STATUS' command that returns a result string to the controlling script. The serial module, in addition to the obvious things, like baud, duplex, etc. Will tell you if it is currently 'listening' to the serial port, talking to the serial port, and the address of the read and write IO structs. The purpose behind this is that I want to allow another program to be able to use the serial port on its own, such as might be desirable for protocol, realtime game, music, graphics modules, general high speed terminal applications, and who knows what else? The module would preferably know how to speak ARexx, so that it could send the IO commands directly and at high speed without having the overhead involved in setting up or closing the serial port. In addition, any program, even if it did not speak Arexx, that opened the serial port in shared mode could also be allowed to use the port in a controlled manner, under direction of a script. The display module's 'STATUS' command also returns the address of its window and the output console device, for basically the same reasons as above. I think the window address will be particularly useful for such things as attaching menus and gadgets to it, and for rendering graphics. For the menu/gadget stuff, I will be adding handling from within the display to 'pass the events' back to the script via ARexx-alike message, but that hasn't been implemented yet. If anyone reading this can see any problems with any of the ideas, please let me know. > - Ranjit -larry -- "Intelligent CPU? I thought you said Intel CPU!" -Anonymous IBM designer- +----------------------------------------------------------------+ | // Larry Phillips | | \X/ lpami.wimsey.bc.ca!lphillips or van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+