OpenXTalk Forums

This comes under the "Demos" part of this topic. It's not fun, or games
(although it does open up a whole new avenue of "fun and games").

As anyone reading this may or may not know, the systemversion function is broken under MacOS 11+
(it returns the wrong value).

In OXT Lite, I already have a built in function you can run: That works for all platforms, but I'd ideally like to fix the systemversion function C++ code in the engine.

So, that brings me to the point of this post: How to test C++ code in the OXT IDE without having to do a full recompile, test the result, and keep going backwards and forwards to the compiler.

Well, it's actually quite simple - and I thought I'd upload a proof of concept of running C++ code in the IDE. This uses the shell function to run the compiled code. (You'll have to compile your own if you are running windows - instructions included).

But my thinking was - this way we could externalise all functions as needed - by building up a list of compiled binary functions. If anything needs changing in future, you just recompile the one single file as you are referencing it through the IDE.

tperry2x wrote: ↑Sun Aug 18, 2024 7:29 pm This comes under the "Demos" part of this topic. It's not fun, or games
(although it does open up a whole new avenue of "fun and games").

As anyone reading this may or may not know, the systemversion function is broken under MacOS 11+
(it returns the wrong value).

In OXT Lite, I already have a built in function you can run:

Code: Select all

put osversion()

That works for all platforms, but I'd ideally like to fix the systemversion function C++ code in the engine.

So, that brings me to the point of this post: How to test C++ code in the OXT IDE without having to do a full recompile, test the result, and keep going backwards and forwards to the compiler.

Well, it's actually quite simple - and I thought I'd upload a proof of concept of running C++ code in the IDE. This uses the shell function to run the compiled code. (You'll have to compile your own if you are running windows - instructions included).

But my thinking was - this way we could externalise all functions as needed - by building up a list of compiled binary functions. If anything needs changing in future, you just recompile the one single file as you are referencing it through the IDE.

systemversion-cplusplus-screenshot.png

systemversion-cplusplus.7z

That is kind of the idea of Extension Builder.

Instead of building a CLI that you can use from shell() or open process tCmdLine, you compile it as a library and then bind to the symbol (function/command) names in the library.

The lce packaging format has the advantage of being able to include a 'code' subfolder which can include a separate compiled library binary for each platform's ABI (Application Binary Interface), then the extension loads the appropriate library binary for the current platform.

There's also a way you could theoretically create an extension library that is written in xT Script and use a CLI compiled depending on the platform, that is stored in the package's 'resources' or 'code' sub folders and then loaded by the library script as needed.

I posted something recently about the structure of the .lce package format... I'll see if I can find it.

But I agree, I think it's a good idea to modularize the whole thing a bunch more. Keep all the platform specific or peripheral tasks sort of things external to the engine, and as readily editable as possible.

That is why I want to create sort of 'syntax-to-implimentation arbitrator' libraries for certain non-core things like for example 'Text To Speech", the functionality is already coming from an external, but IIRC revSpeak was only ever implemented on macOS and Windows. LC made some sort of 'unified speech' library to combine some other implementations (I'm guessing here, because I can't look under the hood). I've done something similar with General Music library, and I want to do that same sort of 'unifier' library for 'speech' as well as some other desirable tasks such as microphone sound recording, displaying PDFs, or doing colors manipulations (for a few examples).

Of course being able to compile C++ from directly from text in a card feild is certainly a useful thing too.

BTW, in an effort to further explore hidden details of Builder and Widgets and hopefully make it more accessible to people, I've currently diverted my attention from 'revTools redo' to working on trying to make my Extension Builder Editor/miniIDE more useful. Eventually I think it could be a replacement for the Extension Builder stack.

So far now it has:
1) Import and Export an .LCB file
2) Some syntax colorization (need to automate colorizing as you type)
3) Basic templates for the three Extension Module types (language module, library, widget)
4) Has drop down menus for inserting a new Property Name with all of the possible metadata tags and setup of getter/setter functions to go along with it.
5) Has drop down menus for inserting a premade basic event handlers for all the possible event messages a Widget can receive ( OnMouseUp(), OnDragStart(), OnScrollWheel(), etc.)
6) Has drop down menus for inserting a premade basic handlers.

It's already helping me edit widgets faster. I spent time with it this morning using it to update one the original demos for Widgets that Ali Loyd did, but that was written for a very early version of Extension Builder, found here:
https://github.com/OpenXTalk-org/OpenXt ... n/main.mlc
The '.mlc' apparently was an early filename extension they were using for XBuilder source code files.

I got that basic-button widget somewhat working again. It's not actually that basic, uses gradients and has a 'pulse' animation that can be enabled (would be cool to add the macOS button 'No' shake animation). Needs more work, but I'll upload the new version of this widget soon.