A special note for mac users

[tperry2x]

Hi everyone.
You may notice I've just posted links to 0.95.
I'm experimenting using a new place to host this, so please let me know if you can't download.
This is a special note for mac users really. The codesigning should now work, but there is updated information you'll need to follow inside the DMG. Please follow this carefully and step-by-step (you can miss out the bit about creating the firstrun file if you've used OpenXTalk on that computer before).

I have my fingers crossed that this rectifies the issues seen since we started modifying the plist files and version information in the "Get Info" dialogs, as we are now signing with a development certificate. (which is free, and lasts for a year at a time). It can always be re-signed at a later date with an updated certificate. Instructions in the DMG as I say.
Many thanks.

[micmac]

Hi Tom

The certificate resulted in two identical error messages:

Did not find the designated keychain.

Mic

[richmond62]

Hi. Mic,

read my 'guff' here: viewtopic.php?f=14&t=611

as the whole cert. thing on my machine, at least, turned out to be completely unnecessary.

Best, Richmond.

[tperry2x]

The certificate resulted in two identical error messages:
Did not find the designated keychain.

viewtopic.php?p=4817#p4817
As I mention, adding the certificate is probably overkill for most people, however it's just in case people can't open it. Think I can call this rectified (although don't want to jump to conclusions too early).

I'm already chalking it up as 'a win', as 0.94 wouldn't even open for a few people on the Mac.

[Kdjanz]

Downloaded 0.95 without problems.
Followed instructions on the keychain and terminal work and then moved the app to the Applications folder.
Double clicked the icon and got the usual message about an unsafe app that could not be checked...blah, blah, blah
Right clicked on the icon and chose Open and things fired up perfectly as expected. Subsequent runs of the app were absolutely normal.

Two Issues though:
1. I have a high res monitor 3200x1800 and a low res 1920x1080. The high res is on the left and has the menu bar on it. I like to program on the low res side because text is larger and easier on old eyes. 0.95 started on the high res however and I cannot figure out how to move the toolbar over to the right screen for working. Most modern Mac programs have a Window menu on the menubar and it has commands to move the program to the other monitor. When I create a new stack, the window opens with the title bar off in space off the top of either monitor and I have to faf around with the Message box to bring it down to usable coordinates.

2. I went to settings and wanted to turn on Automatic updates to make future life simpler. When I turned it on and clicked the Check now button, I got some cryptic text saying I had to run a shell script using sudo. The script file was on my desktop and looked benign to me, so I did what I thought it was asking. Here is my terminal session:

Code: Select all

kdjanz@Mac-Studio ~ % sudo /Users/kdjanz/Desktop/xTalk_IDE_update.sh
Password:
sudo: /Users/kdjanz/Desktop/xTalk_IDE_update.sh: command not found
kdjanz@Mac-Studio ~ % sudo mv -f '/private/var/folders/1n/x98w3n9n31dfynx_rtvjb7vr0000gn/T/TemporaryItems/xtalk_updates/updatecache/202311241843/DevGuides.livecodescript' '/Applications/OpenXTalk Lite.app/Contents/Tools/Extensions/community.ferruslogic.plugin.devguides/DevGuides.livecodescript'
rm -f '/Applications/OpenXTalk Lite.app/Contents/Tools/.buildnumber'
echo '202311241843' >> '/Applications/OpenXTalk Lite.app/Contents/Tools/.buildnumber'
sudo chmod 766 '/Applications/OpenXTalk Lite.app/Contents/Tools/.buildnumber'
mv: rename /private/var/folders/1n/x98w3n9n31dfynx_rtvjb7vr0000gn/T/TemporaryItems/xtalk_updates/updatecache/202311241843/DevGuides.livecodescript to /Applications/OpenXTalk Lite.app/Contents/Tools/Extensions/community.ferruslogic.plugin.devguides/DevGuides.livecodescript: Operation not permitted

When I got the operation not permitted error, I pasted the script text directly into terminal and tried to run it that way:

Code: Select all

 kdjanz@Mac-Studio ~ % sudo mv -f '/private/var/folders/1n/x98w3n9n31dfynx_rtvjb7vr0000gn/T/TemporaryItems/xtalk_updates/updatecache/202311241843/DevGuides.livecodescript' '/Applications/OpenXTalk Lite.app/Contents/Tools/Extensions/community.ferruslogic.plugin.devguides/DevGuides.livecodescript'
mv: rename /private/var/folders/1n/x98w3n9n31dfynx_rtvjb7vr0000gn/T/TemporaryItems/xtalk_updates/updatecache/202311241843/DevGuides.livecodescript to /Applications/OpenXTalk Lite.app/Contents/Tools/Extensions/community.ferruslogic.plugin.devguides/DevGuides.livecodescript: Operation not permitted
kdjanz@Mac-Studio ~ % /Users/kdjanz/Desktop/xTalk_IDE_update.sh
zsh: permission denied: /Users/kdjanz/Desktop/xTalk_IDE_update.sh

So then I thought it might be a Bash vs zsh thing, so I went to Bash:

Code: Select all

The default interactive shell is now zsh.
To update your account to use zsh, please run `chsh -s /bin/zsh`.
For more details, please visit https://support.apple.com/kb/HT208050.
bash-3.2$ /Users/kdjanz/Desktop/xTalk_IDE_update.sh
bash: /Users/kdjanz/Desktop/xTalk_IDE_update.sh: Permission denied
bash-3.2$ sudo /Users/kdjanz/Desktop/xTalk_IDE_update.sh
sudo: /Users/kdjanz/Desktop/xTalk_IDE_update.sh: command not found
bash-3.2$

So then I gave up...

When I went back to the 0.95 Pref for Automatic Updates and did the Check Now again, it worked fine without telling me about the script etc. so perhaps the script did do it's thing even with the error messages.

Kudos and thanks for your work on this, from a usually silent lurker.

[tperry2x]

Thank you Kdjanz for testing this out.
I'm not ignoring anyone, I've just been floored by Covid at the moment, so will not be very active for the next couple of days. I'll have a look at this if I feel up to it and do some testing. Ideally, I want to cut out the bit that asks you to run a terminal script, so I'll make this a bit more automatic and user-friendly.

This is how it's supposed to work:
https://www.tsites.co.uk/sites/openxtal ... update.mp4

edit: just tested on the mac, and seems to work there too:
https://www.tsites.co.uk/sites/openxtal ... update.mp4

Like you rightly said, I think it must be due to Apple switching from the bash to zsh shell. I totally forgot about that.

However, I want to tweak this further, and I'll test some more on Windows too (when I'm feeling up to it).

