OpenXTalk Forums

I have just noticed that the colourisation for the script editor will not 'stick' between OXT Lite sessions.

OXT Lite 1.03

MacOS 14.5 beta 3

Anything past MacOS 11 for the 9.6.3 engine is where compatibility starts breaking for MacOS.
Did it do this before you ran beta versions of MacOS? I'm quite suprised it opens.

This is interesting as my script editor preferences for LC 963 are preserved on MacOS 14.5 beta 3, and OXT Lite's are not.

So my first question has to be:

1. Where are LC 963's preferences stored?

2. Where are OXT Lite's preferences stored?

2.1. Obviously the answer to #2 is different to #1: and if LC's preferences are stored is, say, a text file, then why aren't OXT Lite's stored in a similar way.

I do NOT believe this has got anything to do with it being 'Macintosh', but I think it has a lot to do with HOW and WHERE, and in WHAT format OXT Lite stores its preferences.

Poking around in my MacOS system I have found the following documents:

/richmond/Library/Preferences/com.runrev.livecode.plist and

/richmond/Library/Preferences/org.opentalk.plist

I have opened
/richmond/Library/Preferences/com.runrev.livecode.plist and saved a version of it elewhere, now I shall open LC 963 and reset my script editor colour preferences and compare the saved version with the /richmond/Library/Preferences/com.runrev.livecode.plist one:
- -
So script editor colour preferences are stored elsewhere.

They are the same format. Just a different filename.
Which preference about the colourisation isn't sticking? Do you mean the script editor colours, or the appearance swatch colours? or something else?

I mean the script editor colours.
- -

They are the same format. Just a different filename.

Obviously OXT Lite is not reading that file when the IDE boots up.

It depends.
Under 'Extras', do you have "Replace Script Editor Colours when selecting theme" turned on?
(Or View menu > Theme Preferences if you prefer).

You can also bring up the stack inspector for the "revPreferences" stack, scroll down to the custom property called "cScriptEditor,colorization,scheme" and see it change in there while you tweak the preferences. That will show you that the setting is being 'set' in the preferences.

As mentioned above, if you've got the 'replace script editor colours...' checkbox turned on, it'll match the script editor colours with your system theme The point of that, is so you don't go setting your system appearance to 'light mode', then open a script editor to find that it's in dark mode. Of course, like anything, you can turn that preference off.

I can confirm that the preference for this is 'sticking' here on Linux and Windows. Can't test on Mac at the moment as I don't have one available. I will verify this on MacOS 10.15 but won't be able to check past that OS version.

-
So: I have just set my script editor preferences:
- -
Now will quit OXT Lite and restart it:
- -
Reverted.

Here's a thought:
- -
Now a quit and restart:
-
Nope.

It would seem to me that, either:

1. Something is resetting my decision to the default one. or

2. OXT Lite is looking 'somewhere else' for script colourisation settings.

Oddly enough, with LC 963 the SAME thing is sticking:
-

richmond62 wrote: ↑Fri Apr 26, 2024 9:24 am Oddly enough, with LC 963 the SAME thing is sticking.

Perhaps your OXT prefs file is corrupt somehow?
You could try resetting it to defaults, or deleting it manually. I can't recreate that issue (this is on a MacOS VM, but it's what I have access to at the moment):

I opened OXT Lite 1.03 and set a script editor colour scheme. Quit OXT Lite fully, then reopened it to see if the pref would stick: (which it did).

I quit and reopened it again, just to be absolutely sure: I can see it already 'stuck' / remembered the pref as the message box syntax colours are correct.

As I say, I'll try and test this on other MacOS systems this evening at some point.

Indeed, deleting the file from inside the 'xTalk' folder solved that problem.

I t might be that that file was stuck from an earlier version of OXT Lite.

richmond62 wrote: ↑Fri Apr 26, 2024 11:33 am Indeed, deleting the file from inside the 'xTalk' folder solved that problem.

That's good to know. I'm glad that solved it.

It might not be a bad idea to include a 'Read Me' file with OXT Lite telling Mac users to delete that file whent they install a new version of OXT L.

