1. FluidAE: the next step

• Posted by ryanj Oct 16, 2013
• 2587 views

Thanks for the feedback on the first release alpha release of FluidAE 3.

After some discussion and thinking about some of my original goals, I would like to explain some things that I plan to add by the time FluidAE 3.0 Final is released. Any thoughts or ideas about this would be appreciated.

---

General

Multi-process Communication

I would like to add an easy-to-use api for multiple processes to communicate, whether on a single core, multiple cores, or even separate computers. Also, I'm considering a way for dlls to be loaded on demand, which can communicate (suggested by Kat), just like separate processes. This will basically make FluidAE a multi-tasking multi-application environment, with various configurations. It could be as simple as one EXE file, or as elaborate as multiple components that get launched as processes, or dlls, or connected to over the network. Multiple applications (include files, processes, or dlls) could work together on a single instance of a GUI, saving resources.

Cross-platform Support

Currently, only Windows is supported, but, I plan to add support for linux. I'm not sure if it will be x-windows, XCB, or GTK.

GUI Module

Common Dialogs

I will add a collection of common dialogs that any application can easily use. These will help reuse code for common things like: splash screen, color selection, “About FluidAE” to (display version info), the Debug Console, a basic question/information dialog, find/replace, etc. These can also be useful as templates for designing your own dialogs. I will also make a wrapper for the File Open/Save system dialog.

Themes, System Preferences

Eventually, there will be a theme system to customize the look of widget classes and change colors and fonts. There will be a standardized way of loading icons used for things like mouse pointers, buttons and list items. System preferences such as system colors, font size, and date/time format will be accessible, too. By the way, did you notice the custom mouse pointers that FluidAE uses?

Canvas Widget Class

I decided to change the name of “document” widget class to “canvas” because it seems to be a more accurate description. A “canvas” lets you draw a background and a foreground (using a sequence of simple drawing commands), and define handles that the application can use to respond to keyboard/mouse events. Handles can be any shape you want, not just rectangular areas. They are identified by drawing each handle's shape on an invisible bitmap. Each handle has a unique color assigned to it. Whichever pixel color is at the mouse coordinates identifies which handle the mouse is over. By responding to Handle events, the application has complete control over how the canvas looks and behaves, so it can be used for all sorts of things, like: Word processor, vector drawing program, CAD, image, chart, calendar, etc. This is what I'm currently working on.

Additional Modules

Document Module

The GUI is a “module” in FluidAE. I'm going to add a Document module, which will provide a standardized way of editing the data of a document (whatever type that may be: formatted text, CAD drawing, vector drawing, MIDI file, etc.) using a set of commands, which the application defines. These commands can then be called from the application (usually triggered by GUI widget events, such as clicking on buttons in a toolbar, or on menu items). The commands would modify the document's data in a controlled way, so that the application doesn't have to deal with the internal document sequences directly. There would be an integrated undo/redo engine, too. The application could then have a collection of customizable toolbars with buttons, menus, etc. that let the user execute commands with a click of the mouse. Or, when canvas handles send events to the application (dragging something on the canvas, or pressing keys) it can execute commands to modify the document (insert text at the cursor location, or move a node on a spline curve object, for example).

Printer Module

I want to add the ability to print documents to a printer, using the operating system's print API. I don't know how to do that yet, but it needs to be done.

---

As you can see, when FluidAE 3.0 is finalized, it will be more than a widget toolkit. It will have pretty much all the tools you need to make the entire GUI for a serious application in a way that is modular, well-structured, and easy to develop. Rather than simple hacked-together utilities, you could make full-featured applications, with customizable toolbars and properties panels. Imaging being able to make things like this in Euphoria: diagram editor, image gallery, database front-end, email client, irc client, word processor, PCB editor, or a MIDI file editor. It is my dream that FluidAE will let you at least make the GUI for things like that.

3. Re: FluidAE: the next step

• Posted by useless_ Oct 17, 2013
• 2485 views

Doing that to executeable code on windows OS would imply control over the use of executable DLLs by other processes under control of Ry's FluidAE. This is well past my suggestion that DLLs be loaded/used/unloaded under program control. Euphoria already has associated memory for data sharing, but as far as i know it isn't lockable unless the app using the memory sets up some semaphores for itself. Neither does it allow for use of executable Euphoria code, altho i seem to remember someone made it possible for machine code to be stored and retrieved and executed from shared memory. This also seems to imply that your apps plug into FAE (my suggestion), not that FAE is an include in your apps (Ry's original intent). Could you elaborate and clarify?

useless

5. Re: FluidAE: the next step

• Posted by Lone_EverGreen_Ranger Oct 20, 2013
• 2162 views

I think FluidAE has a lot of potentional. I haven't looked much into it, but I plan to. I think it will be a very good toolkit for Euphoria. I hope the project is developed further and will mature over time.

7. Re: FluidAE: the next step

• Posted by jimcbrown (admin) Oct 29, 2013
• 1955 views

Seconded.

9. Re: FluidAE: the next step - Interprocess communication

• Posted by jimcbrown (admin) Oct 29, 2013
• 1988 views

I'm interested! *waves flag*

11. Re: FluidAE: the next step - Interprocess communication

• Posted by raseu Oct 29, 2013
• 1940 views

Done.

Should appear in archives at rapideuphoria.com in a few hours.

ras

13. Re: FluidAE: the next step - Interprocess communication

• Posted by raseu Oct 29, 2013
• 2177 views

Available from here ( http://www.rapideuphoria.com/uploads/libzmq.zip )
until appears in archive.

ras