[richmond62]

Bad luck with the COVID: work on 1 to 2 weeks 'away'. I had that about a year and a half ago during lockdown: think of 'flu time 3.

Wishing you a speedy recovery.

[tperry2x]

Hi again Kdjanz.
Just to follow up on what you said about the monitors, I'll have to test as I don't tend to use a multi-monitor setup here.

I have a high res monitor 3200x1800 and a low res 1920x1080. The high res is on the left and has the menu bar on it....0.95 started on the [left] however and I cannot figure out how to move the toolbar over to the [right] screen for working. Most modern Mac programs have a Window menu on the menubar and it has commands to move the program to the other monitor.

When you say moving the Toolbar, I'm just checking you mean the revMenubar stack (with this on it):

revMenuBar.png (14.81 KiB) Viewed 583 times

If you go into preferences, and turn on the option to allow it to be dragged, can you then quit & relaunch and drag it to your second screen?

When I create a new stack, the window opens with the title bar off in space off the top of either monitor and I have to faf around with the Message box to bring it down to usable coordinates.

I don't know if the IDE considers whatever screen the revMenubar is on to be it's main screen, but I'll have to experiment.
Could you upload screenshots of what you are seeing as it's certainly an interesting one.

You could also try 'nudging' the revMenubar stack around too with a new preference, to get it onto "screen 2"
https://www.openxtalk.org/forum/viewtop ... 4774#p4774

[tperry2x]

Bad luck with the COVID...Wishing you a speedy recovery.

Thanks Richmond. I'm feeling pretty but as long as I don't go rushing around the house, I'm not too bad with it. Still feels like I've been running for 10 minutes, when all I did was go up the stairs.

[richmond62]

I see you are still doing 'stuff', bravo, much better than lying around feeling sorry for yourself.

[tperry2x]

I see you are still doing 'stuff', bravo, much better than lying around feeling sorry for yourself.

Yes, otherwise I've found I only feel worse.
Here's a strange question, but what's the best way for a standalone to attain administrator privileges on Windows / sudo privileges on MacOS and Linux?
I ask, as I'd like to remove the terminal part of my updater, and having it apply the updates seamlessly without having the user jump through that terminal copy-and-paste malarkey, like in the videos above https://www.openxtalk.org/forum/viewtop ... 4917#p4917, would be brilliant if I could avoid that.

