Current binary downloads?

[FourthWorld]

I have a project on the horizon which must be GPL, and was hoping to consider OXT as a candidate for our choice of dev platform.

I was looking for the most recent stable build which includes the Sonoma menu fix, along with Linux and Window downloads. I could not find these on the OXT Downloads page.

Where I can I find those?

[richmond62]

https://openxtalk.org/forum/viewforum.php?f=16

OXT Lite 1.05 runs well on MacOS 15.

[tperry2x]

OXT Lite 1.05 runs well on MacOS 15.

However, the standalones may crash MacOS 14 (and above) if you add a macOS-style menu.
I have removed the Sonoma menu patch back in 1.04 as the patch was causing image corruption.
(release notes, look under 1.04 and the 'unpopular change' for Sonoma users).

Now for the unpopular change (at least for Mac users on Sonoma): Richmond discovered that the Mac standalone will occasionally corrupt images, or leave them entirely blank. I traced this down to the menubar code-patch, as removing it immediately removes the image corruption. This unfortunately means that if you use a Mac-style menubar (as opposed to a stack-placed menubar) in MacOS Sonoma, the standalone will crash.

[richmond62]

standalones may crash MacOS 14 (and above) if you add a macOS-style menu

I didn't see that printed on the packet.

A warning re that on the downloads 'place' might be a good idea.

[tperry2x]

I didn't see that printed on the packet.

"Using this with MacOS will seriously damage your health. Quit now" ... something like that?
We did mention that here (We had a discussion on 'unpatching' the engine as part of your Devawriter tests).

[FourthWorld]

OXT Lite 1.05 runs well on MacOS 15.

However, the standalones may crash MacOS 14 (and above) if you add a macOS-style menu.
I have removed the Sonoma menu patch back in 1.04 as the patch was causing image corruption.
(release notes, look under 1.04 and the 'unpopular change' for Sonoma users).

Now for the unpopular change (at least for Mac users on Sonoma): Richmond discovered that the Mac standalone will occasionally corrupt images, or leave them entirely blank. I traced this down to the menubar code-patch, as removing it immediately removes the image corruption. This unfortunately means that if you use a Mac-style menubar (as opposed to a stack-placed menubar) in MacOS Sonoma, the standalone will crash.

Thank you for the link and that background. Unfortunately the situation makes OXT a non-starter for this project, which requires a menu bar and image display.

[tperry2x]

Using OXT Lite 1.04, (or LCC 9.6.3 for that matter) will result in the same crash if you run it in Sonoma or above with a MacOS-style menubar and custom menus.

[FourthWorld]

Using OXT Lite 1.04, (or LCC 9.6.3 for that matter) will result in the same crash if you run it in Sonoma or above with a MacOS-style menubar and custom menus.

Thank you. As an Ubuntu fanboy I have my own OS preferences as well, but the world chooses what they choose, so all I can do is pick the tools I need to meet my users where they are.

[FourthWorld]

I've reviewed the original bug report for the menu issue, and if I'm reading it correctly it appears to be triggered by the engine's routines that move standard menu items from their standard locations ("Quit", "Preferences", and "About"), and only if those items are not in their expected positions within their respective menus.

If my understanding is correct, this issue will not affect any developer who puts the HIG-specified menu items in their standard locations - is that correct?

If so, yeah, it needs to be addressed for general use because we can't predict what people will attempt with their menus, but it may not be a non-starter after all for app designers conforming to Apple's design guidelines.

Is my understanding of the limited scope of this issue correct?

[richmond62]

We did mention that here (We had a discussion on 'unpatching' the engine as part of your Devawriter tests).

Other people may not be that interested in digitising ancient Indian manuscripts (I cannot imagine why), so may not have read our discussion.

[tperry2x]

Logically, I suppose if you are developing an app for the mac, you'll probably want to include the about menu, quit, help etc to make it appear like a standard Mac App.

If you are building a standalone for Linux and Windows, then it's not an issue.

The issue only comes about if you were developing your app for Linux and Windows, then later build for MacOS - but forget to add these Mac specific menus and menuitems in.

I was wondering about an alternative way to approach a fix for this. In the menu builder stack, if the 'as macOS menubar' is ticked, it could check for the existence of these required menuitems and menus, and offer to add them in. Perhaps with a confirmation dialog explaining why they are needed for MacOS compatibility.

