OpenXTalk Forums

so you'll always end up with these files needing to exist even if you were to override it later in the home stack

That shouldn't matter, but having overrides in Home stacks would solve the problem of 2 slightly different IDEs on one machine [say, 1. with widgets available, and 2. with widgets 'buried'] interfering with each others' preferences,

I'm not sure I follow. By widgets interfering, do you mean if you had duplicate widgets installed in the same folder as the program and also the same widget installed in the user's home folder?

Having had a quick poke around the code in github (I ended up getting the whole thing and poking around offline), it seems that it takes what's in the user's home "My Livecode" as precedent, - so it doesn't seem to load the same thing twice.

Paul knows this far better than I though, so I'm sure he can correct me if I'm wrong (and please feel free if I am indeed wrong).

My point with the stuff that gets loaded before the home stack was, if "~/.runrev/licenses/livecode-firstrun.lcf" isn't available, then the registration dialog is called.
This is the same dialog that prevents you loading older versions of Livecode (PPC ones) as you can't register anymore.
They just got rid of the registration requirement with a skip button. They didn't delete the dialog altogether though. That seems to be engine-specific.

So even if you were to edit the home stack, because the existance of "livecode-firstrun.lcf" is checked well before that, users will always get the registration dialog no matter what you do to the home stack.
This is why using "touch ~/.runrev/licenses/livecode-firstrun.lcf" creates a blank file and LC/OXT is happy and carries on loading, onto the home stack and everything else regardless, as it thinks you've already done the registration step.

This is why Paul also created the "Run this first.app" in the RC mac builds, which was an Applescript that made this file.

The same as the engine always looks for the file "~/.runrev/preferences/livecode7.rev" because that is hard-coded in the engine way before anything else is even loaded. So you can't later specify to use "~/.runrev/preferences/openxtalk.oxtstack" because as far as the engine is concerned, it's "livecode7.rev" or nothing.

richmond62 wrote: ↑Tue Oct 31, 2023 5:32 pm I am now poking around inside the 'Home' stack to see if there is any code that tells it to look for the 'livecode7.rev' file in the User's folders, and whether or not we can squash that and replace it with something called, say 'OXTsettings.rev' that is app-specific rather than a general prefs file for all installations of OXT and LC.

There is, OXT DPE does make its own OpenXtalk folder and its own openxtalk.rev prefs file, which it will generate from livecodes pref .rev file if it finds one on first run (could be easily changed to not do that)

I'll have to see if I can find exactly where I had to change it...

tperry2x wrote: ↑Tue Oct 31, 2023 6:31 pm True, although it's down to the order things load.
Because as far as I can tell, the engine deals with these things before it even starts reading stacks, so it always looks for these things before the home stack loads - so you'll always end up with these files needing to exist even if you were to override it later in the home stack.

This needs changing at compiler level in the engine to truly change it.

As far as I can tell, the only file that the IDE engine actually looks itself, before the IDE startup handler starts, is that damned license file, which if you can use another method to create a dummy license file first (AppleScript, VBScript. shell script, etc.) then that takes care of that check (and you never see that embedded registration stack pop up). Everything else seems to be handled in that startup handler or in the chain of stacks that it loads up (the IDE libraries), including searching-for/creating /naming the prefs file (in "~/Library/Application Support/OpenXTalk/" on macOS) and the "My OpenXTalk" folder in the user's documents folder.

For that license file... I wonder if that may be attached to some IDE global, or to an environmental variable, because you can pre-set those via a key in the apps info.plist file on macOS and similarly do that via a launching shell script on Linux and Win. I also wonder if some kind phantom stranger couldn't swoop in and employ the same sort of memory debugging hackery to edit the binaries in order to skip that license file check entirely.

Also...have to remember to contact Mark W. about his Linux binaries building progress. I think it's time to really start looking more seriously at building these binaries ourselves.

OpenXTalkPaul wrote: ↑Fri Nov 03, 2023 12:01 am There is, OXT DPE does make its own OpenXtalk folder and its own openxtalk.rev prefs file, which it will generate from livecodes pref .rev file if it finds one on first run (could be easily changed to not do that)

I'll have to see if I can find exactly where I had to change it...

Line 419 and surrounding scripts in OXT DPE home stack:

https://github.com/OpenXTalk-org/OpenXt ... cript#L419

Around Line 506, you can see where I changed it to use OXT's own prefs folder/file:
https://github.com/OpenXTalk-org/OpenXt ... cript#L506

I did not know you could use: Thanks for the tip Paul, I'll look into using this for the OXT Lite builds.

Okay, have had a look at this.
Can I please propose a change to your github code:
I'd like to specify a variable tForkName, so rather than having to change the path multiple times, you can just change it here for whatever your fork is called:
Complete changed section of code, commented (based on your bit and mark's bit put together): I'll also attach this in plain text form: Have confirmed this works in testing, like so:
My changes on my site are updated with this modification:
https://www.tsites.co.uk/sites/openxtalk/oxt-changes.7z
https://www.tsites.co.uk/sites/openxtal ... s.livecode