GUI Framework or API Suggestions for IDE of forGL in Haxe Please

1

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 :slight_smile:

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!

2

Something like Xamarin maybe would fit the bill.
(Oops C# :smile:)

3

Thanks for you input!
Right now I will wait and see what other approaches are suggested.

4

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 :slight_smile:

https://www.codementor.io/stalky00/xamarin-vs-react-native-2018-comparison-guide-for-developers-o6oswmj88

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):

5

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!

6

Im not totally sure i understand that list of requirements in the OP, but maybe HaxeUI might work / be helpful?

http://haxeui.org/

Cheers,
Ian

7

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.

8

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.

9

@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!

10

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.

11

@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 :slight_smile:

Cheers,
Ian

12

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.

13

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:

Or I could just send you the .zip :smile:

14

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/

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! :grinning::sunglasses::smiley:

15

Here’s an example of a programmer’s editor written in Lazarus:

http://wiki.freepascal.org/CudaText

16

@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…

17

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.

18

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?

19

An alternative to coding a full ide, you did say you were a lazy developer :wink: 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 and is fairly extensible.

1 Like
20

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

If you really want client-side multithreading, perhaps contributing to Haxe CPP could be an option :slight_smile: 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.