Page 1 of 1

Cross-Platform Libraries to Wrap

Posted: Thu Nov 11, 2021 1:43 pm
by OpenXTalkPaul
I'm going to use this topic to keep a list of free open source cross-platform libraries to potentially wrap with Builder.

RayLib - A game engine, there's a thread about this, sort of already started to wrap it.

Lau. How about a whole other scripting environment embedded into OXT? Lau is not an xTalk, but it is highly readable in my opinion, fairly easy to learn. I used the LSL variation of Lau for a bit back when I played around in "SecondLife".
Lau is made to be embedded into other things. It's often used as scripting language for Game Engines.
I read somewhere that someone made a Rev/LC External a long time ago that embedded Lau.
http://luabinaries.sourceforge.net

LibUV ... Is the Async oriented library that Node.js is built on top of! This could be extremely useful for lots of things, particularly multi-tasking long running tasks such as downloading a bunch of data from multiple sources for example.
http://docs.libuv.org/en/v1.x/

Re: Cross-Platform Libraries to Wrap

Posted: Thu Nov 11, 2021 6:12 pm
by xAction
Oh I found one last night:
GIF Encoder - This is a small C library that can be used to create GIF animations.

Let'see what are we really missing:
Audio production, ie, making noises from thin air/code
Accelerated Graphics
3D
---------------------------------------
Fast web ...apps, raylib should get us there, at least from what I see in the demos. via webassembly.
However, translation of the OXT standard desktop gui elements to a web gui is going to be another trick
And the trick is available via WebGui
Imgui already has some bindings for raylib and lua already so we can probably tie it all up in a nice little bow.

Not sure if Libsynth covers this, but we should be able to produce sounds from the IDE.
PortAudio is a free, cross-platform, open-source, audio I/O library. It lets you write simple audio programs in 'C' or C++ that will compile and run on many platforms including Windows, Macintosh OS X, and Unix (OSS/ALSA). It is intended to promote the exchange of audio software between developers on different platforms. Many applications use PortAudio for Audio I/O.

While we are adding scripting languages to our scripting language Python is super duper popular.
Javascript

That would open the door to
Visual coding interfaces.
Google Blockly
Scratch
Although we could theoretically use Scratch blocks as widgets to do it all in OXT

Speaking of that, taking the learning curve out of Builder would be a huge bonus.

I found a builder widget that allowed manipulation of SVG text, but to make it useful I'd have to rewrite like 300 lines of code, after extracting and parsing the paths from the SVG fonts I want to use.
There should be a UI for that kind of thing, shouldn't need to reinvent the wheel everytime you want to add a widget.
Here's SVG export library
A Raster to SVG conversion library

Want to run/compile C from in OXT apps? Embeddable libCork might be the thing, if I understand what I'm reading.

XD, Sketch, ..UIX apps, I can't find specific libraries for parsing their files, they probably all spit out JSON/Javascript/CSS/HTML. I did find this for Adobe XD
Just thinking we might want to be able to entice UIX designers to OXT with a direct path.
But 9 to 10 odds they are going direct to web/mobile via Javascript.
I can't find a library that spits out CSS from some other data like a bunch of text boxes and graphics.

So V8 is for embedding Javascript in C++ programs, some old stackoverflow posts says Apple won't allow it on their store.

Play old video games with libMame?

How feasible is it to make OXT an embeddable language?

How Retro are you? Are you Final Cut Retro?
FINAL CUT is a C++ class library and widget toolkit with full mouse support for creating a text-based user interface. The library supports the programmer to develop an application for the text console. It allows the simultaneous handling of multiple text windows on the screen.

I can't find much else that seems of use. I skipped over neural networks and aritificial intelligence stuff since I don't know what how it could be applied. But there's libraries out there for that. Sure is a crowded market out there.

