OpenEuphoria

1. Fluid Application Environment 3.0.alpha1 Released!

• Posted by ryanj Oct 10, 2013
• 2952 views

Euphoria is an elegant programming language that has the potential to compete with other programming languages. Sadly, for many years, it has been lacking libraries and tools necessary for people to take it seriously as anything other than a hobby language. One of the major areas it is lacking in is Graphical User Interface libraries. Although there are several libraries available, they are all somewhat difficult to use because they wrap the complex Win32 API or third-party libraries that are written in C.

FluidAE is an exciting new GUI library that makes it easier than ever to design a graphical user interface in the Euphoria programming language. It is written from scratch in pure Euphoria code to take full advantage of Euphoria's sequences, namespaces, and other syntax features with minimal overhead. Internally, FluidAE hides the complexities of low-level operating-system-specific APIs with an “operating system window” layer of code. On top of this layer is a special system of Widgets that you control through a unique, elegant, and intuitive API. This API has several major advantages.

I am happy to announce that after 8+ years of experimentation, research, and rewriting code multiple times, FluidAE 3.0.alpha1 has finally been released! I sincerely hope that this project will help the Euphoria community to create high-quality software.

If you are interested in GUI programming, you can download it from http://fluidae.com/. Also, you can join the #fluidae channel on irc.freenode.net where I am available to chat about this project.

3. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by ryanj Oct 11, 2013
• 2759 views

It currently runs on Windows, but I plan to add support for other platforms, too.

No, it doesn't require any other libraries at all! It accesses win32 api directly.

5. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by useless_ Oct 11, 2013
• 2675 views

There is a gotcha in it: all the widgets must be different, you cannot reuse code even with a different-named widget. Ry has not yet said what the penalty is for doing so. Or why it is this way.

useless

7. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by ryanj Oct 12, 2013
• 2570 views

I'm sorry, I do not understand what you mean by "you cannot reuse code". It should be possible to create multiple instances of dialogs, or even multiple instances of groups of widgets that can be placed wherever you want. I am in the process of writing an application that will demonstrate this.

9. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by useless_ Oct 12, 2013
• 2574 views

From the irc logs of 10/10/2013 :

[21:01] <rywilly_> if you are curious, i wrote a really detailed API manual (pdf file) and there's a demo application, too
[21:02] <useless-afk> i *was* curious, until you said i couldn't run two or more widgets of the same code
[21:03] <rywilly_> i still am not sure what you were trying to say, i don't know if it can do what you want or not
[21:11] <useless-afk> how is FAE going to know i amrunning the same code twice, and what is the penalty i am subjected to?

And you had said regarding using the same code in multiple widgets, that FAE wasn't that OO.

useless

11. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by useless_ Oct 12, 2013
• 2555 views

So we cannot edit the widget library? What are the penalties for doing so?

useless

13. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by EUWX Oct 13, 2013
• 2479 views

I applaud your attitude. It is better to give the application programmer a reasonably complete set of functions and tell him not to meddle with those rules. He/she could then concentrate on creating a good application without worrying about the GUI and without worrying abolut any absent features.
I will even say that it is best to give a reasonably complete set of GUI functions and tell him to take it or leave it.
There are too many people writing too many functions and modifications to Euphoria, and not enough programmers using the language. The time spent (wasted) in these so called modifications is better spent on promoting the language in forums and areas where it matters.
One of the reasons I was suggesting many "includes" into one and building a "no entry" wall around it was this concern.

ryanj: My suggestion to you is to go ahead and finish the task the way YOU want to finish it, and then spend some time in giving us the demos and documentations. You then look at it later only when there are significant changes in windows APIs

15. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by EUWX Oct 13, 2013
• 2458 views

useless said: "I had hoped he could add 10 more lines of code to FAE to make all my dreams come true"

That attitude is exactly what I am concerned about. If every developer or user has that attitude, he will never be able to finish. The right attitude is what I suggested. Let him finish the way he wants to do it. Add your own functions in YOUR own application programs ad lib, but please don't clutter the library with extras.

A woman with a baby can get presents of all kinds of toys and clothes from friends and relatives, but don't force her to use those toys and clothes on HER BABY, and when the baby is to be presented to the outside world for a competition or just a trip, let the mother decide what clothes the baby wears and what toys she takes with her.

17. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by EUWX Oct 13, 2013
• 2430 views

ryanj has already said in his reply: "Yes, you could make your own custom widget classes, but it has to be done a specific way or it won't work correctly with the other widget classes"

19. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by jimcbrown (admin) Oct 13, 2013
• 2389 views

I'd like to see ryanj clarify this, but that's not quite my interpretation of what he said.

