Comments on 0.94

[tperry2x]

Please discuss all comments on 0.94 here. Trying to keep the 0.94 download topic clear of comments, just so users can easily find it.

Download links for OpenXTalk Lite 0.94
These links remain the same as in previous versions.

Firstly, the mac version is offline at the moment as I'm having a few issues with Gatekeeper again. I hope to have this dealt with either tomorrow or at least by the end of the week.

What's changed?

• Removed the theming as it was inconsistent across different platforms (this needs to come from the engine to truly be accurate).

• Added the option for Tool Snippets, which can be toggled off in the preferences - so that newly created objects have sample code pre-applied (good for those new to XTalk)

• The draggable top bar containing the "Code, Inspector, Group" etc, - the draggable option can be toggled via the preferences now.

• Because the "Player" (video) tool is so broken and can cause a spontaneous crash on some versions of linux, added the option to disable this under "Compatibility" mode in the preferences.

• Added a global variable for getting the system version (as 'get the SystemVersion' did not function correctly under MacOS 11+). You can now use 'put tSystemVersion' - returns "MacOS 14" for example. You can alternatively use 'put tSystemVersionNumber' to just get the short version string. - will tweak this in future so it hopefully replaces the SystemVersion command entirely.

• Other changes since 0.93 include fixes to a few other colour swatch applying bugs in the preferences.

• Changes to the preferences path (no longer uses runrev for preferences location), uses ~/.xtalk for example.

• Modified the windows Installer so you don't get prompted / stopped by a previous existing installation.

• Added a few extra "Colorization" options for the script editor - you have a choice of more colour themes in the preferences.

Mac: .../sites/openxtalk/openxtalk-lite-0.9-osx.dmg (offline currently)
Linux: https://www.tsites.co.uk/sites/openxtal ... 9-linux.7z
Windows: https://www.tsites.co.uk/sites/openxtal ... 0.9-win.7z

List of known issues (as they unfold):
https://www.openxtalk.org/forum/viewtop ... 4441#p4441

NICE!
BTW: The OpenXTalk Mac Native library already includes a function macOSVersion(), which is an LCB library but it just evaluates a regular xtalk script that calls a shell() function to get the accurate macOS version, using same method that the macOS System installer uses.

Theming / DarkMode on Windows 10 probably does require engine level change to really do dark window frames (unless you 'fake' your own window frames for ever window in the IDE), but I'm curious is anyone running it on Windows 11? That has dark support from the get-go, where on Win10 it's an after thought, with some devs hacking undocumented stuff into their apps to support it.

But I prefer dark theme on Mac and Linux(es), and I don't think those really need engine level changes to support it on those platforms, maybe just some more work. The OXT macOS Native Tools library method of supporting darkmode on macOS however, is the proper way to do it on macOS, using Apple's API/AppKit, but the IDE/engine could definitely support it better then it currently does (which it does have some support for it on macOS). But yeah...it's never going to be consistent across platforms, that's somewhat of an issue with the platforms themselves I think.

Tool Snippets sounds really interesting, there was some sort of Snippets Pallette that was in the IDE at one point, but I wasn't sure if it that was useful because it seemed to be related to the advanced AutoComplete features (which was only in plus, commercial, indy versions) but I could be mistaken. There was some sort of script left in it, and it was functional for inserting the script into a script editor window, but didn't seem to have any snippet storage mechanism. I think it would be great to include such a thing, a 'scripter's scrapebook' for reusable scripts or just saving some quick notes. I would really like to have an OXT autocomplete (and spell checking, because that's a sore spot for me). I messed around with that idea using Trevor Devore's NSPell/ASpell cross platform wrapper library, created a xTalk syntax specific dictionary for it.

Draggable toolbars sounds good too.
I'd love it if we could have a palette similar in style and functionality to old QuarkXPress(3) measurements palette, horizontal layout, compact, but extremely useful. I did a bunch of work on a palette with the goal of building it, but it gets frustrating managing focus, selection, getting properties info from controls in other stacks, and that sort of thing. I'm starting to think maybe it would be better to entirely rebuild some palettes, like Tools, using widgets, existing separate from the Engine, but still having two-way communication with the IDE. Most of the IDE palettes all already use widgets for the gear/palette-settings pop-out menu).

