OpenXTalk Forums

Posted: **Sat Feb 01, 2025 3:30 am**

tperry2x wrote: ↑Fri Jan 31, 2025 5:15 pm Is it available in a truly hardware agnostic way? - That's probably only going to be close via a browser (and even then, there will be differences in the way things are reported & variables returned) - it's not the 100% magic bullet either, because there's not a lot ready 'today' that has an xTalk-savvy syntax. Even less so that is ready to use.

Well Qt App kit runs I a browser, the demo on this page is an image editor that loads in under a second (excluding hardware differences, your mileage may vary )
https://www.qt.io/qt-demos
It needs the xTalk interpreter part to go with it.

WASM should run the same way under on any hardware, so long as the wasm vm is compliant, hardware agnosticism is the entire point of it. There's quite a bit of C/C++ that has already enabled to be ported to run in HTML5 Browsers.
JAVA similarly should always yield the same results, since the machine it runs on is virtual (the it's its 'Engine' that is compiled native).

Anyway, I'd still always want a 'Desktop' version that can tap System APIs and libraries, shell commands, MIDI hardware, etc. more directly.

Posted: **Sat Feb 01, 2025 12:21 pm**

I was about to close the page after scrolling down to find it, as it took over a minute to load for me.
I was getting bored of waiting. I'm sure it's all very clever behind the scenes - but the eraser tool... didn't. (it draws on the canvas with a brown line). - so, yes - it shows web tech is possible, but we knew that it was fairly versatile. It might be the best option for Mac ARM users soon.

For example, Photopea is a great example of this - but it loads INSTANTLY. No waiting, no fuss, and works. Why can't the emscripten plugin (which never ever really worked did it?) - why doesn't it work like that? - rather than normally spooling for 40+ seconds before loading anything? Even a progress bar while loading would give you an indication that something is happening, and an idea of how long... None of what I've seen web-xTalk-wise looks like it's what you'd call 'ready' (useable).
Everything web-xTalk wise all has good bits, but there's no cohesive effort to put it all together into one working thing.

An example which comes close is the hypercard remakes, but why not expand on it to be a fully-fledged implementation with colour, arrays, functions and commands missing from Hypercard that have been added to LCC over the years? I don't get as to why someone would go to all that trouble, then stop short of creating a useable web IDE.

Again, there's no way to actually run these 'locally' - probably because it relies on server-side scripting or a server implementation of a plugin running remotely to work. To be truly fully platform agnostic, this needs to work on something as simple as javascript CSS and HTML. Nothing fancy, and stuff that you can download to an archive and launch from your desktop, or is equally at home being hosted on a server somewhere. Like my example, it needs to not care where it loads from ideally.

: screenshot.png (38.33 KiB) Viewed 4936 times

Posted: **Sat Feb 01, 2025 5:43 pm**

Dan Gelder's HT->JS transpiler is amazingly efficient, and elegantly crafted.

Posted: **Sat Feb 01, 2025 6:14 pm**

And it would be available where?

Posted: **Tue Feb 11, 2025 3:51 am**

tperry2x wrote: ↑Fri Jan 31, 2025 10:10 pm Continuing the digital obsolescence theme...
I think I may have found a way we can run our present engine in MacOS.
Kind of emulated... ish. In a minimal way, bear with me.

Emulated... kind of. No more than what Rosetta 2 is doing (except Rosetta 2 automates the process). If Apple were to drop Rosetta 2 tomorrow (or in their next OS release), I think this might give us a backup plan.

OK if I scanned through this idea accurately then this method is basically run the Linux build in a mini VM of Linux on macOS via XQuartz (macOS X11), but then it would have to use QEMU to emulate X86 on ARM, likewise if you are running the ARM Linux on ARM Mac you would still need to emulate x86 instruction set. UNLESS you can build the ARM version on Linux, then you have CPU-native ARM Linux on Mac ARM, no emulation.

Otherwise o ARM-based Apple Silicon CPUs you might as well run a Mac OS X 10.9+ VM with QEMU ARM<>Intel and then run the Mac version, that's how SuperCard users kept using it (or they had dual boot set-up with 10.14 Mohave).

The Linux AppImage does include some built GTK2 libraries but unfortunately not all of the related libraries (such as libwebkit2gtk+), that's the nice thing about 'container' things like AppImage or Docker, you can include all of the requirements WITHOUT embedding them into the engine (in my opinion every thing like that should all be separate, dynamic loaded libraries that can be updated without recompiling the engine). So that AppImage should continue to work so long as AppImage and x86_64 instruction-set is supported on the system. No GTK needs to be pre-installed on the Linux with AppImage because bits of GTK2 are included inside the .AppImage (along with some other libraries like libFluidSynth) they're like disk-images that get mounted when run and the mounted volume is used in searching for libraries (I think you can add other library search paths too in the app-launcher which is just a shell script).

Still the point remains that there is no (current) Linux ARM build of the Engine, which is a real shame because I think it makes a great dev environment for the resource limited SoC like Raspberry Pis. I remember the Linux ARM build of LC CE 7.x ran surprisingly well on the RPi B+ I used to have.

Posted: **Tue Feb 11, 2025 11:04 am**

OpenXTalkPaul wrote: ↑Tue Feb 11, 2025 3:51 am OK if I scanned through this idea accurately then this method is basically run the Linux build in a mini VM of Linux on macOS via XQuartz (macOS X11), but then it would have to use QEMU to emulate X86 on ARM, likewise if you are running the ARM Linux on ARM Mac you would still need to emulate x86 instruction set. UNLESS you can build the ARM version on Linux, then you have CPU-native ARM Linux on Mac ARM, no emulation.

Not exactly, as that web page is running an entire virtualisation in-browser as far as I understand it. So the real work is being done via the server hosting the page as far as I can work out. Meaning it's platform / processor agnostic - even though you do end up being booted into a linux OS, you could in theory run that page and attach the ISO on an ARM mac (in theory). Not that I have access to one.

Although, QEMU will run x86 intel programs on ARM macs, just a bit slower. As you said (This Reddit thread explains why it's slower for everyone who might be following along), but that's not the route I was going down - essentially the idea was the emulation load was happening on a server farm somewhere (possibly, if it's indeed doing what it seems to be doing)

OpenXTalkPaul wrote: ↑Tue Feb 11, 2025 3:51 am The Linux AppImage does include some built GTK2 libraries but unfortunately not all of the related libraries (such as libwebkit2gtk+)

I think we might be talking about two different things here, but I'll try to address both of them.
When the engine is compiled on Linux, it's pulling 'just enough gtk2' in order to launch and embedding it inside the binary when compiled. So it's kind of already an appimage in some ways, although not what you'd class as an appimage. It's statically linked.
Instead of being dynamically linked, - so it doesn't require those dependencies to be installed on a user's target system to run.

I agree though, with an appimage - we could bundle everything we want to include (I'm thinking the video dependencies) - so that if they aren't available on the user's target system, at least they can run. I know the video 'player' object is pretty sketchy on all platforms to various degrees - but that's another discussion.

OpenXTalkPaul wrote: ↑Tue Feb 11, 2025 3:51 am ...that's the nice thing about 'container' things like AppImage or Docker, you can include all of the requirements WITHOUT embedding them into the engine (in my opinion every thing like that should all be separate, dynamic loaded libraries that can be updated without recompiling the engine). So that AppImage should continue to work so long as AppImage and x86_64 instruction-set is supported on the system. No GTK needs to be pre-installed on the Linux with AppImage because bits of GTK2 are included inside the .AppImage (along with some other libraries like libFluidSynth) they're like disk-images that get mounted when run and the mounted volume is used in searching for libraries (I think you can add other library search paths too in the app-launcher which is just a shell script).

This is the second bit to it. As far as I can tell, all the other GTK libraries you might need - for things like webkit rendering etc, that's where GTK libraries would be handy if they were part of an appimage. However, because the browser widget doesn't work anyway even with these installed, it's a bit of a moot point.

OpenXTalkPaul wrote: ↑Tue Feb 11, 2025 3:51 am Still the point remains that there is no (current) Linux ARM build of the Engine, which is a real shame because I think it makes a great dev environment for the resource limited SoC like Raspberry Pis. I remember the Linux ARM build of LC CE 7.x ran surprisingly well on the RPi B+ I used to have.

I would love to see the 9.x engine recompiled for ARM to work on Raspberry PI's (and other system-on-chip single-board computers), and there are various options at compile time to try and compile for these systems on Linux. However, it then asks for ARM-specific prebuilts.... which we don't have.

FourthWorld wrote: ↑Sat Feb 01, 2025 5:43 pm Dan Gelder's HT->JS transpiler is amazingly efficient, and elegantly crafted.

richmond62 wrote: ↑Sat Feb 01, 2025 6:14 pm And it would be available where?

Your guess is as good as mine.

I'm leaning more and more towards my browser version anyway. I have been adding various extra functions to my javascript implementation, and looking back for inspiration at the old hypercard stacks with XCMDs in.
I'd say about 90% of those XCMDs and XFCNs all have one thing in common - they are all geared up to get information about the physical hardware (boot device name, system folder location, moving resource-forks into data-forks and vice-versa...) things that just aren't applicable to a browser-based implementation. There are a few extra things I've added, which I'll detail on that topic.

Posted: **Tue Feb 11, 2025 10:37 pm**

tperry2x wrote: ↑Tue Feb 11, 2025 11:04 am When the engine is compiled on Linux, it's pulling 'just enough gtk2' in order to launch and embedding it inside the binary when compiled. So it's kind of already an appimage in some ways, although not what you'd class as an appimage. It's statically linked. Instead of being dynamically linked, - so it doesn't require those dependencies to be installed on a user's target system to run.

Right, but IMO it should be dynamically linked and not statically linked (embedded). The static linking is what has made it so that I can't just use the newer GTK3+ requiring webkit 'widget' (GTK widget, not OXT "widget") in a window, because you can't mix GTK2 with GTK3, it crashes the engine as soon I've tried to. If GTK was dynamically linked, at. least in theory the engine could run with GTK 3 or 4 and most things would still work (with the exceptions of changes or deprecations in newer GTK libraries, which would still need to be fixed in engine source, and as I understand it there were a lot of changes from GTK2 to GTK3).

Posted: **Tue Feb 11, 2025 11:07 pm**

tperry2x wrote: ↑Tue Feb 11, 2025 11:04 am
FourthWorld wrote: ↑Sat Feb 01, 2025 5:43 pm Dan Gelder's HT->JS transpiler is amazingly efficient, and elegantly crafted.

richmond62 wrote: ↑Sat Feb 01, 2025 6:14 pm And it would be available where?
Your guess is as good as mine.

The JavaScript (and some PHP) source for HyperCard Simulator is in Dan's Github repos as well as a version in OXT repos (that also includes the HyperCard icons .png files)

Dan's repo of the HC Stack convertor/uploader (PHP) and the Script.js 'engine' is here:
https://github.com/hyperhello/hypercard ... /tree/main
That relies on a few other projects to do the STAK to HTML/JS conversion.

I forked Dan's repo above and included the icons and other assets in sub-directories set-up/named the way they're expected to be by links in the code. The script.js 'Engine' file in that repo has some 'OXT additions' added to the syntax. https://github.com/PaulMcClernan/hyperc ... k-uploader.

Some other repos of interest:
https://github.com/hyperhello/BNFToLPEG ... me-ov-file
https://hypervariety.com/BNFToLPEG/

Dan's other live-hypermedia-in-browser webapp project called HyperHello:
https://github.com/hyperhello/hyperhello

I don't know about "90%" of them, but certainly the functionality of many xcmd/xfcns from 20-30 years ago are outdated, obsolete, etc. and there was a lot of them that all had the same functionality. Of the ones that are not obsolete or that would still be relevant in a browser-engine context, I think most if not all of those could be recreated with JavaScript implementations. Basically just a thin-wrapper around some JavaScript script. For examples it was extremely easy to implement the missing 'speak' syntax (could make 'revSpeak' a synonym for 'speak') and launchURL (which was an xcmd I used a lot back when). Dan set it up so it's very easy to integrate / add 'new' syntax to the script.js file for that very reason of reimplementing missing xcmd/xfcn.

Posted: **Thu Feb 13, 2025 6:50 pm**

Others seem to think that life in the browser will be the future for most things... Truly platform agnostic, so we can get off that treadmill. But can it be standalone - does it still work offline, just on my desktop?

https://creston.blog/wasm-will-replace- ... ldrdevops

WASM will replace containers

Summary
WebAssembly (WASM) is poised to replace containers due to its write-once-run-anywhere nature and growing support. WASM offers the benefits of microservices, like strict boundaries and scalability, without the drawbacks of network overhead and reliability concerns. While still in its early stages, WASM’s adoption is accelerating, and developers should consider incorporating it into their workflows.

WebAssembly is a true write-once-run-anywhere experience.

Creston10 Feb 2025
WASM will replace containers
Humans saw this and then invented OKRs and SCRUM.
In the year 2030, no one will remember Kubernetes.

Portability

Containers solved a lot of important problems in software development. We had VMs before containers, but they were not as ergonomic to use. The experience of containers was, by comparison, a true delight. Fast(er) builds, near-instant startup, no virtualization, etc.

Now we're in an era where containers are annoying to work with. The promise of DevOps has been eroded by complicated tooling and tight coupling of program-container-linux. In my experience, developers want to write code and ship features to hit their quarterly goals. Learning how to use Docker is a distraction. No one has a goal to "improve Docker build times" unless you're part of the new PlatformOps (formerly DevOps (formerly Ops)) team.

My money is on WebAssembly (WASM) to replace containers. It already has in some places. WebAssembly is a true write-once-run-anywhere experience. (Anywhere that can spin up a V8 engine, which is a lot of places these days.) You can compile several languages into WebAssembly already. Languages that can't be compiled will eventually have their own interpreters compiled to WebAssembly. The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated.

A very obvious argument against WASM succeeding is the Java Virtual Machine (JVM). It's almost exactly the same promise: write once, run anywhere. After all, over 3 billion devices run Java. There are many languages that run on the JVM: Java, Kotlin, Scala, Clojure, Jython, etc. The biggest limitation is that JVM bytecode cannot run in a web browser (RIP Java Applets). Web browsers are a crucial target for app development. Anyone that wants to share code between platforms will avoid the JVM. There is an interesting, slow-moving trend away from the JVM and towards statically compiled binaries. See: GraalVM, Kotlin Native, Scala Native, Jank.

Microservices

In a microservice architecture, you communicate with other services through HTTP or RPC calls, or using a message broker. This decoupling has important tradeoffs. The success of the model suggests most companies find the benefits outweigh the costs. Importantly, it creates strict boundaries between parts of your system. Conway's Law, etc. You don't need network boundaries to create good encapsulation, but it sure helps when you have a lot of developers.

Perhaps the biggest downside is the cost associated with having many small services communicating over a network. Not only do you pay for the bandwidth and resource overhead, but you have to engineer solutions to improve the reliability of each system in the face of network partitions.

With the advent of "serverless" platforms like AWS Lambda, you can take microservices to the extreme: just deploy single functions in the cloud. My favorite serverless model is Cloudflare Workers. If you have one Worker call another Worker, there is no actual network request. Instead, it just calls the Worker code in the same V8 runtime. Meaning you don't pay the cost of a network roundtrip.

Importantly, Cloudflare Workers all run in V8 sandboxes. There are no containers. You have the option of writing your worker in JavaScript/TypeScript, or compiled WASM. A container cannot call another container in the same process. But V8 can. In other words: by deploying WASM in V8 sandboxes, you get all of the developer benefits of microservices with all of the runtime benefits of monoliths. Cloudflare is not the only provider doing this. Wasmer is trying to build a solution in this space as well.

Adoption

WebAssembly is still a young technology. But it's rapidly developing, and support seems to be growing. Maybe it doesn't work for you yet, but keep an eye on it. Try developing on Cloudflare to see what the future looks like. (TV infomercial voice): if you or a loved one are building Docker images, you may be entitled to a better experience.

If you primarily develop in languages like Python, Ruby, or PHP, be patient. I recommend adding a compiled language like Go or Rust to your Golden Path so you can be prepared when the WASM reckoning is upon us.

Posted: **Thu Feb 13, 2025 8:43 pm**

Kdjanz wrote: ↑Thu Feb 13, 2025 6:50 pm Others seem to think that life in the browser will be the future for most things... Truly platform agnostic, so we can get off that treadmill. But can it be standalone - does it still work offline, just on my desktop?

If you want to run web assembly (.wasm files) locally on your desktop, then you'll need to leverage that using javascript.

So the question is, why complicate matters and not just use javascript if it can do all you want?

The thing I'm working on does just use javascript, css, and html. Nothing too exotic - purely because I want to support as far back browser-wise as possible.

You can run it online, offline, from a memory stick, from your desktop... wherever you want. The only thing the browser will do - a bit like MacOS - will put up a warning the first time asking if you are sure you want files to be saved locally. Once you agree to that, you are all good.

Webassembly has the advantage that it can be compiled, as in, code/script can be hidden from prying eyes. It's especially useful for commercial programs where you might want to hide the source from people who'd copy parts of your work without asking. That's the only real advantage it seems to have over javascript, the fact that you can make containerised 'web apps' from it - so you can make it look like an app on the surface. I know there's far more, but for my purposes, this is the main advantage.

As far as future predictions go, they are just that: predictions. There's been enough web technologies come and go, all of which were touted to be the next big thing and how they'd overthrow what was there before. Javascript is so ubiquitous and supported so thoroughly across such a range of browsers - if compatibility is key, that's what I'd personally aim towards.

But, that's why alternative languages exist. It comes down to what you are trying to achieve. No one language fits all tasks, but it's also about what is most widespread and of course personal preference comes into it because we are human and have our preferred methods.

Docker/cloudflare - all these kind of things rely on third-parties websites to keep going. My aim is to not be dependent on external providers in any way, and not to require some form of paid development toolkit. With css, html, and javascript editing - I'm using a basic text editor, so development costs are zero. Just my time.

Posted: **Thu Feb 13, 2025 11:07 pm**

https://www.electronjs.org/

Posted: **Thu Feb 13, 2025 11:18 pm**

If you want to run web assembly (.wasm files) locally on your desktop, then you'll need to leverage that using javascript.

So the question is, why complicate matters and not just use javascript if it can do all you want?

I want to use open Xtalk - I don't care what is behind it - Javascript or WASM or whatever magic makes it go doesn't matter.

I also don't care what my windows or buttons look like (Mac, Linux or Windows) as long as I can make a window that contains all my controls and leaves me a canvas to create my UI on. Platform agnostic as much as possible.

Posted: **Thu Feb 13, 2025 11:26 pm**

https://www.electronjs.org/

I hate electron with a passion because it creates slow to load, huge apps that always feel fat and sluggish to me. As an engine, it feels like a 1965 VW 4 banger air cooled engine trying to push a modern car. Yes it can do it, given enough time and patience, but it is not really a pleasurable experience if you have the choice of something else.
(I actually own a 1982 VW van, but it has a Subaru engine transplant that allows me to actually get up to the speed limit now!)

Posted: **Fri Feb 14, 2025 1:12 am**

Kdjanz wrote: ↑Thu Feb 13, 2025 11:26 pm
https://www.electronjs.org/
I hate electron with a passion because it creates slow to load, huge apps that always feel fat and sluggish to me.

I wonder if that may vary by app.

I've never seen any xTalk app with the audience size some of these have:
https://www.electronjs.org/apps

Posted: **Fri Feb 14, 2025 2:45 am**

I agree that there are lots of electron apps out there, and I regularly use 8 or 9 of the apps on that screen. It's much easier for the developer to use that engine to make life easy across all the platforms, so I understand the why.

But I can almost always tell which ones they are on the first run. It takes them longer to start up and put something on the screen, then there is a pause while the content updates and flows in. Once they are up and running, the interaction is fine, but I almost never quit and pop back into an app because of the startup delay. The other dead giveaway is the size on disk. To pick just one example, GitHub Desktop is 413.7 Meg on disk for an app that has no graphics or built in database or any other "heavy" components - except the Electron Framework folder is 242 Meg just by itself. The app code is the other 172 Meg. That one app is 50x bigger than my first Mac hard drive! You get 10 of those apps on your drive and you are in Gig territory. The Ollama app has an Electron framework of 382 Meg. So there is just no way that any Electron app will ever be called "lean and mean".

We can accept that on the desktop with SSD drives of wonderful capacity and M series processors that still amaze me. Don't even think of portable devices with that sort of overhead though.

Posted: **Fri Feb 14, 2025 5:18 am**

Kdjanz wrote: ↑Fri Feb 14, 2025 2:45 am I agree that there are lots of electron apps out there, and I regularly use 8 or 9 of the apps on that screen. It's much easier for the developer to use that engine to make life easy across all the platforms, so I understand the why.

Yeah, that's also why I choose xTalks for some projects. Time-to-market has value.

But I can almost always tell which ones they are on the first run. It takes them longer to start up and put something on the screen, then there is a pause while the content updates and flows in. Once they are up and running, the interaction is fine, but I almost never quit and pop back into an app because of the startup delay.

I used to blame that on C++.

But with any engine, a lot of that is the framework used. I was a tester for Adobe back when they acquired GoLive. The original code from those admirably crazy Rhinelanders was blazing, but the first new version after the acquisition was slow as molasses in winter. But the original was Mac-only and Adobe's in-house framework was xplat, so on balance the company felt the trade-offs were okay.

Posted: **Fri Feb 14, 2025 5:03 pm**

FourthWorld wrote: ↑Fri Feb 14, 2025 5:18 am I was a tester for Adobe back when they acquired GoLive. The original code from those admirably crazy Rhinelanders was blazing, but the first new version after the acquisition was slow as molasses in winter. But the original was Mac-only and Adobe's in-house framework was xplat, so on balance the company felt the trade-offs were okay.

My biggest complaint about GoLive was always that it inserted pointless extra tags / cruft in its generated in the HTML output, which in a time when you were lucky to get 3kpbs MODEM transfer speeds, was absolutely a deal breaker. I'm pretty sure that trying to use GoLive is what prompted me to start writing my 'Tarantula' HTML editor (HyperTalk of course, but used lots of XCMD/XFCNs). To be fair the web landscape was rapidly evolving at the time.

Posted: **Fri Feb 14, 2025 5:57 pm**

Kdjanz wrote: ↑Fri Feb 14, 2025 2:45 am I can almost always tell which ones they are on the first run. It takes them longer to start up and put something on the screen, then there is a pause while the content updates and flows in. Once they are up and running, the interaction is fine, but I almost never quit and pop back into an app because of the startup delay. The other dead giveaway is the size on disk. To pick just one example, GitHub Desktop is 413.7 Meg on disk for an app that has no graphics or built in database or any other "heavy" components - except the Electron Framework folder is 242 Meg just by itself. The app code is the other 172 Meg. That one app is 50x bigger than my first Mac hard drive! You get 10 of those apps on your drive and you are in Gig territory. The Ollama app has an Electron framework of 382 Meg. So there is just no way that any Electron app will ever be called "lean and mean".

I agree with your criticisms of Electron.
But I also recognize that anything that is going to be usable as a general purpose pseudo-platform capable of implementing all sorts of applications is going to be rather large. They are large and slow to initialize for the same reason that in OXT the included Chromium CEF framework with copies for multi-platforms is what makes the IDE so extremely large (just compare the disk-space size to LC Community version 6.x) and I imagine that standalone apps that use the CEF-based Browser Widget (Windows & Linux builds) are similarly slow to load from disk.

However... Electron is not the only the only web-app-to-desktop-app wrapper around. Just about every major OS out there already ships with some Browser engine baked in. So all we really need is an basic desktop app-shell that creates windows with a WebView to display 'Stacks' (which would be custom HTML pages), and some methods to facilitate sending messages between those stacks and for doing 'bare-metal'/desktop-app things like direct access to filesystem, command-line tooling, OS APIs, etc. Decker is a good example for that in a minimal way that does not bundle a browser engine. it has very small desktop app versions that can be set to allow running shell scripts.

And also using Web Assembly .wasm modules offline does NOT necessarily even require any browser or javascript engine, various other languages can already interact with .wasm modules or even run AS wasm modules themselves. They can be used in ways similar to a Java VM.

Also note that a JavaScript engine is NOT the same as a web browser engine (although Browser Engines typically include them), it's fairly common to run JS without any 'web' these days. For example these days Apple ships macOS with 'JSX' Javascript interpreter as an OSA (same as AppleScript) included in the box. I could imagine an xTalk wrapper around v8 JS (not web) engine that creates its visual output in windows using Cocoa, GTK, Qt. or whatever, like wise I can imagine an xTalk interpreter in the form of a library wasm module (interestingly I recently discoverd that MetaCard interpreter was once available to use as a shared-library, embedded into another app similar to common use-case of Lua).

Posted: **Fri Feb 14, 2025 6:21 pm**

tperry2x wrote: ↑Sat Feb 01, 2025 12:21 pm but the eraser tool... didn't. (it draws on the canvas with a brown line)"
My guess is that the 'background color' is set to brown, so you are erasing, to a brown background. But the point of that Qt demo was not to be web-Photoshop it was to show that Qt widgets working in a browse. It loaded in much less time on my end (of course I tried it on a beefy Graphics production oriented workstation and wired gigabit connection).

"Why can't the emscripten plugin [engine] (which never ever really worked did it?) - why doesn't it work like that?"

It doesn't work like that because it's 1) unfinished and NOT compiled to web assembly format, it's compiled with older ASM.js based version of Emscripten. Re-compiling to .wasm could cut the current 28+MB file-size in half, and speed up execution. Either way the loading-time should be much faster if loading from local storage (specially with m.2 SSDs).

IMO, the main advantages of WebASM is NOT code opaqueness (I see that as a DISadvantage), it's the execution speed and the ability to compile existing code from desktop dev, like OXT's C++ engine code, into byte-code that can work on anything that supports running wasm.

Posted: **Fri Feb 14, 2025 6:21 pm**

tperry2x wrote: ↑Sat Feb 01, 2025 12:21 pm but the eraser tool... didn't. (it draws on the canvas with a brown line)"

My guess is that the 'background color' is set to brown, so you are erasing, to a brown background. But the point of that Qt demo was not to be web-Photoshop it was to show that Qt widgets working in a browser. It loaded in much less time on my end (of course I tried it on a beefy Graphics production oriented workstation and wired gigabit connection).

"Why can't the emscripten plugin [engine] (which never ever really worked did it?) - why doesn't it work like that?"

It doesn't work like that because it's 1) unfinished and 2) NOT compiled to web assembly format, it's compiled with older ASM.js based version of Emscripten. Re-compiling to .wasm could cut the current 28+MB file-size in half, and speed up execution. Either way the loading-time should be much faster if loading from local storage (specially with m.2 SSDs).

IMO, the main advantages of WebASM is NOT code opaqueness (I see that as a DISadvantage), it's the execution speed and the ability to compile existing code from desktop dev, like OXT's C++ engine code, into byte-code that can work on anything that supports running wasm.

OpenXTalk Forums

BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!

Re: BIT-ROT!