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

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.

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

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.

@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

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.

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:

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:

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

http://wiki.freepascal.org/CudaText

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

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.

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?

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

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

Sorry if I did not make this clear…
forGL IDE needs to run on a wide variety of platforms, especially phones, smart phones and tablets. A heavy weight IDE would be a barrier to anyone that is not already a developer with a laptop or desktop.

@ibilon
I like the spirit of your suggestion but…
I don’t see VS Code running on Android or Windows Phone or Mac Phone.
forGL is aimed for maybe non technical and likely non English speaking Users.
I would have a problem recommending a solution that did not fit more platforms and typically took 1/2 Hour or more to install even by experienced technical users and took GigaBytes of storage and (scariest of all) triggered a Windows OS Restore point as part of the Install.

@Kyliathy
It may be that JS will be the only solution for dumb phones.
For smart phones I would much prefer a native app.
Its nice that Node.js is finally catching up to using Web Worker(s) but I already have a WW without needing Node.js so I do not see a compelling reason to add a Dependency on a JavaScript specific library I did not use before.

@Matt
Thanks for the info about Lazarus JSON interface.
I would prefer to have a single app for smart phones and tablets rather than 2 or more.
So first choice would be something in a Haxe generated target language rather than Pascal. For Laptops and Desktops I did consider a Client / Server approach but for now simplicity is favored.

forGL IDE would look like…
Similar to Any programming language IDE.
Like Haxe Develop or Visual Studio Code or whatever.
Area for source code typically at Left side
Colored text of the forGL code showing if Verb, Noun, whatever

At Right would be Dictionary view or File view or Project View
like Haxe Develop or Visual Studio Code
Dictionary view is something specific to forGL and would Help with Editing and maybe Running.

Bottom would have status area.

When Interpreter is Running:
Output of User code.
Display of Data, Operator and Noun stacks. (Interpreter internals)
Call Stack, (Verb calls another Verb)

Maybe an area for Breakpoints.

And what kind of (and how much) data has to be shared ?

Data would be almost entirely Text for now. Parts of the Text may be marked up with Noun, Verb or other info as described before. For simple apps I do not expect a lot of Data needs to be rendered.
BUT when more capable applications Run with their own text UI or GUI or even 3D GUI then I expect perhaps quite a bit more Data. Depends on how smart the GUI is about rendering. Somewhat similar to the IDE or IDE / Debugger you use when working on / Debugging your own Graphics game or application.

At the point where forGL allows user code to create and Run their own UI then having the Output be in an entirely separate window and not just a part of the 4GL IDE makes a lot of sense. I think forGL will support dynamic UI or GUI creation likely before forGL supports most of our Natural Languages (in a simplified way).

Thanks for your thoughtful suggestions!

Are you sure you’re talking about Visual Studio Code here (rather than regular Visual Studio)? VSCode is rather lightweight in terms of install size, and I’m not aware of it creating any system restore points either.

Sorry, I guess I described VS 2017 Community edition.:slight_smile:
BUT
Need to support various phone and tablet platforms that I do not think VS Code will actually run on.
User needs to be able to use forGL IDE even when phone Not Connected to Web as is found in various countries in Africa where Web time is expensive compared to average wages.
So claiming VS Code will work because it supports Remote Debug does not apply in the Not Connected case.

Thanks for calling me out! They say the first thing to go is Memory, Forgot what was next :slight_smile:

Since you’re focusing on mobile, have you considered https://www.nativescript.org?

NativeScript lets you code in either pure JavaScript, or transpiled from typically TypeScript, but I do not see any reason why JavaScript transpiled from Haxe wouldn’t work.

And even though you code in JavaScript (or TypeScript, or Haxe) and style in CSS, the resulting Android / iOS app (and in the near future: desktop Electron app) is actually running NATIVELY, and emphatically NOT in a web view, unlike PhoneGap / Cordova based solutions like Ionic etc, resulting in native speeds.

There is very mature support for Angular and Vue.js, but you can just use JavaScript without these frameworks if you wish.

For the text editing part, I’m not sure whether there’s a good editor component available, but you could alternatively use the https://microsoft.github.io/monaco-editor inside a web view in NativeScript (there’s loads of web view components available for NativeScript).

Monaco is the editing component in VS Code.

Again, all Free and Open Source.

Let me know if you need more help :sunglasses::grinning::love_you_gesture:

Oh, it seems that Monaco doesn’t work on mobile, but maybe a simpler editor can work.
I found the following seem to work on my old crappy mobile:

I would just chime-in that (IMHO) “node.js” – and JavaScript in general – is massive overkill. (Literally “massive.” The library itself is huge.) I think you want a native user-interface option.

My frank opinion – and it is just that – is that “JavaScript, like Java, has no proper place in a mobile environment.” JavaScript tosses mountains of source code on top of what ought to be a very simple application requirement. It puts an interpreter and a runtime where it doesn’t belong. It also represents a mass of mission-critical-to-you software that you don’t have any control over – their developers can, and will, “do as they damn well please” without warning, just because somebody somewhere decided that something was “cool” and something else was “deprecated.” And, with ES6, the language itself(!) is getting worse. Whereas, Haxe lets you build a native alternative for each target platform, and that IMHO is what you ought to do. “Lean and mean.” (People who don’t use Haxe can’t do that. Since you do, make the most of it.)


Yes, you can integrate these UIs into a 3D application, much as you would any other application, but you might have to build-out some “wedges” to make the two pieces of software work together the way you want them to.

Check simple mobile IDE: https://scormpool.com/luastudio
Written on Haxe. Project DB based. Can be exported. Not opensource but you can get an idea what you can do with Haxe.