Added a few extra "Colorization" options for the script editor is much needed, I'd really like to make a mechanism (as opposed to being "hard-coded") for adding custom sets. If the default color or 'no color' could be made to really have the value 'empty' instead of "0,0,0" (which is RGB Black, and not the same as empty) then it would auto-change from light/darkMode when toggling that in the macOS system menu. As it is now you have to manually switch SE to the darkMode script either theme in order to have scripts default coloring be white text, not a real big a deal as most people would probably set it the way they like and then forget about it.

"Because the "Player" (video) tool is so broken"... is it? I was't aware it was a problem, but I haven't really ever much tested the built-in player object on Linux(es)... are they like window layering issues or what? I'm going to have to spend some real quality time with the Linux build again.

I really need to get more into building extensions on Linux, I'm sure a player object could be built, maybe using libVLC or FFMPLAY, that could be a suitable replacement. Incidentally I've been messing around with FFMpeg/FFMplay using shell scripts to play files, render audio waveform images, convert media formats, etc. FFMPEG has become quite a capable multimedia system over the years, mixing, muxing, etc. can even do streaming/and serving streams (like act as standard DLNA media server).

Anyway thanks for the work! I will give this a spin this long holiday weekend (Thanksgiving here in the states).
I'm going to try to make some videos to put up on OXT YouTube channel too, if I'm not in a food coma from gorging on pies.

[richmond62]

I do hope you will "ruin my weekend" as my digestive juices floweth, my vampire teeth drippeth, and the weekend approacheth: and all that I need is a Mac build to take for a walk on both MacOS 12 and MacOS 14.

[richmond62]

For anyone who might care hereabouts, while systemVersion is problematic in LC 963:
-

Screenshot 2023-11-22 at 12.47.53.png (79.7 KiB) Viewed 1077 times

-
LiveCode sorted things out at their end somewhere before LC 9.6.11:
-

Screenshot 2023-11-22 at 12.46.49.png (74.24 KiB) Viewed 1077 times

-
It would be interesting to know if systemVersion were buried in the engine, or in a file floating around where one could get at it with relative ease.

[tperry2x]

It would be interesting to know if systemVersion were buried in the engine, or in a file floating around where one could get at it with relative ease.

Seems to have been done in 9.6.8
(page 9 of this document)
https://tekkieuni.livecode.com/LiveCodeNotes-9_6_8.pdf

Typically, it doesn't mention if this was in the engine or in some livecodescript file somewhere.

9.6.8 is also when they added native ARM support for macs too. Something we are also lacking currently.

I should add that the links for 0.94 mac version are now also back online too, so feel free to test away!

[richmond62]

9.6.8 is also when they added native ARM support for macs too. Something we are also lacking currently.

Indeed.

The last time I set foot in an English Primary school was in 1973.

The last time I set foot in an English state Secondary school was also in 1973.

The last time I set foot in a Scottish Primary school (as part of my work with a focus group of teachers for the thesis of my second masters degree) was in 2003, as, similarly a Scottish Secondary school.

Those would not have recognised an Apple computer if it had hit them in the head like a 10-ton truck.

Certainly 'Hello World' looks distinctly 100% Windows.

BUT, you, being "right there" can confirm if my suspicions are right that native ARM support for Apple machines is neither here nor there re English Primary schools.

[richmond62]

It seems pretty clear to me that change has been done inside the engine:
-

Screenshot 2023-11-22 at 13.48.40.png (154.53 KiB) Viewed 1068 times

-
"The engine will now return . . ."

[tperry2x]

...you, being "right there" can confirm if my suspicions are right that native ARM support for Apple machines is neither here nor there re English Primary schools.

