GUI is Default Requirement.
Text style UI may be OK only for some more limited platforms.
Need a GUI interface to support IDE of an internationalized forGL written in Haxe.
IDE to have several built in windows AND with at least another window created dynamically as forGL code running output.
Good if created dynamic window is independent from IDE windows.
Must be able to support languages other than English.
Not a Graphics oriented Game. High Performance not required but nice if available.
Able to Run on
Android, Windows Phone, Windows, Linux, Mac OS, perhaps others
Have a good working code interface available in any of:
Perhaps you would suggest ?
Working code samples of how to use various features OR at least more than sketchy documentation.
Must support UTF8 text encoding on input and output.
Must support various languages for Control names, labels, etc. and not just English dynamically at run time. Visible Names and Labels, etc can change dynamically.
Must support a minimum of 8 Colors (unless display does not)
Able to create Graphical or text windows dynamically at run time.
This includes not only a drawing / rendering / text out area (or Canvas or whatever) but also graphical or text controls, Text entry, Buttons and Sliders at minimum.
Able to allow User input (mouse, touch, keyboard) on graphics/text area or on dynamically created controls.
Able to allow drawing various simple 2D primitives via API by program.
Very Good to Have (Close to being a Requirement)
Support for at least 2 separate sets of rendering areas. forGL IDE would use the first set (and maybe others) AND the code written by a forGL User/Programmer would use the second set. Like what you see now when you use an IDE to Run / Debug your programs.
OK if forGL application needs to create 2 instances of GUI (one for IDE and one for Running output) as long as no conflicts between instances.
In the same way that Comments by forGL User/Programmer may be Export to Haxe code:
Have a way that the GUI API interfaces may be dynamically inserted as part of the Export. My first guess is that something like the “Comments in Haxe” approach will work for Graphics API calls also. This is something I will work on but include here for info.
I would describe the API interfaces in forGL terms so that Users/Programmers can declare WHAT they want done and forGL + the API supports HOW it happens. Translation of API interface commands in forGL to languages other than English will be the main responsibility of the forGL project. But please consider there may be a side effect that the GUI APIs (or Framework or whatever) web site may be visited by many people not fluent in English.
Nice To Have Bonus Features
Ability to Import and Export graphics in a well known fairly device independent standard.
SVG seems like a good choice, perhaps you have a better idea ?
Eventual goal is to have a Semantic markup included (with run time substitution of localized text) as part of the Graphics representation. Idea like Words AND Pictures.
A way to share (Import and / or Export) render surfaces (Canvas or whatever) To / From
R, Jupyter Notebooks, Julia, Python, or your suggestion ?
Use of available GPU.
Bonus if GPU can be accessed by general purpose Haxe code and not just for Graphics rendering.
3D + Time support (maybe a Slider control for the Time (forwards / backwards)
GUI may support more than 1 instance of forGL Interpreter.
GUI acts a little like a Graphical server to multiple forGL Interpreter clients.
Small Code Size and Reasonable Performance
There, I give 2 conflicting Design Requirements
Not Interested In Curses Approach
MS Windows Cmd.exe does Not support ANSI Escape sequences (at least on Win 7 and 10) so current Workaround on Windows is to use ansicon AND I do not really want to stay with text mode only output.
Your Suggestions will help very much Goal of me to publish forGL IDE this month.