I don't think it's connected to changing versions. For example, I've never had to trash or delete the preferences on the dev mac I use, and that's had the same prefs file from 0.96 all the way to 1.04 of OXT Lite - and hasn't ever shown any 'unsettable' properties.

I'm still perplexed as to why it wouldn't have saved the setting, and I've never seen that here. (Not something I can recreate), unless I set the permissions of that file to 'Read Only' or something weird like that.

Plus, if I wiped out everyone's settings each time I produced a version of OXT Lite, that wouldn't be received well either

I do agree.

I'll have a look at the settings on my MacOS 12 machine at home.

richmond62 wrote: ↑Fri Apr 26, 2024 1:25 pm I'll have a look at the settings on my MacOS 12 machine at home.

If something doesn't work on Monterey, please note that the 9.6.3 engine, upon with OXT Lite (Mac) is based, isn't officialy listed as compatible with anything higher than MacOS 11.
The fact it opens and runs on anything above MacOS 11 I'd say is a happy coincidence, but I certainly wouldn't expect it to be as solid as on MacOS 11.

One day, when the engine gets compiled for recent MacOS again, with updated libraries and fixes, then perhaps we can expand support for these newer MacOS versions too. Until then though, I'm not surprised that occasionally things go wonky on these MacOS versions or do unexpected things.

I mean, if you look at the "platform support" in that PDF, youll also note that Windows 11 isn't listed - and we get revCopyFile permissions blocked errors, the wrong UI drawn, and titlebars being drawn incorrectly in windows 11 as a result.

LC do point out that the linux version runs on anything with glibc 2.13 or greater, so that covers a huge array of distros (both past and present). Obviously I've found lots that doesn't work on linux, and am fixing as I go. - at least there I've been able to recompile using recent libraries and incorporating bug fixes from the updated dependencies you need for it to tie into. So, thats definitely the most supported 'engine' as far as all 3 platforms go (being the only one currently built on the 9.7 source).

However, I cant do this for Mac - just because I don't have compatible hardware to test it in. This is why I've repeatedly asked for help maintaining or fixing issues in the mac version.

Now, as time goes on and the operating system versions increase, I fully expect Mac OS support in particular to drop further behind. This is because mainly Windows has to retain legacy support for most stuff as used in industry, as does linux as used heavily for server infrastructure.
MacOS is the moving target here, and we are already seeing adhoc patches (as clever as they are), we are starting to have to emergency patch just to get MacOS versions to open.

Ultimately, all "engines' will lose support without being actively maintained and fixed at the c++ level. First the mac one, then eventually Windows and linux a lot further away.

They will be at the point the mobile engines are, losing support already for recent Android and iOS without a full time c-++ dev team.

So I'm very aware that all this work we are doing in OXT lite and OXT is great, but without the engine to run it, it's all a bit of a sticky-plaster on a bullet wound.

Preferences do stick here at home on MacOS 12.

Personally I am not interested in what stuff LC pumps out re whether LC works on MacOS 12, 13, 14 or what have you.

LC 963 DOES work on MacOS 14, and it does not play "silly buggers" with preferences I have stored on my 2018 Mac MIni when it was running the original MacOS 10.13 it came with.

OXT Lite did not do that.

So, writing about what bits of LC 963 might or might not work on MacOS 'Y' is neither here nor there and only serves as a distraction that something went wrong with OXT Lite om MacOS 14 which did not go wrong with LC 963.

You are missing my point. Im not talking about surface changes with the stacks and scripts in the ide, I'm talking about locked engine support.

As far as things breaking in oxt lite and not LCC, we are pulling OXT about here and there at everyone's whim, so it's not surprising we find things are broken and occasionally cause errors in implementing something new.

There's not exactly a manual that comes with this showing how its all intertwined. We are discovering that as we go. Well, at least Paul is and myself to a lesser extent.

So no. None of that is a "distraction", it's perfectly relevant and also inevitable - but you dont seem to want to hear it.

But you then seem surprised when something doesnt work in recent MacOS, and running it with beta versions of MacOS and expecting it to run correctly is a real gamble.

If you remember, LCC 9.6.3 crashes on MacOS 14 as it needed that patch for the menubar, supplied by Tom?