If anything, making it possible to make drag and drop scriptable GUI applications with multiple scripting languages seems like it'd be useful. There's a lot of gui frameworks but they all come from a programmers perspective , ie,
drawButton(10,10,50,20 "My Button) bla bla bla. Anyway supporting mobs of languages is a nightmare for another day.

This wikipedia page needs an update I think

Re: Cross-Platform Libraries to Wrap

Posted: Fri Nov 12, 2021 12:20 am
by Paul
I would think one could create a library to do that in the engine's native script, but it might be quicker / easier to wrap a small portable lib that already does that.
Let'see what are we really missing:
I think everyone is going to want different things added.
[/quote]
Fast web ...apps, raylib should get us there, at least from what I see in the demos. via webassembly.
However, translation of the OXT standard desktop gui elements to a web gui is going to be another trick
And the trick is available via WebGui
Imgui already has some bindings for raylib and lua already so we can probably tie it all up in a nice little bow.
If your target is the web, you might just want to use that GUI dev tool that they've already made for building things with RayLib. To be honest if I was going work on wrapping a game engine for scripting with OXT, it would probably be SDL2.
Not sure if Libsynth covers this, but we should be able to produce sounds from the IDE.
PortAudio is a free, cross-platform, open-source, audio I/O library. It lets you write simple audio programs in 'C' or C++ that will compile and run on many platforms including Windows, Macintosh OS X, and Unix (OSS/ALSA). It is intended to promote the exchange of audio software between developers on different platforms. Many applications use PortAudio for Audio I/O.
Do you mean libFluidSynth? FluidSytth is like a virtual MIDI Instrument that plays MIDI data using Sound Samples from SoundFonts files. It pipes sound that it generates to various Audio back ends (which depends on what's available on the platform it's running on) or into PCM samples in a file (wav, AIFF, raw pcm, etc. and uses libSndFile to do that which makes libSndFile a dependency of FS). Some of the backends it can use for sound out are PortAudio, ALSA, Apple's CoreAudio, etc. too.
If you want a lib for creating wave samples from like quadratic equations and whatnot then maybe look at C-sound (which has been around for decades)
While we are adding scripting languages to our scripting language Python is super duper popular.
Javascript
V8
Apple won't allow it on their store.
No Apple is no longer about making life easier for regular people to use computers, now they're a consumer product company that's all about keeping a closed system that they control as gatekeepers.

I'm not specifically looking to add other scripting languages, and we can already do some things with JavaScript. I'm pretty sure that v8 is basically the JS engine in CEF that's already used by Browser Widget on Win/Linux).
I was only looking a Lau because it's small and can be easily embedded, and It's easy.
I'm not sure Lau would add much to this platform, although a quick look at what's available with Lau it seems there's a few Lau libs that might be useful to me.
Speaking of that, taking the learning curve out of Builder would be a huge bonus.
I don't think it's possible to take learning curve out of Builder entirely, because of it's nature in being a middle-ware language it has elements of lower level languages such as statically typed variable. Now I do think it could be MUCH MUCH Better, as far as documentation and it could be greatly expanded with new language utility handlers and library modules that would make using it much easier by virtue of not having to invent the wheel because someone didn't think it was important to invent the wheel in Builder before releasing it to the public. What I mean by "Invent the Wheel" would be handlers like

Code: Select all

widgetPointToCardLoc(in pWidgetPointH as Point, in pWidgetPointH as Point) returns string
I found a builder widget that allowed manipulation of SVG text, but to make it useful I'd have to rewrite like 300 lines of code, after extracting and parsing the paths from the SVG fonts I want to use.
There should be a UI for that kind of thing, shouldn't need to reinvent the wheel everytime you want to add a widget.
Here's SVG export library
A Raster to SVG conversion library
Builder uses the Google's Skia drawing library as it's 2D rendering. You can do some neat stuff with it without adding another SVG library. However, I would be interested in something like an SVG Utility library, that could do things like extract path data from fonts and return the data as SVG path for use in a Widget. I was thinking of writing some scripts to extract the paths from layered, exported SVG 1.1 from Adobe Illustrator. I'm currently manually cutting/pasting the paths from the XML fields with a text editor.
Want to run/compile C from in OXT apps? Embeddable libCork might be the thing, if I understand what I'm reading.
Not particularly, I find C cryptic and ugly, but if it can add something useful for our Scripting language then yes.
Play old video games with libMame?
I'd go for libRetroArch which can use variations of libMAME cores (MAME2003, MAME2011, FBA, etc.), and a whole lot of emulator cores for other hardware. Mostly you can use emulators already with shell() or open process and passing the proper command line switches and such. I did make my own front end for my arcade cabinet in LC, and some utilities for using RetroPi / EmulationStation too. At one point I spent some time trying to mimic EmulationStation's UI in LC (sort of worked)

Code: Select all

How feasible is it to make OXT an embeddable language?  
You could already embed the command line app into another app, I guess. Do you mean rebuild the whole thing as a libXTalk binary or run on an a project board like Arduino? I don't think so.
How Retro are you? Are you Final Cut Retro?
FINAL CUT is a C++ class library and widget toolkit with full mouse support for creating a text-based user interface. The library supports the programmer to develop an application for the text console. It allows the simultaneous handling of multiple text windows on the screen.
Test based interfaces? YUCK! No Thanks!
I can't find much else that seems of use.
---SNIP---
There's a TON of libraries out there. I'm mostly just looking for small, easily wrapped libs that can fill a gap in OXT's capabilities. For instance I wanted to use HID Gamepads and input devices, so I found and wrapped HIDAPI and now I can use a Playstation Controller via script in my stacks.

Re: Cross-Platform Libraries to Wrap

Posted: Sat Nov 13, 2021 1:32 pm
by xAction
To be honest if I was going work on wrapping a game engine for scripting with OXT, it would probably be SDL2.
SDL2 does not come with a physics engine, every thing you want to do with SDL is another library dependency, images, keyboard, sound, network, fonts, another download, another unzip, another file to parse.

Raylib is one JSON file. Network, images, fonts, sounds, inputs, 3D, windowing.
Oh look even an icon packer.

I did 17 SDL2 tutorials, I had to download libraries, unzip the libaries, move the libraies, tell the Visual Studio project where the libraries were, tell the operating system where the libraries were, rename paths in the files because Visual Studio couldn't figure out that the images were right next to the source code, exclude the current file from the Visual Studio project to run the next file. Bleh.

With raylib, i downloaded it, installed it, double clicked my favorite text editor which it happened to include preconfigured to compile source code, loaded an example, hit F6 and it ran, one example after another, easy peasy.

I wonder if it'd just be easier to wrap Lua and then use Lua raylib wrapper. Oh Lua is 28 unparsed .h files. I'll stick with rayLib.

Re: Cross-Platform Libraries to Wrap

Posted: Sat Nov 13, 2021 11:46 pm
by xAction
PoTrace
Potrace(TM) is a tool for tracing a bitmap, which means, transforming a bitmap into a smooth, scalable image. The input is a bitmap (PBM, PGM, PPM, or BMP format), and the output is one of several vector file formats. A typical use is to create SVG or PDF files from scanned data, such as company or university logos, handwritten notes, etc. The resulting image is not "jaggy" like a bitmap, but smooth. It can then be rendered at any resolution.

Potrace can currently produce the following output formats: SVG, PDF, EPS, PostScript, DXF, GeoJSON, PGM (for easy antialiasing of pixel-based images), Gimppath, and XFig. Additional backends might be added in the future.

Mkbitmap is a program distributed with Potrace which can be used to pre-process the input for better tracing behavior on greyscale and color images. See the mkbitmap examples page.
Get graphics into the app as vectors.

Re: Cross-Platform Libraries to Wrap

Posted: Mon Nov 15, 2021 1:48 pm
by OpenXTalkPaul
xAction wrote: Sat Nov 13, 2021 11:46 pm PoTrace
Potrace(TM) is a tool for tracing a bitmap, which means, transforming a bitmap into a smooth, scalable image. The input is a bitmap (PBM, PGM, PPM, or BMP format), and the output is one of several vector file formats. A typical use is to create SVG or PDF files from scanned data, such as company or university logos, handwritten notes, etc. The resulting image is not "jaggy" like a bitmap, but smooth. It can then be rendered at any resolution.

Potrace can currently produce the following output formats: SVG, PDF, EPS, PostScript, DXF, GeoJSON, PGM (for easy antialiasing of pixel-based images), Gimppath, and XFig. Additional backends might be added in the future.

Mkbitmap is a program distributed with Potrace which can be used to pre-process the input for better tracing behavior on greyscale and color images. See the mkbitmap examples page.
Get graphics into the app as vectors.
This could be an excellent very useful library to wrap since we have several ways to display & use SVG, probably just need to wrap a few suctions and pass it some file paths. Although I personally like to go in after a trace and remove or fix individual points afterwards, it's often possible to get some SVG paths down to an extremely small amount of data with a little bit of manual editing.

Re: Cross-Platform Libraries to Wrap

Posted: Mon Nov 15, 2021 2:21 pm
by OpenXTalkPaul
xAction wrote: Sat Nov 13, 2021 1:32 pm
To be honest if I was going work on wrapping a game engine for scripting with OXT, it would probably be SDL2.
SDL2 does not come with a physics engine, every thing you want to do with SDL is another library dependency, images, keyboard, sound, network, fonts, another download, another unzip, another file to parse.

Raylib is one JSON file. Network, images, fonts, sounds, inputs, 3D, windowing.
Oh look even an icon packer.
One JSON file? For web maybe if that JSON loads some .js scripts, but not for desktop it's not, it's at least 2 library binaries, although they are nice and small. I'm not at all against trying to wrap that with Builder, although I think it would be a bit of work to wrap and adding a game engine can't be a priority for me right now. We would need to get it to render into a widget "native view" (unless it can programmatically make windows on it's own on all platforms?), and then test on different platforms. Still it may be a lot less work than wrapping SDL, although SDL probably has more advantages, it's certainly more popular and has constant active development for decades now for examples.
I did 17 SDL2 tutorials, I had to download libraries, unzip the libaries, move the libraies, tell the Visual Studio project where the libraries were, tell the operating system where the libraries were, rename paths in the files because Visual Studio couldn't figure out that the images were right next to the source code, exclude the current file from the Visual Studio project to run the next file. Bleh.

With raylib, i downloaded it, installed it, double clicked my favorite text editor which it happened to include preconfigured to compile source code, loaded an example, hit F6 and it ran, one example after another, easy peasy.
I don't think this is as much of a problem for a Builder extension, all platform/archtecture specific libraries would be in their respective "code" folder subdirectories and that is where the engine looks first for libraries to load. On macOS SDL comes with the main lib pieces nicely packaged as a single SDL.framework bundle (if you get it from the official download, instead of a package manager).
We wouldn't need to wrap all of it to start making it useful, and some things might not even need to be wrapped for our particular app engine at all, or some things we may want to substitute a different library (such as HIDAPI for game controllers, which I've already mostly wrapped: https://www.youtube.com/watch?v=UElNxSq7r9k&t=438s or OXT Builder FluidSynth for playing background music in it's own threads). I know PyGame, after much years of development still hasn't wrapped all of SDL (which itself is moving target), at least not as part of the base PyGame, but PyGame uses a lot of SDL.
I wonder if it'd just be easier to wrap Lua and then use Lua raylib wrapper. Oh Lua is 28 unparsed .h files. I'll stick with rayLib.
Like I said, you may not need to parse every thing in an .h to make a library useful, you can make bindings for just functions you actually want to use, for what you want to do with it, then as you need more of the library to do something else, you wrap those calls. Wrapping parts as you go makes it a progressive process. Take my macOS Tools for example, it taps a bunch of NSApplication API from Cocoa (some of that might work with cross-platform GNUStep libraries too), I certainly haven't wrapped all of Cocoa APIs, but these NSApp bits I did wrap are very useful for making macOS apps behave like native macOS apps, beyond what the Engine can do without it.

Re: Cross-Platform Libraries to Wrap

Posted: Tue Nov 16, 2021 12:41 am
by xAction
I'm pretty sure if you don't wrap all of Lua into a library you'll end up with errors trying to run scripts and you can't expect the end users to know what's going on with the broken half patched library.

If you're only going to wrap a portion of it, it'd just be safer to run lua through a shell command.

Re: Cross-Platform Libraries to Wrap

Posted: Tue Nov 16, 2021 3:54 am
by OpenXTalkPaul
xAction wrote: Tue Nov 16, 2021 12:41 am I'm pretty sure if you don't wrap all of Lua into a library you'll end up with errors trying to run scripts and you can't expect the end users to know what's going on with the broken half patched library.

If you're only going to wrap a portion of it, it'd just be safer to run lua through a shell command.
I wasn't talking about Lau, I just meant most libraries in general, for example libFluidSynth has a bunch of functions I haven't gotten around to yet, and FluidSynth also loads some libraries it depends on for certain features, like libSndFile which has some useful features on its own that could also be bound to.

Re: Cross-Platform Libraries to Wrap

Posted: Tue Dec 07, 2021 10:46 am
by astu
OpenXTalkPaul wrote: Thu Nov 11, 2021 1:43 pm
Lau. How about a whole other scripting environment embedded into OXT? Lau is not an xTalk, but it is highly readable in my opinion, fairly easy to learn. I used the LSL variation of Lau for a bit back when I played around in "SecondLife".
Lau is made to be embedded into other things. It's often used as scripting language for Game Engines.
I read somewhere that someone made a Rev/LC External a long time ago that embedded Lau.
http://luabinaries.sourceforge.net
Oh... The good old SecondLife-Times... spend many time there...
but LindenLaps changed their LSL-Format to Mono...
But Roblox uses LUA

Re: Cross-Platform Libraries to Wrap

Posted: Tue Dec 07, 2021 12:28 pm
by OpenXTalkPaul
astu wrote: Tue Dec 07, 2021 10:46 am
OpenXTalkPaul wrote: Thu Nov 11, 2021 1:43 pm
Lau. How about a whole other scripting environment embedded into OXT? Lau is not an xTalk, but it is highly readable in my opinion, fairly easy to learn. I used the LSL variation of Lau for a bit back when I played around in "SecondLife".
Lau is made to be embedded into other things. It's often used as scripting language for Game Engines.
I read somewhere that someone made a Rev/LC External a long time ago that embedded Lau.
http://luabinaries.sourceforge.net
Oh... The good old SecondLife-Times... spend many time there...
but LindenLaps changed their LSL-Format to Mono...
But Roblox uses LUA
Really? Mono as in .NET? C#? That's surprising, I would've thought that they would've tried for EASIER!

Re: Cross-Platform Libraries to Wrap

Posted: Tue Dec 07, 2021 1:43 pm
by astu
http://wiki.secondlife.com/wiki/Mono_in ... _scripters

it´s since 2011
....Mono is an open-sourced programming environment in which to develop and run .NET applications. You can find out more at the Mono website. "Mono for Second Life®," which we'll just refer to as "Mono" from now on, is the integration of a new Mono-based compiler and runtime into our Second Life servers.....

Re: Cross-Platform Libraries to Wrap

Posted: Sat Dec 11, 2021 1:35 pm
by OpenXTalkPaul
astu wrote: Tue Dec 07, 2021 1:43 pm http://wiki.secondlife.com/wiki/Mono_in ... _scripters

it´s since 2011
....Mono is an open-sourced programming environment in which to develop and run .NET applications. You can find out more at the Mono website. "Mono for Second Life®," which we'll just refer to as "Mono" from now on, is the integration of a new Mono-based compiler and runtime into our Second Life servers.....
It's been at least that long since I played around with SL.

As much as I hate to admit it, MS made C# fairly good readability wise, at least for their docs. Ironically I've actually looked at their documentation for Apples APIs maybe more than Apple's own docs!

Re: Cross-Platform Libraries to Wrap

Posted: Wed Dec 15, 2021 11:55 pm
by OpenXTalkPaul

Re: Cross-Platform Libraries to Wrap

Posted: Mon Mar 07, 2022 5:06 pm
by tperry2x
[attachment=0]lipo_cmd error.png[/attachment]lipo on OSX, whatever that is.
Never heard of it being needed before, but this appeared when trying to build with LC Community 9.6 on OSX 10.13

I don't have the developer tools, but no idea what this is. I cancelled it and the build completed fine, and runs on other macs... so don't know if this needs wrapping too?

Re: Cross-Platform Libraries to Wrap

Posted: Mon Mar 07, 2022 9:31 pm
by OpenXTalkPaul
tperry2x wrote: Mon Mar 07, 2022 5:06 pm lipo_cmd error.pnglipo on OSX, whatever that is.
Never heard of it being needed before, but this appeared when trying to build with LC Community 9.6 on OSX 10.13

I don't have the developer tools, but no idea what this is. I cancelled it and the build completed fine, and runs on other macs... so don't know if this needs wrapping too?
Lipo needs the Xcode Command Line Developer Tools (I believe that's a separate and much smaller download than Xcode).

Lipo is for removing CPU architectures from a Universal (FAT) binary that aren't needed. Which is important if your app is going to be submitted to Apple for the AppStore, because they no longer allow new apps that contain 32bit code on there. Lipo can be used to strip out the 32bit code, leaving only the 64bit code (un'FAT', like lipo suction for a binary).

This message is due to some of the existing externals having been built as 32+64 fat binaries, the standalone builder can use Lipo to strip out the 32bit parts to keep Apple happy.

Unless you're building apps for use on really old macOS versions below 10.8.x, you most likely do not need the 32bit parts because only 64bit capable CPUs can run macOS above 10.8.