# GUI Framework or API Suggestions for IDE of forGL in Haxe Please
**URL:** https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576
**Category:** Haxe
**Created:** [March 3, 2019, 5:33pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576 "2019-03-03T17:33:09Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@RMax](https://community.haxe.org/u/RMax)
#### Post date: [March 3, 2019, 5:33pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/1 "2019-03-03T17:33:09Z")
**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.
_ **Requirements:** _
Able to Run on
Android, Windows Phone, Windows, Linux, Mac OS, perhaps others
Have a good working code interface available in **any** of:
**C++, Java, JavaScript, Python (reluctantly C#)**
Seems likely to me to have JavaScript plus 1 other language support needed.
_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.
**For GUI**
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 support**
**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.
IF GUI is already implemented as being within the Haxe **std** library (not JavaScript here), having a **Logging feature to write out physical files** either supported or known to work with GUI would be nice.
**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.
**Thanks!**
---
### Author:  [@elsassph](https://community.haxe.org/u/elsassph)
#### Post date: [March 3, 2019, 7:50pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/2 "2019-03-03T19:50:22Z")
Something like Xamarin maybe would fit the bill.
(Oops C# 😄)
---
### Author:  [@RMax](https://community.haxe.org/u/RMax)
#### Post date: [March 3, 2019, 8:06pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/3 "2019-03-03T20:06:17Z")
Thanks for you input!
Right now I will wait and see what other approaches are suggested.
---
### Author:  [@Kyliathy](https://community.haxe.org/u/Kyliathy)
#### Post date: [March 4, 2019, 7:46pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/4 "2019-03-04T19:46:09Z")
I may be a bit out of the loop here, but last time I checked, Xamarin didn’t get such great reviews. I also am looking for a cross platform GUI framework and my current top choice is React Native.
Regarding Xamarin and React, here are some comparisons from the interwebz 🙂
> **[React Native vs. Xamarin: Answering the Million Dollar Question - DZone Web Dev](https://dzone.com/articles/react-native-vs-xamarin-answering-the-million-doll)**
>
> A developer discusses the popular React Native and Xamarin frameworks for mobile application development, comparing how each stacks up in a dev environment.
> **[React Native vs Xamarin: A Simple 5-Step Guide \[2021\]](https://brainhub.eu/library/react-native-vs-xamarin/)**
>
> React Native vs Xamarin – which will be best for your project? Compare the performance, development speed and market share to make the right choice.
[https://www.codementor.io/stalky00/xamarin-vs-react-native-2018-comparison-guide-for-developers-o6oswmj88](https://www.codementor.io/stalky00/xamarin-vs-react-native-2018-comparison-guide-for-developers-o6oswmj88)
> **[Xamarin vs Ionic vs React Native: differences under the hood](https://cruxlab.com/blog/reactnative-vs-xamarin/)**
>
> Cross-platform Frameworks: Pitfalls, Performance, Development convenience, Integration into OS & existing code
And here’s one that is a bit opinionated but I found that the arguments fit my memories of Xamarin (it’s massive, compiles slowly and just feels like it carries over a rather massive overhead):
> **[Why I left Xamarin behind in favor of React Native](https://medium.com/@reicheltp/dev-diary-4-why-i-left-xamarin-behind-35817ccd07b2)**
>
> The Good, the Bad and the Ugly of Xamarin in comparison to the whole new world of React Native
---
### Author:  [@RMax](https://community.haxe.org/u/RMax)
#### Post date: [March 4, 2019, 8:37pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/5 "2019-03-04T20:37:14Z")
Problem I have with Depending on **JavaScript is total LACK of Threads (Haxe also has this problem).**
I had to do **a fair amount of separating out different start up and clean up steps** Before / After forGL Interpreter runs **to even Get a JavaScript Web Worker to not time out** according to running on FireFox, IE, Chrome on Win7 desktop. So I will likely support JavaScript but likely not my first choice. React principle(s) I like as the tricky change able Data is handled like an Invariant or Const that gets replaced every so often. I expect React Native is an improvement some other JS approaches but still have Browser & JS limitations. BUT I am a newbie with HTML, CSS and JS so perhaps my ignorance is skewing my opinion.
Thanks for the Input!
---
### Author:  [@ianharrigan](https://community.haxe.org/u/ianharrigan)
#### Post date: [March 5, 2019, 8:18am UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/6 "2019-03-05T08:18:37Z")
Im not totally sure i understand that list of requirements in the OP, but maybe HaxeUI might work / be helpful?
[http://haxeui.org/](http://haxeui.org/)
> **[HaxeUI Community](https://community.haxeui.org/)**
>
> Discussions about HaxeUI - a cross platform user interface toolkit with native support
> **[haxeui/haxeui-core](https://github.com/haxeui/haxeui-core)**
>
> The core library of the HaxeUI framework. Contribute to haxeui/haxeui-core development by creating an account on GitHub.
Cheers,
Ian
---
### Author:  [@elsassph](https://community.haxe.org/u/elsassph)
#### Post date: [March 5, 2019, 10:27am UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/7 "2019-03-05T10:27:13Z")
Quite a few good points.
On the JS side:
- React for the UI is certainly worth considering - potentially you can avoid most of the CSS complications and UI code sharing by using `react-native-web` or `ReactXP`.
- Also desktop (e.g. Electron) apps should be able to run background processes more efficiently than using web workers, and there are ways to open multiple (and fully independent) windows.
Otherwise @ianharrigan’s HaxeUI may be the right solution to use native non-JS GUI widgets.
@RMax that said do you intend on making your IDE project on mobile platforms? It’s a bit unclear what type of IDE you’re building TBH.
---
### Author:  [@ianharrigan](https://community.haxe.org/u/ianharrigan)
#### Post date: [March 5, 2019, 11:17am UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/8 "2019-03-05T11:17:12Z")
FYI - haxeui works without native also (just incase that wasnt clear). Still not 100% sure what the OP is looking for to be honest - so very well may have misunderstood something.
---
### Author:  [@RMax](https://community.haxe.org/u/RMax)
#### Post date: [March 5, 2019, 3:51pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/9 "2019-03-05T15:51:11Z")
@elsassph
**ReactXP** seems a little better, have you used it ?
@ianharrigan
HaxeUI Core on GitHub “This is an _ **Alpha** _ release…”
I very much appreciate your _Honesty_ about HaxeUI status.
I first looked at Haxe UI about 6 months ago. I thought this looks like a very capable top layer framework to the GUI. But when I look at it now I don’t see a lot of progress towards getting beyond Alpha status.
**Anyone,**
I am trying to be proactive by speculating ahead.
**3D Thinking:**
I expect very strong interest by forGL Users to code & run a 3D app and then Export to Haxe target programming language(s) that will include a 3D style application.
Also forGL IDE may someday use a 3D presentation style.
_ **If I was to choose a Haxe interface to 3D Graphics what would you suggest ?** _
**Thanks for the Info!**
---
### Author:  [@sundialservices](https://community.haxe.org/u/sundialservices)
#### Post date: [March 5, 2019, 4:26pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/10 "2019-03-05T16:26:10Z")
I don’t have a specific suggestion – except to say that I am really not comfortable getting “JavaScript, let alone mountains of JavaScript,” into the picture unless you absolutely have to.
And you really don’t have to. For instance, others have already mentioned **haxeUI**. . .
Now, it would help if you would give us more detail about _exactly_ what this “internationalized 4GL” actually is. Tell us more about how it has been constructed . . . of course without giving any secrets away.
---
### Author:  [@ianharrigan](https://community.haxe.org/u/ianharrigan)
#### Post date: [March 5, 2019, 5:35pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/11 "2019-03-05T17:35:24Z")
@RMax - yeah, of course - fair points. It is in alpha, and although it _does_ look like its stalled, development in `new-component-method` branch is where all the activity is happening (ie, master is on 775 commits and the new branch is on 1,249) - and that will form the basis of the first official `v1.0.0` release.
Its a little crappy really that GH doesnt show you that in the activity “heart beat” graph (though i get why that is the case - noise)
That all said and done, i totally understand about reservations about using any framework that isnt “done” (or established) - but i thought i would just put it out there anyway 🙂
Cheers,
Ian
---
### Author:  [@Gama11](https://community.haxe.org/u/Gama11)
#### Post date: [March 5, 2019, 5:42pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/12 "2019-03-05T17:42:18Z")
> Its a little crappy really that GH doesnt show you that in the activity “heart beat” graph (though i get why that is the case - noise)
I think it’s more that GitHub is designed around development happening on the default branch. You can see this with several similar things, such as how PRs always target the default branch by default.
---
### Author:  [@RMax](https://community.haxe.org/u/RMax)
#### Post date: [March 5, 2019, 5:58pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/13 "2019-03-05T17:58:00Z")
**Thanks** to the Haxe Forum!
_ **What 3D specific approach / library / framework would you suggest for a Haxe app ?** _
@ianharrigan
**Thanks.** I have a more “warm and fuzzy” feeling about using HaxeUI now.
Can you say How to use HaxeUI **as part of a 3D application ?**
_ **About HaxeUI:** _
_ **Can anyone share their experience using HaxeUI ?** _
With all of your help I am trying to make a good choice for the GUI approach.
**About forGL…**
_Everything is available:_
If anyone wishes, send me your email through the Message feature and I will send a .zip of all Sources and Build .bat files and Docs. I will try to keep up with emails from the Community about the .zip but my primary focus is publish to GitHub (MIT license) by end of April.
Uses a **Dictionary** of a **.toml** file to Read in at start Word definitions. Words may be defined in various **European languages now** with support for other languages before ver 1.0
Dictionary internally has a few values per Word.
**Word type:** Noun, Verb, Built in Verb, Operator, Choice, Local Noun (local variable)
**Noun** is like Data to Haxians. string, integer, float, bool (all practically identical to Haxe way)
**Verb** is like Code. User types in a Verb definition.
**Verb, Built in** is like a already provided utility. **Show** top value of Data stack for example.
**Operator** (s) are well known Math operators or functions, Punctuation or ( ) { }
**Choice** are flow control keywords like If, else, while, etc.
**Local Noun** is defined only within a Verb. Lifetime is within the block where it first appears.
Each Word type has a different Color so you can see at a glance What the type is.
Other values for Words in a Dictionary are:
**Visible name** what the User / forGL Programmer can use when Editing. May be in any European language.
**Internal name** the English equivalent of the Visible name. Used by forGL.
There is a Parser and Resolver that take Dictionary definitions and build a linear Array of Objects for the forGL Interpreter run time use.
forGL Interpreter is Stack based using **Data** , **Operator** and **Noun** stacks and some other stuff. Having the Stack based approach allows forGL to support nearly any combination of Nouns, Verbs, Operators, in practically any order to support the wide variety of Natural Language(s) orders. Think Prefix, Infix or Postfix notation is up to User.
**For more details of forGL see somewhat long Intro and End post** :
> [@Generate Haxe Source Files From Haxe?](https://community.haxe.org/t/generate-haxe-source-files-from-haxe/1550):
>
> Problem: Need to generate 1 or more Haxe source file(s) using a Haxe program. Haxe sources generated should compile OK. Dependencies of the generated files need to be included in typical Haxe fashion. Approaches: A class name (ex: GenMain) that either already exists within the Haxe to Haxe generator or else is part of a physical file set. GenMain is treated as the output Main class. So GenMain gets renamed and refactored as part of the generation steps. Refactoring as you might guess is wher…
Or I could just send you the .zip 😄
---
### Author:  [@Matt](https://community.haxe.org/u/Matt)
#### Post date: [March 5, 2019, 6:41pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/14 "2019-03-05T18:41:48Z")
For fast developing / prototyping of GUI’ed applications that run on Windows, Linux and MacOSX, you might want to have a look at [http://www.lazarus-ide.org/](http://www.lazarus-ide.org/)
I know Pascal is a rather old language, but it’s easy to learn, and with the Lazarus IDE (itself completely written in FreePascal, as is the underling FreePascal compiler) you can literally put together a user interface in minutes.
There are various components available for text editing and syntax highlighting, already installed as standard on the component palette (the same editor components that Lazarus itself uses; the whole Lazarus project is itself a Lazarus project).
For interfacing with other languages, there are many options available.
Lazarus has a package manager that offers a multitude of 3rd party packages.
The whole thing is, of course, Free and Open Source! 😀🕶😃
---
### Author:  [@Matt](https://community.haxe.org/u/Matt)
#### Post date: [March 5, 2019, 6:47pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/15 "2019-03-05T18:47:08Z")
Here’s an example of a programmer’s editor written in Lazarus:
[http://wiki.freepascal.org/CudaText](http://wiki.freepascal.org/CudaText)
---
### Author:  [@RMax](https://community.haxe.org/u/RMax)
#### Post date: [March 5, 2019, 7:30pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/16 "2019-03-05T19:30:45Z")
@Matt
Thanks for the Input.
I took a quick look and did not find a Haxe interface to Lazarus.
**Perhaps you can tell me of one ?**
I think my reasons for using a Pascal interface with no known Haxe interoperability would be similar to my reasons for using a Visual Basic GUI library.
I do not see a good reason other than FREE and OPEN SOURCE ! ! !
I am looking to find an already working with Haxe approach.
As I fit the Role of “_ **Typical Lazy Software Developer** _” I am not seeking to Develop / Build / Test / Debug an interface to some GUI that may be quite nice or may be significant problems for what I need to do. _ **I guess Risk Adverse should be added to Lazy…** _
---
### Author:  [@Matt](https://community.haxe.org/u/Matt)
#### Post date: [March 5, 2019, 8:15pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/17 "2019-03-05T20:15:11Z")
Hi,
I guess it would very much depend on what that interoperability would have to look like!
If merely passing JSON objects between a Lazarus executable and Haxe executable would be sufficient, then you could simply have a server instance running in your Lazarus app, and your Haxe client would communicate with that (or vice versa).
If you need to have all of your Haxe objects and classes available in the GUI because of a tight coupling, then yeah, it’s not going to work like that…
It all depends on what exactly you need.
---
### Author:  [@Matt](https://community.haxe.org/u/Matt)
#### Post date: [March 5, 2019, 8:16pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/18 "2019-03-05T20:16:39Z")
Could you be a bit more specific about what your GUI / IDE should look like?
And what kind of (and how much) data has to be shared?
---
### Author:  [@ibilon](https://community.haxe.org/u/ibilon)
#### Post date: [March 5, 2019, 8:19pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/19 "2019-03-05T20:19:02Z")
An alternative to coding a full ide, you did say you were a lazy developer 😉 would be to code a plugin/extension to an existing one.
For instance visual studio code, it has haxe externs [GitHub - vshaxe/vscode-extern: VS Code API externs for Haxe](https://github.com/vshaxe/vscode-extern) and is fairly extensible.
---
### Author:  [@Kyliathy](https://community.haxe.org/u/Kyliathy)
#### Post date: [March 5, 2019, 8:31pm UTC](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576/20 "2019-03-05T20:31:54Z")
@RMax regarding threads:
Even though JS can’t really do threads, there are a lot of technologies that allow to go a part of the way, for example check this one about NodeJS.
> **[Node.js multithreading: What are Worker threads, and why do they matter? -...](https://blog.logrocket.com/node-js-multithreading-what-are-worker-threads-and-why-do-they-matter-48ab102f8b10/)**
>
> Node.js v10.5 introduced the worker\_threads module, and it has been stable since Node.js v12 LTS. But what are Worker threads, and why would you need them?
If you really want client-side multithreading, perhaps contributing to Haxe CPP could be an option 🙂 From what I understand, the CPP target is well-maintained so you could get help getting pull requests in.
And since Haxe is fairly extensible, you could use some macros to facilitate weaving your multithreading code. Or perhaps even contribute to the haxe compiler itself. Your knowledge of compilers seems solid and in a small community, every little bit helps.
All I’m saying is that I feel like this community is able to sustain and help bring forth functionality required by users, especially if the users get involved as well. I intend to contribute as well, as soon as my May project “deadline” passes.
@ibilon well said.
@RMax Haxe already has good integration with the Visual Studio Code IDE so if piggy-backing on that sort of GUI framework (based on Chromium) suits you, you should definitely consider it.
You could also write an IntelliJ plugin, there already is a Haxe plugin for it. Both the maintainer of the IntelliJ Haxe plugin and those of the VS Haxe Code plugin seem very available for contributing to their repos and very helpful and engaged.
However, IntelliJ is probably further from mobile than VS Code, which is based on Chromium, which works on mobile.
[Next page](https://community.haxe.org/t/gui-framework-or-api-suggestions-for-ide-of-forgl-in-haxe-please/1576.md?page=2)