I mean, if you are adding the menus as in-stack, then the menuitems and specific menus don't need to exist. You'd only set the menus to display as a MacOS menu bar if you were building for MacOS (right?).

So at that point, it could offer to populate any missing menuitems and menus as needed.

[FourthWorld]

The issue only comes about if you were developing your app for Linux and Windows, then later build for MacOS - but forget to add these Mac specific menus and menuitems in.

Thank you for that confirmation. I had previously overestimated the scope of impact from that issue. Now that I recognize the limited scope, it won't affect the app being considered here.

The only remaining concern is longer term, the eventual need to run natively on m-series processors. I think Paul's estimate of 24+ months remaining for Apple to continue dual-architecture support is reasonable, given that company's history. I'd like to believe that buys enough time to figure out the recompile.

This is encouraging. When a GPL-licensed app is needed, OXT seems a viable option. And where xTalk is needed for that, it's the only viable option.

[OpenXTalkPaul]

The issue only comes about if you were developing your app for Linux and Windows, then later build for MacOS - but forget to add these Mac specific menus and menuitems in.

Thank you for that confirmation. I had previously overestimated the scope of impact from that issue. Now that I recognize the limited scope, it won't affect the app being considered here.

The only remaining concern is longer term, the eventual need to run natively on m-series processors. I think Paul's estimate of 24+ months remaining for Apple to continue dual-architecture support is reasonable, given that company's history. I'd like to believe that buys enough time to figure out the recompile.

This is encouraging. When a GPL-licensed app is needed, OXT seems a viable option. And where xTalk is needed for that, it's the only viable option.

We love the Nichéiest of Niché markets here

Until we can get this fixed in the Engine code, I wonder if we can't at least ensure the IDE doesn't allow those menuItems be specified in the wrong locations. I mean modify the IDE so that it doesn't do try to do that, update menuBuilder to check for those items in non-standard position.

I also still wonder why the patch affects images in standalones? Does it twiddle a wrong byte somewhere? And was this not something that Apple strictly enforced prior to Sonoma or just was it NSMenu API changes that triggered it? Obviously it would be best to have it fixed so as to not allow it on the Engine level.

I'm becoming a big fan of Web based, WebAssembly is about as platform agnostic as possible (perhaps already more so than Java bytecode ever became).

[tperry2x]

I'm becoming a big fan of Web based, WebAssembly is about as platform agnostic as possible (perhaps already more so than Java bytecode ever became).

The thing is, because OXT is essentially put together in, well... OXT - it truly is something that we can all get involved with tweaking. With WebAssembly, it's a pain to edit compared to xTalk script. Plus it can be quite an ugly-language when typed, and can be comparatively confusing to follow - I'm guessing that is probably the barrier to a lot of people.

[OpenXTalkPaul]

I'm becoming a big fan of Web based, WebAssembly is about as platform agnostic as possible (perhaps already more so than Java bytecode ever became).

The thing is, because OXT is essentially put together in, well... OXT - it truly is something that we can all get involved with tweaking. With WebAssembly, it's a pain to edit compared to xTalk script. Plus it can be quite an ugly-language when typed, and can be comparatively confusing to follow - I'm guessing that is probably the barrier to a lot of people.

I doubt many (any?) people are coding in straight Web Assembly. People have mostly been compiling to the format, existing libraries, C++ and language runtimes. Stuff that previously could only be used on the desktop are being ported / reccompiled to .wasm bytecode modules that run in web (as the platform) with native(ish) performance.

Basically OXT's web engine is like 'MetaCard+' compiled to Emscripten so that it runs inside an HTML5 browser, as virtual machine with a virtual file system attached (runs in sandbox) and with two-way bridge of sorts for xTalk<>JS. The point is you could a lot of stuff with that web engine without knowing how to write ANY code directly in WebASM. And like some other 'playgrounds' we can use free GitHub as a free host for this web-app version. I think we could at least get it to be much-more like the IDE but running on web tech. Would need to add in a 'Tools' stack and a basic 'ScriptEditor' stack (or use Web stuff for that and as 'Message Box'). I did some tests a while back where I added in parts of the OSS version of MetaCard IDE, but haven't made time to explore that idea further. I was imagining it could allow for exporting stack's to HyperSim's Stack-as-HTML format, like as a stack export option (export to 'HTML standlone'...).