A place to discuss and plan OpenSource xTalk (not exclusively LCC based)
and Community Builds of LCC ...Ask NOT what xTalk can do for you...
Get involved you DO have something to contribute, no matter your skillset!
Forum rules
A place to discuss and plan OpenSource xTalk (not exclusively LCC based) and Community Builds of LCC
Ask NOT what xTalk can do for you... get involved you DO have something to contribute, no matter your skillset!
Screenshot 2023-11-24 at 9.25.09.png (132.51 KiB) Viewed 9880 times
-
User-centric design: no worse nor better than the Linux and Windows versions: the interfaces are essentially the same.
Easy to understand, "natural language". The programming language contained with the Mac version of the thing is no way differs from the programming language in the Linux and Windows versions.
Instant gratification: Yup: WYSIWYG and none of the compile-and-run stuff.
Constant just-in-time recompiling of bits of code: Erm: that's another way of saying the previous thing.
Editing with a GUI toolkit that has most elements for building apps: no worse nor better than the Linux and Windows versions: the interfaces are essentially the same.
Suitable for data collection and/or data-processing applications: proven time and time again by LC developers.
----
Not sure foxtrot47 what you are trying to say with this claim.
----
The 'problem' with the MacOS version is ONLY concerned with the:
-
crap.png (55.57 KiB) Viewed 9879 times
-
Which has already been shown to be sortable-outable with a couple of patches . . .
. . . which should be applied PRIOR to bunging the thing in a DMG file.
Is there a way to download the engine files onto a local hard-drive so stupid Richmond does not have to learn about GIT-hub (one old GIT is enough round these parts)?
Aaaaaaah: downloaded the whole jingbang:
-
SShot 2023-11-24 at 12.51.15.png (32.72 KiB) Viewed 9878 times
Wait a minute: even a cretin (like . . .) could replace these files:
-
SShot 2023-11-24 at 12.53.59.png (128.74 KiB) Viewed 9878 times
-
Mind you, if that were the ONLY problem we'd all be laughing with (hysterical) relief.
And, I wonder why LC 963 tells me that this file is NOT a LiveCode file, when, on opening it in BBEdit is looks like one?
-
SShot 2023-11-24 at 12.57.18.png (198.53 KiB) Viewed 9878 times
-
Someone has been playing some serious 'funky monkey' around and about:
-
SShot 2023-11-24 at 13.00.13.png (63.01 KiB) Viewed 9877 times
-
This would seem to suggest that quite a lot can be done without spending 6 months learning C++, and that a lot of files inwith the engine that ARE written in xTalk have been obfuscated so that Paul, Tom, Richmond, and all their wee pals will not put their sticky paws in them.
Unfortunately Richmond has very sticky paws indeed, and coupled with a large dollop of ignorance about how things 'should' be done . . .
Even a large amount of the files inwith the engine that do NOT end with .rev or .livecode seem to be writtein in xTalk:
-
SShot 2023-11-24 at 13.06.53.png (35.28 KiB) Viewed 9877 times
-
Erm . . . "teardown".
Teardown is NOT mentioned in the LC Dictionary: are we to conclude that there are parts of xTalk that LiveCode have kept to themselves?
Certainly if that is true, and the xTalk language is open source, we ought to be able to ask them for a COMPLETE list of xTalk terms, and should sowe caan get on with things.
-
SShot 2023-11-24 at 13.12.37.png (18.87 KiB) Viewed 9876 times
-
Well, possibly, but a term used at the end of an xTalk script in a totally decontextualised fashion it is ever so slightlydifficult to understand.
So, as the vast majority of the engine IS written in xTalk (although terms such as 'teardown', 'test', and 'setup' suggest either a superset of the language we know, or a series of custom handlers/functions which will have to be tracked down and understood), the problems seem to be, largely, twofold:
1. Understanding what to change and how to change it.
2. Building the engines after we've mucked around with the code.
We also need to know how files with the following suffices are interconnected (called?):
.gypi [these appear to have been written on non-xTalk]
richmond62 wrote: ↑Fri Nov 24, 2023 1:45 pm
So, as the vast majority of the engine IS written in xTalk
Not by conventional definition of "engine".
It's C++ (though the Android build has a LOT of Java as the OS uses Java interfaces).
The "engine" of a scripting language generally refers to the compiled object code executable needed to interpret and execute scripts. By definition, it cannot interpret itself.
That's what those gyp files are.
(Generate your projects) files. Think of it as a tool to then make vcproj files (visual studio), xcodeproj files (mac) and makefiles (linux). It takes the source and generates the bits you need to then go on further compiling adventures in xcode, visualstudio and the make compiler build tools in linux.
That needs fixing before we can actually even think about getting the engine to compile, as the two are linked.
It would seem that as gyp is not at a stage where it is currently working, I believe LC may have switched away from gyp to use something else that is maintained, possibly some point after the 9.6.3 LCC. They may be using anything else, known only to themselves (or even a toolset they only have access to internally). That is 100% understandable as gyp is a bit broken currently.
(but it's better to sign into github, create an account, and make a fork of the gyp link above. You can then edit online without having to download anything).
Follow the white rabbit and see how deep the rabbit hole goes!
Meanwhile, I'm currently learning C++ so that's taking up my time.
You can begin to see why my personal preference is to switch away from this engine and find an alternative. (and I don't mean that as a snarky comment). It would be easier to start afresh in my view.
richmond62 wrote: ↑Sat Nov 25, 2023 1:58 pm
Tried a code-sign thing with the Terminal on Mac 0.94 and the thing is still not working.
I have a plan (I think), regarding this.
What I propose is I'll revert back to an unmodified App Bundle. (This will be the original 'engine' from 9.6.3 community).
I'll then add the Sonoma patch and see if it breaks it for codesigning. (will try resigning it with the instructions if it does).
Then, if that's all good, I'm going to strip away the version numbers that you see in the 'get info' dialog. This way, the only mention of the version will be in the splash / about dialogs.
This goes hand-in-hand with my re-enabling the online updates function, which I've done today.
I've also fixed the grid spacing issue.
The next job is the multiple monitors thing. I may have a little adjuster in the compatibility section in the preferences, so it can be 'nudged' and the position saved. This only seems to affect users with multiple monitors, and if the IDE isn't loading on screen 1.
First job though is getting it working again on the mac.
micmac wrote: ↑Sun Nov 26, 2023 9:34 am
Clicking Download for Mac 0.9.4 on Terry's site, result in an error
Mic
I've not changed my download link. What's the address of his site?
(I'm now struggling to find the link to his site anywhere) I'll put the link here if you have it?
richmond62 wrote: ↑Sun Nov 26, 2023 2:10 pmhttps://tlittle72.neocities.org/openxtalk
Great stuff!
HOWEVER, on attempting to download the Mac version of 0.94 I got a '404', a 'not found.'
The Linux and Windows downloads work perfectly well.
yes, as mentioned above. TerryL just needs to rectify his link. If you hover over it, you'll see the link on his page points to a 7z file (I haven't used a 7z file since 0.92 of OpenXTalk Lite).
o) I updated the Mac download link on my website, sorry for the mixup. I'll try to update all if you switch servers.
o) Did anyone have an opportunity to test ask password on Mac & Linux to verify bullets "•" appear while typing/pasting input? If not, maybe numToCodePoint("8226").
o) Please verify the Toolbar drag handle disappears when Toolbar Icons and Toolbar Text are both unchecked. Terry
TerryL wrote: ↑Sun Nov 26, 2023 11:08 pm
o) I updated the Mac download link on my website, sorry for the mixup. I'll try to update all if you switch servers.
o) Did anyone have an opportunity to test ask password on Mac & Linux to verify bullets "•" appear while typing/pasting input? If not, maybe numToCodePoint("8226").
o) Please verify the Toolbar drag handle disappears when Toolbar Icons and Toolbar Text are both unchecked. Terry
Hi Terry. I will definitely switch server hosting these files, and will change the download link. You will need to update the information on your site. If it's easier, it would be best just to link to here: https://www.dropbox.com/scl/fo/75kfz9ho ... 5xdm5&dl=0
Ask password does produce bullets:
Screenshot_2023-11-27_00-04-00.png (16.5 KiB) Viewed 9779 times
If this checkbox is off in the preferences, no more drag handle:
Screenshot_2023-11-27_00-07-11.png (73.35 KiB) Viewed 9779 times
@TerryL
As mentioned, you will need to update the links on your homepage, as the previous ones are all broken since I had to change the way the downloads were stored.
Woah now, I can't speak for Tom or Terry, but personally I think that the macOS engine works very well for me, I've done the majority of work on OXT Don't Panic Edition on macOS. It is still my daily driver OS, and likely will continue to be until I retire sometime in the next 2 decades.
The MacOS engine, with Extension Builder access to all of Apple's APIs, probably has the easiest path of al the supported desktop platforms as far as adding support for new OS features. Extension to do xTalk scripted audio recording on Mac again.
Yeah Code-Signing, Sandboxing, Notarization, etc, is a pain but what can you do? I guess that's the price you pay for a secure (allegedly) system. This isn't exclusively an xTalk problem, ANY development tools that aren't Apple Xcode are going to have the same issues. Try building an 'native' app with RealBASIC (or whatever it's called now), or Python, or any of others and you will hit the same problems.
But people who aren't afraid to run an app from a trusted source that is NOT the App Store likely already know how to get around the roads blocks, but you can make an OXT provision file, make your own certificate and code-sign all with just a free Apple Developer account. If we want to start getting Apple to actually notarize this, that's $99/year USD last I checked. If you REALLY need to build AppleSilicon native apps now, then I suggest you subscribe to LiveCode Ltd.'s App-Building as a subscription service - service.
No, OXT does NOT have an Apple Silicon native engine, but the Intel based Mac engine runs fine in Rosetta 2 from what I understand. I still don't yet own an Apple Silicon based Mac so I can't confirm.
I still very much fully intend to work at compiling the macOS engine to run native on Apple Silicon, but I really need an M-series Mac before I can even get started on that task, This may change very soon.
In fact I was just thinking about how we already have iOS Standalone engine is already targeting Apple's ARM processors and probably could be a good template, I was thinking maybe it could even run as 'Catalyst' app (which, if you're not familiar, is Apple's Framework for iOS apps that can run 'native' on macOS Apple Silicon).
Another option, depending on your needs, may be to totally switch to another open-source xTalk interpreter. It was quite painless to compile StackSmith (for one example) from (C++ +Objective C) source with Xcode. I also easily built a 'native' (in that it doesn't require JavaVM to be installed in order to run) OpenXION build with GraalVM 'natifier'. There are several others that could potentially, with a lot of work, be developed into viable alternatives to the LC Community engines that OXT currently runs on.
----------
I'd also want to be clear that the OnScreenKeyboard widget that I've been developing for the last two weeks or so, had nothing to do with fixing the mentioned crashing bug when using macOS built-in on-screen-keyboard. It was purely coincidence that I happened to be working on that at the time of the post. My goal with this widget was to make a graphical representation of a standard keyboard that could react to either messages generated from physical keyboard input (rawKeyDown,keyDown,enterKey,tabKey,etc.) as well as point-n-click (the widget send virtualKeyDown/Up in this case) character selection to aid with tasks like setting up key-combinations (like 'Command,Control,Option,Shift,ˆ) for example. It's also quite fun to map the keys to musical phrases or drum sounds.
From what I understand, FFPLAY (from FFMPEG Team) can be bound a window on Linux, just using shell command switches, even without creating an extension wrapper for it. I think the FFMPEG suite would be great to wrap as an extension, but it would add 10s of 10s of megabytes to the overall package sizes and it is frequently updated, so would prefer to leave that to a package manager like HomeBrew/LinuxBrew.
I did edit the IDE to include Homebrew binaries directory in the $PATHs to make calling user-installed shell commands easier.
For Linux it would be great to know if the distro you are using has all of the required dependencies, is using Wayland or a newer Desktop Environment / compositing engine, etc. Just saying that it's VERY broken isn't particularly helpful. I mean I've run OXT on Linux distros where it ran as good as the macOS engine does for me. On Ubuntu Studio (with low latency kernel, and KDE Plasma), the browser-widget and the player control work fine as far as I can tell. I mean I wouldn't use the Browser Widget on Linux or WIndows for secure banking or anything like that, but for rendering HTML and running some JavaScript it does the job. Likewise, the Player seems to play the included MPEG demo video OK.
On ElementaryOS, with not-common DE Pantheon desktop, I do have those issues, but I kind of expectedd that since the Engine probably targets 'Buntu/Debian Linux from like 10 years ago (actually I don't think the source is even fully updated for C++2011 support). What would be helpful would be to create a list of required dependencies and incompatible desktop environment/windowing compositors/etc.
Please note. Download links have all changed