OpenEuphoria

I don't think i was being that vague. I'll try to provide more details.

You have FAE set up so there's a root widget, and child-widgets, and those child-widgets can have child-widgets of their own. Each widget must have a unique name, and the names can contain numerals, so a root widget named "reality" can have a child-widget named "elephant", which can have child processes named "elephant-joe's" and "elephant-345". Any restrictions in the gui in "reality" are also restrictions to the elephants, as they are part of reality. Anything done in "elephant-joe's" doesn't affect what goes on in "elephant-345". That includes the gui onscreen, the Eu_tasking going on for the child, and the native windows OS msging, anything else going on.

It's that "anything else" i want to take advantage of, and from the description of Ry's FAE, the root "reality" widget can send messages to each child separately, as well as globally. So all i need to is have Ry insert code which i can edit as needed to specify what other Eu code to load into each widget.

For now, I can use Eu's tasking to do "elephant-joe's" and "elephant-345", not a problem, it's very easy to run that code, but all output goes to one console box on-screen. It looks like an irc window on a single channel. If i run a separate Eu program for each elephant, it gets as unwieldy as running a separate computer for each elephant and merging the on-screen guis to one monitor.

But FAE has wrapped up a programmable windows gui in such a way that if i add (estimated) 10 lines to the root widget, praps "procedure do_external(sequence what)" and "include external_xxxxx.e", and the program itself can copy/edit/save a new external_xxxxx.e before opening a widget, each widget will have a different do_external().

This means when the root "reality" sends a wmsg(?) to a child, each child, in it's own little widget, will process and display according to it's own code, bounded ultimately by FAE. FAE will handle the "where/how/when onscreen", the underlying OS messaging, the timeslicing, the popups, the "active onscreenwindow" keybd and mouse routing, everything in the "reality" directly related to the gui, while everything not related to the gui is handled by external_xxxxx.e as that widget included it. I can open "reality" and by virtue of the requested code, cause a new widget to open called "tree", and it includes an Eu file i write containg tree properties.

So while Ry didn't intend for FAE to be "object oriented", each widget is and can be a fully gui'd separate onscreen device, doing it's own thing in only one Eu program, and FAE provides the means for each device (note i am not using the word "object"?) has FAE to provide keybd input, on-screen output, and coordination with reality (thru the wm_msging) of the elephants (and any other active children of reality).

Lets say i had elephant_9876 and a tuft of grass_2345 widgets onscreen, and the tuft of grass popped up an alert window saying it cannot complete command "stand up on hind legs" sent to it by reality (or whatever the wm_msging in FAE is called). The external_xxxxx.e in grass_2345 send the error msg also to reality, which can halt the "time" in every child under reality, until i close the alert. I can write new code to prevent that from happening, save it, then in the gui provided by FAE, i check "restart" and "import history" for a "new" whatever caused that erroneous msg, the code in question is restarted, imports the relevant history file, and reality resumes the progression of time.

I do not know if the programmable background in a FAE window includes moving pictures, but if i had the realtime point-of-view graphics of a elephant reaching for a tuft of grass in the elephant_87465 window, and the realtime pov of the grass in the grass_xxxx window, i'd say Eu can now take full advantage of a gui OS.

Of course there's other ways of doing this narrow of an example, but FAE wraps all the stuff related to the widgets' on-screen interaction with the programmer in one tidy package, in one program, one app. The same can be applied to any multi-variable database or process. You get to pick what's onscreen, where, make changes, see results with your choice of what and how, in real time. One app may have widget "transmitter", "antenna array", and "recievers". One app may have widgets "input", parts xxxxx, and "output". You could plan a "garden" with various plants widgets, and tomatoes includes a tomato.e file, insects are included, and there can be a dirt.e widget, a sun.e and rain.e, all with a appropriate guis and parameters, even pictures, and you can run them forward and backwards in "time" (if the code you write, which each widget includes, can do that).

No elephants were harmed in the making of this post. Elephants were only a stand-in, they could have been mice or men or white whales or transistors or atoms or planets. FAE was leveraged to glue together all the widgets in "reality".