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

21

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!

22

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.

23

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:

24

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:

25

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:

26

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.

27

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.

28

All, Thanks so much for your suggestions!

Not focusing on Mobile but not going to make Mobile less capable than it is now.
I do Not want to use something that does not fit Mobile well.

@codeservice Thanks for the Input!

@sundialservices Agree. I think JavaScript is OK for limited Web stuff but still in the style of a 20th century programming language instead of 21st century.
Serial code only, poor / non existent type checking, forced use of Objects, etc.

Anyone have experience using HaxeUI for a project ?
Any impressions / details would be much appreciated.
Thanks!

29

With all due respect, that’s nonsense.
JavaScript has been supporting functional programming concepts for a long time now.
Modern JavaScript programming very much involves things like higher order functions, e.g. in the case of callbacks, promises, etc.
Modern-day JavaScript programming is littered with monads.
Even if no one realises they are monads.

30

@RMax I’m using HaxeUI for a desktop medical application I’m developing. Quite happy with it. Honestly, I can’t imagine using any other UI framework for my particular haxe work. Is there anything in particular you’d like to know about my experiences thus far?

31

All,
I guess the “find the API that Randy will accept” contest is over!
HaxeUI is the contest winner!

@intoxopox
Thanks for the HaxeUI recommendation.
Sounds like you are trying to help make the world better!

@Matt
My apology as I see I was not completely clear.
I still reserve the right to post nonsense after this…
I think I understand that me saying something is Serial when you see the variety of what JavaScript offers does not fit your idea of Serial as execution jumps around to Callbacks, Event Handlers, etc.
But I think Monads or Callbacks or Event Handlers in this context may be missing my point.

Calling something Functional does not automatically promote somehow out of Single Thread (what I call Serial as opposed to Parallel) without really taking advantage of the multiple general purpose CPU cores and the many multiple GPU cores. Like 21st century Hardware provides. It is the so called 21st century Software that I find lacking (including my own). And perhaps there is a scheduler somewhere that runs in a separate Thread. But if the result is still only a single CPU doing the work of our own application code I would call this a Serial solution. Actually Callbacks and Event Handlers “just” add some rather non deterministic behavior to a likely already challenging software environment.

I am more interested IF 2 or more actual Threads really Run on 2 or more CPUs at the same time doing different sections of Code within a single application. As far as I can tell at least for Browser hosted HTML hosted JavaScript, you get 1 main Thread. The main Thread gets flipped around to various fragments of JS code when an Event fires and then a Callback runs and then back around somewhere else. To get anything else At the Application Level to run at the same time then Browser + JS asks you to create a Web Worker. So until Web Workers are created automatically by using a JS Thread API, I think JS is a Single Threaded and therefore Serial (not Parallel) approach.

FYI Been Dangerous with Events & Callbacks since Win 2.x

1 Like
32

But a single thread is easier to manage than multiple threads…
Having to deal with mutexes etc to protect shared state is a pain in the neck.
By all means, use threads if you must, but I’d recommend using a single thread if you can.

33

And if you’ve taken a look at ES6, it just got worse. A brand-new language, piggybacking on the “JavaScript” name (just as “Perl-6” piggybacked on the “Perl” name).

JavaScript / HTML5 methods might be necessary for the web, but they’re not called-for in mobile deployments. There you want native performance … “lean and mean, and no Big Phat Libraries™ anywhere in sight.”

Thanks to Haxe, you can have that . . . :smiley:

1 Like