Here's my interpretation:

"You can do this, just make sure you figure out what the hidden rules are or things may break in surprising ways. If this sort of thing is not fun for you though, I hope to spare you as much of this pain as possible by doing my best to make sure you'd never need to make your own."

ryanj didn't explictly state this, but I thought the following was implied: "If his sort of thing is fun for you though, go ahead and have fun!"

Perhaps the most useful, or interesting, custom widgets will even be adopted by ryanj into the next release of FluidAE!

It'd be nice if ryanj could explicitly spell out what rules need to be followed, and what the exact consequences for violating each one is, however

A) You get what you pay for. AFAIK, although ryanj has been paid to develop at least one application, which involved work on and using FluidAE, he's not being paid to develop docs for custom widget writing.

B) This is an alpha version, so the rules and the consequences may have changed between now and the final release. "Internals" tend to change more frequently than a solid, external API.

There's always the occasional, odd, exotic app that needs its own custom widget though.

I strongly disagree with this. People should be free to tweak things. Maybe this library meets 95% of my needs, but if I can't add the missing 5% myself then I have to spent 100% of the effort doing it from scratch. That's a far cry from best.

A programming language is a tool. Most, if not every single one of those functions and modifications were done to address a specific need encountered in real life by someone.

I agree with you on the promotion and stuff, but for me, I haven't done it because that's no fun.

I agree with this, but at the same time, I'd recommend that ryanj keep an open mind about new ideas to improve his grand masterpiece. You never know who might suggest what to make this GUI easier to use or develop or more fun to deal with.

21. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by ryanj Oct 14, 2013
• 2332 views

I still don't understand what missing feature you are talking about. I'm not opposed to what you want, I'm just having a hard time understanding what you want. I designed FluidAE a certain way, but I'm open to suggestions. Perhaps if you explain an exact scenario, rather than a vague analogy. What exactly are you wanting to do that FluidAE can't do?

23. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by useless_ Oct 14, 2013
• 2327 views

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".

useless

25. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by useless_ Oct 14, 2013
• 2321 views

I believe what i detailed is using FAE as if it is almost Win3.11, asking for ~10 lines of code hooks to allow "user" code to be called and run by each widget. I am not asking to change the gui itself. I am not asking to change anything to Ry's code. I am asking only for two "hooks": to load a .e file, and a target procedure name for the FAE wm_msg'er to send a msg to. I believe a standardised set of hooks, known to interface to FAE properly, is needed, to eliminate the need for the user to hack these into FAE. And i am making the assumption that the .e file can call what widget internals needed to send wm_msgs back to the FAE msg handler, and do it's own widget popups and text input/output box, and interactions to it's own display (which can also be done by sending a wm_msg to itself, i presume).

Consider the windose desktop to be the root gui. Consider each icon on the desktop to be a mouse-able selection in FAE's root gui. I can write an app in Eu and put a shortcut to it on the winxp desktop, i can have a gui window on FAE show a list of programs in a hdd directory. I can click on and launch a winxp desktop shortcut or a FAE list item(?). Each application i launch (either way) "inherits" the characteristics of the parent: the "skin" if you prefer, unless that widget or program changes it. I believe the comparison of FAE to win3.11 is quite appropriate.

Mirc has the same ability: it can write new executeable code, it can include or drop executeable code (Eu can do that to DLLs now), it presents a gui with runtime-programmable popups and programmable backgrounds, it's child windows can be separate and placed anywhere onscreen, so it is like FAE also. Mirc has two huge problems: it runs dreadfully slowly, and has very restrictive lengths to variables.

I think FAE hands us win3.11 on a silver platter, written and therefor 100% compatable with Eu code, very easily understood, with all the options of every other gui lib in the archives plus some, and potentially cross-platform. It literally gives me goosebumps. I am only asking for the two hooks, which you may use or not, as you like.

useless

27. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by mattlewis (admin) Oct 14, 2013
• 2277 views

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

29. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by useless_ Oct 14, 2013
• 2268 views

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

31. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by useless_ Oct 14, 2013
• 2301 views

Ok, then the certified code that won't crash in FAE's widget

if sequence(dir elephant_3legs.e) then include elephant_3legs.e end if 
 
procedure do_user(sequence what) 
  elephant_3legs:gui_interface(what)-- must exist in my elephant_3legs.e 
end procedure 

and elephant_3legs.e must take care of catching invalid procedure calls? Or i need to copy/paste my filename.e into the widget launcher in FAE, with no mistakes? That's ok too, altho an slightly odd name for a widget. But i think you get the idea, i do not know the internals of FAE, so making it happen is up to Ry. I don't want someone to say "i hacked FAE, and now it doesn't work, what a $%^&#$!", because that happened to me and EuBot (why is Creole making a bad link to that?), so i know how it feels.