You are spot on.
From what I gather, most schools have implemented Windows PCs because they are cheaper. It all comes down to number of units required, and you can put in a Windows PC for a fraction of the cost of an Apple equivalent.

Shiny new macs in education, seem to be in the minority.
The majority will be windows users, or people running older apple hardware that isn't ARM ready anyway. Rosetta 2 offers a compatibility layer, so at least people with shiny new ARM-based macs can run intel x64 programs for a short period (until Apple decide to axe this altogether, which they will probably sooner rather than later).

At which point OXT (lite and RC) will be dead in the water if we haven't got a native ARM engine ready to go.
So, I currently view Mac support as being 'more broken' than on any other platform as far as OXT is concerned (or any fork that's based on the LCC 9.6.3 version). If Rosetta 2 went away tomorrow, then Mac users on ARM would have to run it via some other emulation layer (such as Whiskey)
https://github.com/Whisky-App/Whisky

[tperry2x]

It seems pretty clear to me that change has been done inside the engine

Sorry, that's what I get for trying to multitask - and failing miserably.
That's a real pity that it's locked away in the engine somewhere.

I wish I knew where. I may go and have a look at some point and see if I can track it down further.

It may well be buried deeper and abstracted further somewhere else.

[richmond62]

1. Re ARM Macs: until recently I was running LC 963 for Windows perfectly acceptably on MacOS 14 Sonoma via WINE 8.

2. Another way to do things:
-

Screenshot 2023-11-22 at 14.00.45.png (104.71 KiB) Viewed 1066 times

-
(Not me being clever: stolen from elsewhere)

Presumably there isn't someway to bypass whatever is written in the engine?

[richmond62]

By adding 4 lines to the Menubar livecodescript file:
-

Screenshot 2023-11-22 at 15.00.53.png (17.47 KiB) Viewed 1058 times

-
You can do this:
-

Screenshot 2023-11-22 at 15.01.11.png (44.32 KiB) Viewed 1058 times

[tperry2x]

The only two references I can find to SystemVersion (aside from the dictionary documentation files) are here:
https://github.com/tperry2x-uk/OpenXTal ... cs.h#L1447
and
https://github.com/tperry2x-uk/OpenXTal ... e.cpp#L169

Nothing that I can really 'get my teeth into' and override.

By adding 4 lines to the Menubar livecodescript file...

True, but then there we are - this is where I am with my attempt. We are calling a secondary function, or variables and writing as an additional thing. Ideally, I'd like to replace systemversion altogether, if only I knew where.

if you open 0.94, and run:

Code: Select all

edit the script of stack "Home"

in the message box, you'll see on line 1543 that I actually use the exact same command (I lifted it from elsewhere too - probably the same place, as it seems to be a recognised & documented (and apple api approved) method of doing it).

Screenshot at 2023-11-22 13-11-49.png (5.73 KiB) Viewed 1057 times

[richmond62]

Nothing that I can really 'get my teeth into' and override.

I don't think that really matters as between the 2 of us we have found 2 ways to produce what we want.

[tperry2x]

Re ARM Macs: until recently I was running LC 963 for Windows perfectly acceptably on MacOS 14 Sonoma via WINE 8.

The only issue with that, despite the name and assertions that 'it's not an emulator', everyone uses it as if it were.
Wine only provides a way to run x32 and x64 bit programs. There currently isn't any way of running it natively on ARM. By running wine, you are actually running it through Rosetta 2 first, then running it's x32 or x64 windows compatibility layer to then start your windows program.

If you take the Rosetta 2 part out of that series of events, you cannot first start wine natively under MacOS [whatever version they drop Rosetta 2 in].

Whiskey is at least ARM-ready, so would potentially provide a way to continue running a virtualised copy of OpenXTalk, although this does raise several other issues.

Namely, it assumes someone is happy downloading and configuring homebrew, building Whiskey from the github source, and then setting up their virtualised copy of OXT [whatever version] as a 'bottle' inside of it.
(This is all before they even get to the stage of opening OXT)

If I assume they did all that, a simple File > Open command then presents the windows file select dialog where you'll see mention of C:\ (or Z:\ for the rest of the local mac filesystem) Mac users won't necessarily feel comfortable / happy with any of this. It won't feel like using a Mac app in the same way that opening a native program does.

That's not to take away from the accomplishments of Wine / Whisky at all. It's amazing what they are accomplishing, however it does require a user to jump through multiple hoops that they may not be comfortable with.

This has always been the issue with the likes of Microsoft Visual Studio, where just to get the IDE open, you have to download close to 3 ~ 4 GB worth of supporting windows libraries. I don't want OXT to have to go that route, and feel it would be far better to attract a talented soul who can lend a hand in producing a native arm-ready engine.

It increasingly seems to be coming to a point where we can't avoid the elephant in the room, which is the engine.

[tperry2x]

I should also add to the above post, keeping iOS support will then offer another potential in-road into running arm apps 'natively'. If we could get ARM support for iOS working, It could in theory be possible to have iOS standalones running natively on your desktop - as recent MacOS should be able to run ARM-based iOS apps as if they were desktop ones.

This would offer a feasible method for developers looking to produce an 'ARM-app' with OpenXTalk, and run it on desktop MacOS, but again this isn't a 2 minute fix.

[richmond62]

There are probably only 3 reasons why a clever person might come forward to make ARM builds:

1. Money.

2. Self interest (might be cheaper to do that than fork out for LC licences).

3. Have an urge to make LC sit up and take notice and realise there is direct competition.

I do hope someone will come forward for reason 2 or 3.

[tperry2x]

There are probably only 3 reasons why a clever person might come forward to make ARM builds

Now you are just trying to cheer me up

[richmond62]

(I lifted it from elsewhere too - probably the same place, as it seems to be a recognised & documented (and apple api approved) method of doing it)

I lifted it from the bug report about "10.16"

[foxtrot47]

There are probably only 3 reasons why a clever person might come forward to make ARM builds:

1. Money.

2. Self interest (might be cheaper to do that than fork out for LC licences).

3. Have an urge to make LC sit up and take notice and realise thete is direct competition.

I do hope someone will come forward for reason 2 or 3.

I don't know anything about ARM, but I'm pretty sure I can help with the IDE. However, my focus is on Item #2 (Self Interest) with a whole lot of nostalgia for pure xTalk.

Over the Summer I tried to setup a Virtual Machine (idea was a mobile dev environment) for compiling 963 from source, but failed miserably. Words you'd rather not hear from someone interested in your project, for sure, but I do have a knack for fixing bugs and finding solutions in complex systems I've never used before. My goal was to track down the windowing issue on Linux within the browser widget, and to fix the dark mode theming.

I felt like, what held me back, was simply the age of the supported Linux host OS. Ubuntu 14 and 16 were such a rabbit hole just to get things to the point where I could get something working half-way, but ultimately, I could never get a successful build just using what was provided. Again, totally in the deep end for me, but I like to try.

You folks have done wonders on the Linux side, so I'm asking, is it possible to stand up a compiler for 963 on Linux, right? Or does it have to be compiled (for now) on another OS?

[richmond62]

As I am currently running (apart from several Macs) LC 963 perfectly acceptably on Xubuntu 22.04 64-bit (my language school's computers from Content Delivery and Reinforcement ALL run that), Xubuntu 23.04 64-bit (one of my personal laptops), and Debian 12.1 XFCE 32-bit (my other personal laptop inherited from my father), I don't think you have to faff around with 8 or 9 year old versions of Ubuntu.

Ha, ha: I initially typed "Content Devilry" . . . closer than you realise.

Oh, and as the laptop I inherited from my father is about 20 years old (and, surprisingly, still working 100%), you should not have to rob a bank to get something usable up-and-running.

[foxtrot47]

That's positive news! I'll give it a shot this weekend with Xubuntu 22.04 64-bit, Xubuntu 23.04 64-bit, and Debian 12.1 XFCE 32-bit. Thanks