You are more than welcome to contribute and fix things in the ide yourself too you know? Even posting a code block on here saying I changed x at line y to solve problem z would be helpful, - do you not agree?

we are pulling OXT about here and there at everyone's whim

Lol: "everyone": at the last count it was about 5 or 6 people, with you doing all the pulling.

If you remember, LCC 9.6.3 crashes on MacOS 14 as it needed that patch for the menubar, supplied by Tom?

Yes, I do: but what is odd is that earlier versions of LC (8.1.10 for instance) run without any patching,

richmond62 wrote: ↑Fri Apr 26, 2024 5:53 pm Lol: "everyone": at the last count it was about 5 or 6 people, with you doing all the pulling.

It might be 5 or 6 people who play an active part in suggesting things, but each time there's an OXT Lite release, over 40+ downloads each time are going on. So there's a lot more eyes on this than you'd think. (as evidenced by my site it used to be hosted on referencing multiple geographic locations, shown in the server's back-end control-panel).

Myself and Paul on his version are the main contributors, yes. I only stepped in due to helping to take TerryL's efforts further - as he'd contributed a lot up to that point. I continued to take it further because not a lot was happening with it for a while. We could both probably do with more active contributors. So rather than just pointing out whats wrong, coming to the table with a working fix would be highly appreciated as I've hinted at before.

richmond62 wrote: ↑Fri Apr 26, 2024 5:53 pm ...what is odd is that earlier versions of LC (8.1.10 for instance) run without any patching,

Yes, right after unicode support was added [to the engine]
Note, engine. Not IDE (not stacks and scripts). Supporting my point above, this is why Windows and MacOS can run LCC 7 to 9.x on the same machine without a backwards glance, and is why you can't do that on MacOS.

Case in point, things that work on earlier versions of MacOS don't now work in later versions. (Systemversion, date and time reporting incorrectly etc). I can see these are fixed in the 9.7 source I have, but can't compile it of course for the Mac (insufficient hardware to do it on).

I could also be awkward and say that LC did exactly what I've done previously in that respect. Try to add something that is great on the face of it (unicode support also came with an updated font rendering routine that improved font rendering on the display massively), but there's something about that method of interpreting certain characters when filling out the menus which also caused a crash. It's also because the method for drawing the menus uses an older hook to initiate them, which isn't supported any longer. Again, fixed properly in the 9.7 engine. Of course, this only is a problem on the mac as menus in Windows and Linux are drawn differently.
(Which is why you can create a menu positioned in-stack without crashing an unpatched engine, but put it in the mac's main menubar in the unpatched engine and instant crash).

So adding something is very rarely without other consequences, some of which don't become apparent until later.... and they also have the benefit of knowing how this is all put together a lot more than we do!
Having slightly scathing comments about subsequent bugs would be understandable if it was commercial software you were paying for: but you aren't. It's free dont forget, so I'm not saying necessarily to lower your expectations, but be mindful we don't exactly have a team of people working on it for a living. I pour a lot of time into this, and other than doing it because I'm interested in it, I receive no financial reward for doing so.

Plus, doesn't really help that I'm essentially working blind when it comes to the Mac version. I might change something that seemingly works here up to MacOs 10.15 - but I don't know how it'll play on anything above that.
So, if you find anything broken - and having the benefit of that modern(ish) iMac - feel free to suggest some patches yourself.

Perhaps I should take a leaf out of Paul's book and only produce longer-term releases? I know Paul has stated before that his time to develop his version of OXT is far less than it used to be. Im sure he'd appreciate contributions just as much as I would. Help with either / both would be highly appreciated.
Plus. It's hard work and a largely thankless task. If all we are hearing are negatives to do with our efforts, then it kind of makes us think... "Why did I bother?" - which, again Paul has rightly mentioned himself. I would concur there are times where just another set of eyes on the script or the c++ code would do wonders. To have things pushed back at us with comments like 'preferences dont stick' is not very helpful, especially when I would have thought checking the preferences were not corrupt by trying the same thing on another mac would have been the logical first step, rather than the default being to point a finger back at me instantly.

It's hard not to take that kind of thing as a bit of an attack.
You could've said: I've tried this on two different macs and found it's an issue on both... That kind of thing at least is a better start.