useless

33. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by useless_ Oct 14, 2013
• 2293 views

if sequence(dir elephant_3legs.e) then include elephant_3legs.e end if 
 
procedure do_user(sequence what) 
  elephant_3legs:gui_interface(what)-- must exist in my elephant_3legs.e 
end procedure 

Ok, make it so it doesn't crash? If elephant_3legs.e does exist, and i don't sequence(dir elephant_3legs.e) then why would it crash? [ad infinitum attack removed by jimcbrown]

useless

35. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by mattlewis (admin) Oct 14, 2013
• 2316 views

I must admit, I'm totally lost. I can't figure out what her requests have to do with FAE. They seem like another round of dynamic code execution ideas that would require a lot of changes to the guts of euphoria, regardless of what other libraries were involved.

Matt

37. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by useless_ Oct 14, 2013
• 2297 views

How is one include line, and one procedure to call user-supplied code, being a dynamic include that involves huge changes to Eu? To me, this smells like the same people putting it down, until 5 years from now when it becomes a good idea and part of an official release, with a different author.

useless

39. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by jimcbrown (admin) Oct 14, 2013
• 2260 views

Agreed. The only, and I mean _ONLY_, way I could see this last piece being vaguely related to FluidAE is if FluidAE was to include a preprocessor that simulated or emulated some of this stuff. Otherwise, it's a complete non sequitur.

The goalposts seem to keep moving also - at first it seemed like the request was the ability to make minor tweaks to the library, then to add custom widgets, then to be able to deal with custom signals/messages, and now dynamic execution.

41. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by useless_ Oct 14, 2013
• 2235 views

FluidAE is a gui. How is using FluidAE to provide gui functions to an app a non sequitur? FluidAE handles what's onscreen and routes the keybd and mouse events, and handles message passing between the widgets, how is that not related to handling what's onscreen and routing the keybd and mouse events, and handling message passing between the parts of a program? Because you say so? Because you want to shut me up?

The goals are the same, the methodology of making it happen changes as you keep saying this or that method won't work.

useless

43. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by useless_ Oct 14, 2013
• 2335 views

I know what a non sequitur is, no need to talk down to me and give a url for something else. You asked a question, i answered it.

useless

45. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by jimcbrown (admin) Oct 14, 2013
• 2241 views

procedure do_user(sequence what) 
  if length(what) < 1 then return end if 
  call_proc(what[1], what[2..$]) 
end procedure 

If, in addition, you want to use the name of the function for some reason (e.g. metadata purposes, like printing out the name of the function in debug code if an error happens), here's a good way to do it:

procedure do_user(sequence name, sequence what, integer rid = routine_id(name)) 
  call_proc(rid, what) 
end procedure 

Then, in your code you can just pass in the name and stuff, without any need to call routine id directly.

47. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by ne1uno Oct 15, 2013
• 2235 views

I ran the demo on a 2.7g single core Xp and startup was around 5 seconds. if you're online at the time or computer is doing something else there can be a lag, (as you know) you have to run multiple tests to be sure. turn off CPU sucking apps! check the task manager. using some version of eu41.

translated, the demo starts before you can move away from the icon you just double clicked. before I can start counting. That is plenty fast. and less than 2 meg uncompressed. this is massively light weight compared to some others, even those that depend on external dll.

with win32lib there is no mistaking how long that takes to start up. or how long it takes to translate.

thanks for putting this together. I have tried some early versions of FAE and hope you can get back to the virtual OS part, time permitting.

what about serial port/joystick input? or is that in the proprietary extended version?

49. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by ryanj Oct 15, 2013
• 2227 views

That's good to hear. I haven't had time to do much performance testing yet.

I do want to add multi-process communication. As far as joystick input, I don't know how to do that. If someone wanted to help with that....

51. Re: Fluid Application Environment 3.0.alpha1 Released!

• Posted by ne1uno Oct 15, 2013
• 2313 views

fluidAE demo on eeepc w/atom1.6g Xp only slightly slower around 8s interpreted w/eu41 and runs translated ok too.

the splash screen has time to dissapear before the app is fully populated. this is not really a problem.

also, the startup time can be deceptive. something in the win32 api must need to get initilized on the first run maybe some obscure dll are loaded but stay accessible.

the 2nd run starts up faster and populates widgets faster. making testing timeing on multiple runs a bit of an estimate.

the text size is much better on the eeepc for some reason. I have larger screen resolution there.