[richmond62]

Here's a strange question, but what's the best way for a standalone to attain administrator privileges on Windows / sudo privileges on MacOS and Linux?

Here's a 'funny' situation: my 64-bit Linux install went 'sour' on me last night: so, today I booted the thing up from a USB flash drive, and, to recover all my files I had to fool around with the Terminal (this on an XFCE setup) and had to open various terminal instances and type sudo thunar and then drag the icon of the folder on the relevant disk (either the one on the laptop or one on the backup external hard disk) into the Terminal.

The odd thing was that, having booted up from an external boot USB, I was NOT asked for any admin password at all: this whole thing made me a bit queasy as it means that "Mikhail the Mountain Man from Montana" can merrily obtain ALL my files without so much as a by-your-leave.

https://en.wikipedia.org/wiki/Montana,_Bulgaria

I would assume (and hope) that anyone who is going to install an xTalk standalone on their rig is not going to be so goofy as to not have either set an admin password, or had one automatically set by the system on installation.

Certainly, when I installed Debian, unlike Xubuntu, I was surprised (foolishly) to find that for me to start installing stuff I had to fiddle around quite a bit to get elevated privileges (which are a given with Xubuntu).

As soon as you start writing about a standalone attaining admin privileges you ought to run to the bathroom and wash your computational mouth out with soap, as that is the dark and dangerous path to viruses and so forth. After all, if a standalone can get admin privileges WITHOUT the owner of the computer granting them, it can blank discs, phone 'home', plant groovy porn pictures all over the place, make the machine play 'Hellzapoppin', you name it.

[tperry2x]

As soon as you start writing about a standalone attaining admin privileges you ought to run to the bathroom and wash your computational mouth out with soap, as that is the dark and dangerous path to viruses and so forth. After all, if a standalone can get admin privileges WITHOUT the owner of the computer granting them...

I'm not about to run anywhere at the moment
I meant, the standard permissions dialog like so:

admin-permissions.png (31.86 KiB) Viewed 552 times

The user would be asked for permissions, and like system preferences does in this screenshot, the purposes for asking are shown.

In fact, same in Linux and Windows:

privs.png (35.68 KiB) Viewed 550 times

winpriv.png (22.31 KiB) Viewed 549 times

This is all very normal stuff for anything that has to ensure it's got write permissions. (linux needs it for the /opt location), MacOS would need it if the OpenXTalk Lite Application is in /Applications, and Windows would need it to overwrite files in C:\Program Files\

To come back to your other point, most live CD / live ISOs have the root user enabled (or casually mention the password within). This is because for fully privileged access to all files (such as an iso who's job it is to clone your computer, you'd need this).

There is nothing to stop anyone coming along with a boot media if they have physical access to your computer, and booting off it. This is why you'd either prevent this in the bios (sorry mac users, you are stuck here), or you'd prevent real access to the machine.

[richmond62]

I'm not about to run anywhere at the moment

Not with COVID, you aren't.

[richmond62]

I meant, the standard permissions dialog like so:

Well, why didn't you say?

Personally the best way, if any, to find out is to pop over to 'the other side' and ask Jacque or Klaus (which I shall do in about 5 minutes).

[richmond62]

Well, that is not really what we wanted is it:
-

Screenshot 2023-12-02 at 18.20.05.png (291.96 KiB) Viewed 540 times

[tperry2x]

No, not what we require. They have got the wrong end of the stick unfortunately.
We need elevated permissions for writing to other parts of the filesystem.

[richmond62]

Quite: but I have "stirred up the hornet's nest": https://forums.livecode.com/viewtopic.php?f=7&t=38764
-

Screenshot 2023-12-02 at 18.42.20.png (178.04 KiB) Viewed 533 times

[tperry2x]

Granted, I suppose this is a slightly odd request - and not something that most users would really need to think about, but I'm surprised there's not some kind of built in function for asking for elevated permissions.

I think as long as it comes with a dialog, explaining the reasons for needing them - and exactly what it's about to do, then I don't think the end-user should worry.

After all, they could always click a cancel or deny button if they didn't feel comfortable with it. Not sure how best to do this, but I'll have a poke around the interweb now.

[tperry2x]

Turns out, it'd be fairly easy in linux:

linux-elevate.png (5.75 KiB) Viewed 527 times

This will ask for the admin password, and I could couple that with an exo-open command so that it even opens the user's default terminal for them, and points it toward the script. (although that might come across as slightly unnerving)