OXT Lite Moving Forward
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!
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!
- richmond62
- Posts: 2764
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: OXT Lite Moving Forward
This list does not make sense one little bit:
- -
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:
- -
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.
- -
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:
- -
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.
https://richmondmathewson.owlstown.net/
- richmond62
- Posts: 2764
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: OXT Lite Moving Forward
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:
- -
Mind you: DO NOT EXPECT anything.
Aaaaaaah: downloaded the whole jingbang:
- -
Mind you: DO NOT EXPECT anything.
https://richmondmathewson.owlstown.net/
- richmond62
- Posts: 2764
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: OXT Lite Moving Forward
Wait a minute: even a cretin (like . . .) could replace these files:
- -
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?
- -
Someone has been playing some serious 'funky monkey' around and about:
- -
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 . . .![Cool 8-)](./images/smilies/icon_cool.gif)
- -
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?
- -
Someone has been playing some serious 'funky monkey' around and about:
- -
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 . . .
![Cool 8-)](./images/smilies/icon_cool.gif)
https://richmondmathewson.owlstown.net/
- richmond62
- Posts: 2764
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: OXT Lite Moving Forward
Even a large amount of the files inwith the engine that do NOT end with .rev or .livecode seem to be writtein in xTalk:
- -
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.
- -
Well, possibly, but a term used at the end of an xTalk script in a totally decontextualised fashion it is ever so slightly difficult to understand.
- -
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.
- -
Well, possibly, but a term used at the end of an xTalk script in a totally decontextualised fashion it is ever so slightly difficult to understand.
https://richmondmathewson.owlstown.net/
- richmond62
- Posts: 2764
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: OXT Lite Moving Forward
Back to the sewage farm again:
- -
This is because when OXT Lite goes into Dork mode it darkens the selected colour rather than changes it for something else:
- -
- -
This is because when OXT Lite goes into Dork mode it darkens the selected colour rather than changes it for something else:
- -
https://richmondmathewson.owlstown.net/
- richmond62
- Posts: 2764
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: OXT Lite Moving Forward
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]
.gyp [as do these]
they may be written in Python.
among quite a few others.
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]
.gyp [as do these]
they may be written in Python.
among quite a few others.
https://richmondmathewson.owlstown.net/
-
- Posts: 280
- Joined: Sat Sep 11, 2021 4:37 pm
- Contact:
Re: OXT Lite Moving Forward
Not by conventional definition of "engine".richmond62 wrote: ↑Fri Nov 24, 2023 1:45 pm So, as the vast majority of the engine IS written in xTalk
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.
- richmond62
- Posts: 2764
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: OXT Lite Moving Forward
OK.
I am referring to a lot of files inwith the 'engine' folder of the source code/
I am referring to a lot of files inwith the 'engine' folder of the source code/
https://richmondmathewson.owlstown.net/
- tperry2x
- Posts: 1531
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: OXT Lite Moving Forward
Hi Richmond, if I can be a pain and refer you back to here:
https://www.openxtalk.org/forum/viewtopic.php?f=9&t=600
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.
You'll find a fork of the gyp source here:
https://github.com/tperry2x-uk/gyp
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.
You may also find this handy:
https://minhaskamal.github.io/DownGit/#/home
(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.
https://www.openxtalk.org/forum/viewtopic.php?f=9&t=600
https://github.com/livecode/livecode/bl ... /README.mdLiveCode uses the gyp (Generate Your Projects) tool to generate platform-specific project files.
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.
You'll find a fork of the gyp source here:
https://github.com/tperry2x-uk/gyp
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.
You may also find this handy:
https://minhaskamal.github.io/DownGit/#/home
(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!
![Cool 8-)](./images/smilies/icon_cool.gif)
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
- Posts: 2764
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: OXT Lite Moving Forward
Tried a code-sign thing with the Terminal on Mac 0.94 and the thing is still not working.
https://richmondmathewson.owlstown.net/
- tperry2x
- Posts: 1531
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: OXT Lite Moving Forward
I have a plan (I think), regarding this.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.
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.
(List of bugs, as they are found and squashed)
https://www.openxtalk.org/forum/viewtopic.php?f=8&t=610
-
- Posts: 121
- Joined: Mon Sep 13, 2021 9:46 pm
- Contact:
Re: OXT Lite Moving Forward
Clicking Download for Mac 0.9.4 on Terry's site, result in an error
Mic
Mic
- tperry2x
- Posts: 1531
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: OXT Lite Moving Forward
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?
Please just use the ones mentioned either on this forum,
viewtopic.php?f=16&p=4646#p4646
or on the main page of this forum:
https://openxtalk.org/OXTDownloads.html
Or the one directly on my site:
https://www.tsites.co.uk/sites/openxtalk/changes/
(All points to the same thing ultimately)
TerryL needs to check his link, that's all, but I'll gladly help where I can.
-
- Posts: 121
- Joined: Mon Sep 13, 2021 9:46 pm
- Contact:
- richmond62
- Posts: 2764
- Joined: Sun Sep 12, 2021 11:03 am
- Location: Bulgaria
- Contact:
Re: OXT Lite Moving Forward
https://tlittle72.neocities.org/openxtalk
Great stuff!
HOWEVER, on attempting to download the Mac version of 0.94 I got a '404', a 'not found.'![Confused :?](./images/smilies/icon_e_confused.gif)
The Linux and Windows downloads work perfectly well.
Great stuff!
HOWEVER, on attempting to download the Mac version of 0.94 I got a '404', a 'not found.'
![Confused :?](./images/smilies/icon_e_confused.gif)
The Linux and Windows downloads work perfectly well.
https://richmondmathewson.owlstown.net/
- tperry2x
- Posts: 1531
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: OXT Lite Moving Forward
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).richmond62 wrote: ↑Sun Nov 26, 2023 2:10 pm https://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.
![Idea :idea:](./images/smilies/icon_idea.gif)
https://www.openxtalk.org/forum/viewtop ... f=14&t=611
and
https://www.openxtalk.org/forum/viewtop ... 4646#p4646
-
- Posts: 66
- Joined: Sat Oct 16, 2021 5:05 pm
- Contact:
Re: OXT Lite Moving Forward
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
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
- tperry2x
- Posts: 1531
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: OXT Lite Moving Forward
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: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
https://www.dropbox.com/scl/fo/75kfz9ho ... 5xdm5&dl=0
Ask password does produce bullets: If this checkbox is off in the preferences, no more drag handle:
- tperry2x
- Posts: 1531
- Joined: Tue Dec 21, 2021 9:10 pm
- Location: Britain (Previously known as Great Britain)
- Contact:
Re: OXT Lite Moving Forward
@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.
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.
- OpenXTalkPaul
- Posts: 1574
- Joined: Sat Sep 11, 2021 4:19 pm
- Contact:
Re: OXT Lite Moving Forward
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.
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.
Who is online
Users browsing this forum: No registered users and 10 guests