Re: Fluid Application Environment 3.0.alpha1 Released!
- Posted by useless_ Oct 14, 2013
- 2225 views
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.
I think perhaps the issue is confusion about the meaning of "code to load into each widget." In general, a GUI framework allows user programs to provide event handling code that is called when the respective event is fired from the underlying OS / window manager. I haven't heard anything about FAE that is any different in this respect.
Right now, it appears to be a wrapper around Win32, and all of your details don't really clarify for me what you think is deficient in ry's implementation.
Matt
Jimcbrown didn't read everything i wrote, but seems to have grasped part of it, which is what Ry did too. Rather than reply at length to him, i'll reply abbreviatedly to this...
FAE isn't the windows message handler, it may or may not use windows msg handler. And FAE's msg handler can send msgs to a specific event reciever in a specific widget, if i understand Ry correctly, as well as broadcast and wildmatch event handler or gui names to send to, if i understand correctly.
As a gui, FAE isn't deficient, or won't be, when it's out of alpha release. It's startlingly versatile and simple to use as is. As a gui, each widget works just fine.
I am asking for a set of oem hooks that do not crash (in and of themselves), which do not need to be hacked in by users, to perform functions in responce to events, like a msg from FAE's msg handler that says "time has now progressed one second". My other option is to write a separate app to send inter-app msgs according to my OS to FAE, simply making such an approach more complex and not cross-platform. By having a single fixed ryan-written include and procedure name for all my user interface other than gui, no new code need be added to any other part of FAE. Lets call that msg hook do_user().
The nature of the include hook isn't to do dynamically included code like has generally been done. If i tell "reality" widget to open an elephant widget, then i have previously written that elephant widget, but it has no gui, and has no interaction to any other gui. Praps that widget is an elephant with 3 legs. So i name my code elephant-3legs.e, and with FAE i launch a widget named "elephant-3legs", it includes elephant-3legs.e, and do_user() calls (or sends msgs to) any procedure in elephant-3legs.e, via FAE's msg handler (no changes there), and recieves msgs sent to it (no changes there). Once launched, FAE doesn't exclude and re-include any more .e files, altho it is obviously possible to close a elephant gui widget and then reopen a new gui widget of the same name.
So no tricks, no changes to anything in FAE as it is now, only adding something like:
include thiswidgetname & ".e" -- but do not crash if not there! ---- procedure do_user(sequence what) -- what = {function_to_do, it's parameters} function_to_do(parameters) -- but do not crash if not there! -- call targets are contained in thiswidgetname & ".e" end procedure ----
Add a few line for not_crashing code. Those lines become the default user interface to each separate widget of FAE. Maybe Ryan say if this feature is already present in some way. Maybe this is what jimcbrown was saying, but FAE currently doesn't allow(?). As i understand from our last conversation in #euphoria, this is pretty much a no-go, non-starter, prohibited use of the lib. If Ryan is not probibiting it, i recommend such a small addition, certified to not crash as if it would if hacked in by the random user who does not understand FAE so well.
useless
