Comments on 1.0

[OpenXTalkPaul]

I'm very confused by this.
Did you download the 1.0f in dropbox for the mac?

if you look at the script of the home stack, and the "IDEtoDarkMac" handler, you should see:
Screenshot_2024-02-01_17-04-20.png

This then calls your setAppToDarkMode handler, in your stack which uses the API method - so it should be doing it the supported way. I certainly get the dark window titles and everything on Catalina in this way.

I had the menu problem in an earlier MacOS build of OXT Lite (v0.98) and thought I'd fixed it in 0.99 upwards.
What do you think is making the menus so flaky on MacOS?

Later on, I'll go back on the mac and get some screenshots of it in Catalina. Can't now because kids

'because of kids', I completely understand that.

I not sure if I have 1.0f or not (downloaded last night).

I do have those lines in the home stack. What method is it using to get the system version?
If you use the macOSversion() from OXT Mac Native library, that's the method that Apple installer packages have used to get the installed system version and it should always be accurate (not subject to that Apple version number bug).

The dictionary browser thing isn't working well when doing multiple successive searches, and I can't see where to set it back to browser widget version Dictionary. Can't remember if you used a key combo thing to do switching?
I just kept this as webpage version with this an internal / external toggle switch in my revPrefs so I can use that it regardless of what platform the IDE is on, figured I would include any Syntax Browser stack as another option in the menus, keeping both let user be free to decide, or use both at the same time. I could be nice to have a syntax search in the reMenuBar.

[OpenXTalkPaul]

That's handy to know.
Is that documented anywhere, as I wasn't aware of that.

Wow! That text formatting is seriously mangled. That's not what I see, but that's screenshots on Sonoma again I assume?
fonts.png

Not documented that I'm aware of, the docs for Extension Building need lots of work.
Of course most users probably won't be extending the IDE or Extension Builder language.

I'm testing on Big Sur at the moment, non-retina display so I'm 72px per inch, IDE not 144 or 288 'hi-dpi' mode (which does make some difference, at least in the splash screen).

I have a dictionary browser stack (based on that same stack from MaxV) that is set up read the sqlite file in the same directory, so then I put it into the IDE in the directory where that is stored, but this method doesn't pick up the dynamically loaded extensions syntax so I want to update it to read from the Dictionary cache folder (adding a 'rebuild dictionary' button to the revPrefsUI stack could be helpful too).

[tperry2x]

I not sure if I have 1.0f or not (downloaded last night).

I do have those lines in the home stack. What method is it using to get the system version?
If you use the macOSversion() from OXT Mac Native library, that's the method that Apple installer packages have used to get the installed system version and it should always be accurate (not subject to that Apple version number bug).

It's using:

Code: Select all

if the platform contains "mac" then put "sw_vers -productVersion" into tShellCmd
put shell(tShellCmd) into tSystemVersionNumber

So, should not be subject to the Apple version numbering bug.

The dictionary browser thing isn't working well when doing multiple successive searches, and I can't see where to set it back to browser widget version Dictionary. Can't remember if you used a key combo thing to do switching?

I had this as an option for a long time, through v0.93 to 0.98 I think. I got cheesed off with the dictionary and got rid of it. All the hooks are still there if you drop in an original revmenubar stack.

I just kept this as webpage version with this an internal / external toggle switch in my revPrefs so I can use that it regardless of what platform the IDE is on, figured I would include any Syntax Browser stack as another option in the menus, keeping both let user be free to decide, or use both at the same time. I could be nice to have a syntax search in the reMenuBar.

That's probably a good idea. If you make a new revmenbar stack, I could just drop yours in to correct the menubar, the dictionary options and also the inline syntax search in the menubar - as it's all in the one stack.

[OpenXTalkPaul]

Well using setAppToDarkMode works, but it's not being triggered for some reason.
What I did was not even check the macOS version and just wrapped that call in a try / end try structure so it shouldn't complain if darkMode API isn't available (pre-10.14 Mohave), and maybe it could still do a pseudo-darkmode (eventually on all platforms, Emscripten too, with the OXT Window Manager, coming soon...er or later )

[tperry2x]

Well using setAppToDarkMode works, but it's not being triggered for some reason.
... maybe it could still do a pseudo-darkmode (eventually on all platforms, Emscripten too, with the OXT Window Manager, coming soon...er or later )

That's very odd why it's not being called.
I did test this, and I knew I'd uploaded screenshots somewhere.
Found the post: https://www.openxtalk.org/forum/viewtop ... 5919#p5919

The pseudo dark mode does already work in 10.9 (which obviously didn't support dark mode at all)

dark-mode-old-mac.png (510.49 KiB) Viewed 509 times

[tperry2x]

I don't know. It's soul destroying.
Just when you think you've got a handle on the problem, and got it sorted, MacOS seems to rear it's ugly head again and present another problem.

I feel like 'why did I bother' quite frankly? - That's not a dig at you or your comments. I mean, you are only observing what's there. This goes for Richmond too - if there was nothing wrong, then there would be nothing to pick holes in. I shouldn't take it personally, but it's just depressing to have done all that work and find that it's no better (or worse) under MacOS than it was before.

I feel like throwing the mac build away and letting someone else do it. Either that, or I put v0.99 back in the dropbox folder, and someone else can pick up the reigns from there. What do you think? Is what I've done junk, because at the moment it kind of feels like it.

[tperry2x]

Anyway I self signed it, adhoc sig using a drag drop utility called CodeSigner.app (useful) ...

Do you know where I download this?

Anyway, dark mode - 1.0f - opened the dmg, dragged out the zip file and uncompressed.
Why is it a zip file? because if I make a dmg from a folder, MacOS makes it an APFS file system by default which is no good under MacOS 10.9 (and probably others).
I could make a dmg in HFS+ format, then convert it and compress it via disk utility I guess. Lots of extra hoops to jump through on CrapOS.

a.png (953.36 KiB) Viewed 500 times

b.png (914.29 KiB) Viewed 500 times

c.png (910.31 KiB) Viewed 500 times

And dark mode gets triggered properly via the API. I'll do it again and check the message watcher...

edit: you can see when I choose 'Dark Mode' the message watcher shows it's running the command, and everything is switching over as it should:

d.png (815.68 KiB) Viewed 500 times

So I don't know what to tell you.
I'm doing this via the view menu > Appearance

e.png (154.84 KiB) Viewed 500 times

[OpenXTalkPaul]

Tom, I don't think what you're doing is a waste of time at all. You've been hands down the most significant contributor. I sincerely appreciate your efforts. I want to help with OXT Lite more, at least by testing and reporting and throwing my 2 cents in. I haven't had the time to do much more than that lately, and I have another busy weekend ahead so probably won't be getting much xTalk stuff going over the weekend.

I do think you should consider picking up more files from my build, particularly the Extension Manager related files because I fixed a bunch of things in there. For example if you click on the right-side menu for OXT MacNative lib item in the Libraries tab of Extension Manager there should be a Demo stack, if you select that it should open the stack but it didn't before I fixed it (and doesn't in OXT-Lite either), there's fixes in the Extension Builder stack too. Also the tabs in Extension Manager 'Snippets' and 'Sample Stacks' are empty (I removed those tabs completely since they were always empty in the before times), Extension 'Store' tab in OXT Lite sill points to a page on LC's server. OXT Heavy has an Extension 'Repo in there, which is actually a bunch of files in GitHub repo. That can be a little bit slow loading the first time loading because it downloads a copy of the 27mb Emscripten Engine from that GitHub Repo (It would be better if it could use the copy of Emscripten engine that is already in the standalones folder). The 'Store' and 'Sample Stacks' probably a good ones to change over into a regular stack instead of a web page. The 'Store' repo's 'database' is simply tab delimited data in a plain text file, that is read by the webstack that's running in that browser widget. The point is I did a bunch of work on this aspect of the IDE.

The more import thing is that crash when I click to open the 'Windows' or 'Help' menu, I don't know what is going on there.

Maybe the dmg I downloaded isn't 1.0f but some other 1.0 build? I'll have to check when I get home.
I'm not sure what it could be, unless it has something to do with sharing a prefs file with OXT Heavy or something like that?
But OXT Heavy (DPE) is still working fine on the same machine.

Apple's Disk Utility kind of sucks donke... er... now days is not particularly useful like it once was, IMO.
Newer version of APFS files system are not even compatible with older APFS drivers in earlier versions of macOS that did support APFS. What I mean is MacOS 10.14 Mohave can't recognize the partitions on drive formatted with Sonoma, HFS+ formatted still works fine on both, and I have a feeling Apple will likely have to keep support for HFS+ for a long time to come, so that's the way to go.

Here's a GUI tool for building fancy dmg files, the sort of DMG that present a splash screen (usually licensing info) when they're mounted, and can code sign them afterwards. This should be able to make 10.14 and lower compatible HFS+ disk images too.
https://www.araelium.com/dmgcanvas
All of what it does can also be done with command line tools that either come with macOS or come with Xcode Command Line Tools (someone could make a stack that is. UI for building distribution .dmgs)

I can't remember/or refind where I got that Code Signing utility app, but I know that it is using the command line tools underneath the UI to adhoc sign. I have collected a few tools for dealing with extended attributes (GateKeeper) and code signing and stripping signatures off and that sort of stuff. When Apple started really pushing it a few years back, then and I started researching. I did find a lot of useful tools and information articles about this sort of code signing and making certs and stuff from this site: https://eclecticlight.co/mac-troubleshooting-summary.
Also this old tech note from Apple has a lot of details too: https://developer.apple.com/library/arc ... index.html

[overclockedmind]

I need to ask a (hopefully non-offensive) question.

Who did Instructions.rtfd and which macOS version was it created in?

Cuz it doesn't jive *at all* with what I've got in Monterey and it's giving me a headache.

Keychain Access, for me, looks completely different.

And, I believe what happened is that it popped the "about the key" dialog after forever, I thought I was still looking at the Instructions, and I might have hit Escape on the Actual Key Dialog. I've removed the cert from login, etc but, even though the cert is signed, with a key? Yeah I got no key.

Looks like this:

kca-certs.png (61.15 KiB) Viewed 484 times

kca-keys.png (39.51 KiB) Viewed 484 times

I might need a one-liner shell script to add the key specifically, OR the signed (and trusted) cert is as it should be.

[tperry2x]

Apple's Disk Utility kind of sucks donke... er... now days is not particularly useful like it once was, IMO.

I couldn't agree more. Like the rest of the OS increasingly, they are removing features / options that people depended upon for backwards compatibility, while making what should be straightforward tasks increasingly complex.

Here's a GUI tool for building fancy dmg files, the sort of DMG that present a splash screen (usually licensing info) when they're mounted, and can code sign them afterwards. This should be able to make 10.14 and lower compatible HFS+ disk images too.
https://www.araelium.com/dmgcanvas
All of what it does can also be done with command line tools that either come with macOS or come with Xcode Command Line Tools (someone could make a stack that is. UI for building distribution .dmgs)

So we are now relying on a paid-for tool to do our codesigning because Apple have made it increasingly difficult?
I know it's not much money to buy dmgcanvas:

Version 4 — $25 — Requires macOS 11 or Later

- and there's the problem: I can't run MacOS 11 on anything here as my Apple stuff isn't new enough, and I'm not about to go buy a replacement mac any time soon.

Also, I note at: https://www.araelium.com/support/dmgcanvas

In DMG Canvas's preferences, enter the Apple ID of your developer account.

That's a non-starter straight away, as the codesigning is an ad-hoc certificate - not signed with an Apple developer account. (As I'm not paying for that subscription).

...in the disk image settings in the sidebar, turn on Notarize with Apple, and select your Apple ID. For the "primary bundle id" enter any value which describes the primary content in the disk image being notarized. This is used for reference by the underlying notarization tools. During the build process, DMG Canvas will submit the dmg to Apple for notarization and wait until it finishes. Once finished, the dmg and any applications inside of it are then notarized, and the resulting dmg is then stapled with the notarization ticket.

Again, I won't be able to "Notarize with Apple" as there is no developer account to "Notarize" with. (what a load of BS this is).

Note that to notarize a disk image, the dmg must also be code signed.

Oh, added bonus. Great.

If you can summise all the codesigning commands you used with OXT-heavy, in a post - that would be great. I would even have an applescript in the DVD which just runs these shell scripts (probably at login for every user on multi-user setups).

I can't remember/or refind where I got that Code Signing utility app, but I know that it is using the command line tools underneath the UI to adhoc sign. I have collected a few tools for dealing with extended attributes (GateKeeper) and code signing and stripping signatures off and that sort of stuff. When Apple started really pushing it a few years back, then and I started researching. I did find a lot of useful tools and information articles about this sort of code signing and making certs and stuff from this site: https://eclecticlight.co/mac-troubleshooting-summary.
Also this old tech note from Apple has a lot of details too: https://developer.apple.com/library/arc ... index.html

That's certainly a lot to wade through. What myself (and overclockedmind) mention is just a one-liner (or even a multi-liner with &&'s) that we can run to make everything 'just work' the way it should. With no Apple BS.

That would be wonderful.


Failing all that. I'm just going to say "run it within wine", and be done with it.

[tperry2x]

I need to ask a (hopefully non-offensive) question.
Who did Instructions.rtfd and which macOS version was it created in?
Cuz it doesn't jive *at all* with what I've got in Monterey and it's giving me a headache.
Keychain Access, for me, looks completely different.

No offence taken. That was me, in MacOS Catalina. - Sorry, I don't have anything newer as regards MacOS.

I might need a one-liner shell script to add the key specifically, OR the signed (and trusted) cert is as it should be.

You and me both

You'd think I was on a personal mission these days to move each and every mac user off MacOS. I never used to hate the platform. In fact, there was a time where it was Mac or nothing with me. Oh how times have changed. I'd now advocate anything except MacOS if you want to get work done as a developer. That saddens me, but there's just too much red tape and Apple-Flavoured-BS to wade through.

If anyone wants to take up the mantle of developing for MacOS, be my guest. As I mention before, I might get as far as compiling an updated engine with updated libraries and such - without the registration requirement, but this is where my involvement with anything MacOS will likely end. I'll then concentrate on Linux and Windows as I see these platforms as being a whole lot more open and reliable. (Can't believe I'm typing that, but it's true from a developer standpoint).

[richmond62]

Apple and their devices are increasingly becoming a bit like my leopard-skin posing briefs: all very fine for strutting one's funky stuff as a fashionista, but more and more awkward to use for what I have always thought computers were meant to be for.

AND, Yes, the only sorts of people I would recommend a Macintosh to are pea-brained fashion types.

I really would encourage absolutely everyone to dump both Mac and Windows (unless, like me, they have an older Mac they are happy with and can keep running) in favour of a Linux distro: and by that I mean spend 2 weeks faffing around with 5-6 Linux distros until you find the one that makes you feel comfortable AND has the sort of backwards compatibility Apple are deliberately removing.

HOWEVER, there is one thing that WE have to consider: developers using OXT might require the ability to make standalones that run on Macs. I have, to my shame, not tried hiving off a standalone for Mac from Linux for quite a long time: but at that time at least, the "Mac" standalone generated by LC Linux just went 'clunk' on a Mac and didn't work.

[tperry2x]

Absolutely. I couldn't agree more.
I can confirm that the linux Linux version of OXT Lite, does indeed generate working Mac applications.
Even running OXT through Wine generates working native intel Mac Apps.

So that's great news. The only thing is you get the C:\ prompt when opening / saving (which will stand out like a sore thumb to mac users), but I think that's a small price to pay for it working.

I may even create a wineskin wrapper for MacOS to put OXT Lite in. So it looks like a double-clickable standard app. That has the benefit that it's already codesigned with the wineskin cert (developer 'doh123'), but at least it'll run without having to pay for a certificate and sidesteps all that Apple malarkey.

Kdjanz very helpfully did some testing in Whisky on an Arm mac, and reports that it runs fine on there too. In theory, even that could make native MacOS (intel) apps. (In theory).

[richmond62]

I am either stupid, or lucky, or, most probably both.

With the SINGLE exception of OXT Lite 0.92 I have never had a MacOS app that a right click won't get to run.

Users tell me that's all that is needed for my Devawriter app.

I have never notarised, stapled, paper-clipped, glued, or hammered any MacOS I have hived off from RR 1 thru LC 963: so what is all the fuss about?

[tperry2x]

With the SINGLE exception of OXT Lite 0.92 I have never had a MacOS app that a right click won't get to run.

Um, I don't understand that above statement when:
https://www.openxtalk.org/forum/viewtop ... 4156#p4156
https://www.openxtalk.org/forum/viewtop ... 4320#p4320
https://www.openxtalk.org/forum/viewtop ... 4764#p4764
https://www.openxtalk.org/forum/viewtop ... 4778#p4778

I have never notarised, stapled, paper-clipped, glued, or hammered any MacOS I have hived off from RR 1 thru LC 963: so what is all the fuss about?

You have had to, and have had problems with - as mentioned above.

[micmac]

Mayby version 1.0f refer to finger, because the pointing hand is back again.


Thank you for the great work you do Tom Perry

Mic

[tperry2x]

Mayby version 1.0f refer to finger, because the pointing hand is back again.

Okay, this got me thinking how long the pointing hand had been there.
Turns out it's always been there - it's in LCC 9.6.3 (and 9.7 community - yes, that's what available in Livecode's github).

hand-in-963.png (217.37 KiB) Viewed 415 times

Thank you for the great work you do Tom Perry

Thank you.

[richmond62]

You have had to, and have had problems with - as mentioned above

OK: but ONLY with OXT: never with anything else.

[overclockedmind]

At this point, I keep running into the brick wall, even with Gatekeeper off... I don't want to bring it up, but I cannot test fairly, as I do not know if it's Apple's wall that I am running into, or actual problems with the program itself.

Because I can get 1.0f to pull the same Crash or Continue dialog the second I touch the Help menu. Not kidding. The code:

Code: Select all

Exception Name: NSInternalInconsistencyException
Description: Invalid parameter not satisfying: index >= 0
User Info: {
    NSAssertFile = "NSMenu.m";
    NSAssertLine = 1024;
}

0   CoreFoundation                      0x00007ff81b0876e3 __exceptionPreprocess + 242
1   libobjc.A.dylib                     0x00007ff81ade78bb objc_exception_throw + 48
2   Foundation                          0x00007ff81bf34cd3 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 267
3   AppKit                              0x00007ff81da39424 -[NSMenu itemAtIndex:] + 151
4   LiveCode-Community                  0x0000000108d52e61 MCJSObjectGetID + 139745
5   LiveCode-Community                  0x0000000108d52f8b MCJSObjectGetID + 140043
6   AppKit                              0x00007ff81dcd9f40 -[NSMenu _populateFromDelegateWithEventRef:] + 290
7   AppKit                              0x00007ff81dc008d1 -[NSMenu _populateWithEventRef:] + 84
8   AppKit                              0x00007ff81dd263ef -[NSCarbonMenuImpl _carbonPopulateEvent:handlerCallRef:] + 365
9   AppKit                              0x00007ff81dd261e2 NSSLMMenuEventHandler + 1074
10  HIToolbox                           0x00007ff823c9634d _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1365
11  HIToolbox                           0x00007ff823c9579c _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 333
12  HIToolbox                           0x00007ff823c9563d SendEventToEventTargetWithOptions + 45
13  HIToolbox                           0x00007ff823ce5546 _Z16SendMenuPopulateP8MenuDataP20OpaqueEventTargetRefjdjP14OpaqueEventRefhPh + 301
14  HIToolbox                           0x00007ff823d170fa _ZL15SendMenuOpeningP14MenuSelectDataP8MenuDatadjjP14__CFDictionaryhPh + 332
15  HIToolbox                           0x00007ff823e3d1b1 _ZL11DrawTheMenuP14MenuSelectDataP8MenuDataPP9__CFArrayhPh + 305
16  HIToolbox                           0x00007ff823d2de55 _ZL11MenuChangedP14MenuSelectDatahh + 248
17  HIToolbox                           0x00007ff823e402b8 _ZL15TrackMenuCommonR14MenuSelectDataPhP13SelectionDataP10MenuResultS5_ + 1094
18  HIToolbox                           0x00007ff823d2db64 _ZL14MenuSelectCoreP8MenuData5PointdjPP13OpaqueMenuRefPt + 397
19  HIToolbox                           0x00007ff823d2d93e _HandleMenuSelection2 + 456
20  AppKit                              0x00007ff81dbe76d9 _NSHandleCarbonMenuEvent + 215
21  AppKit                              0x00007ff81dbe7546 _DPSEventHandledByCarbon + 54
22  AppKit                              0x00007ff81da47de0 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3368
23  LiveCode-Community                  0x0000000108d4dfa3 MCJSObjectGetID + 119587
24  LiveCode-Community                  0x0000000108d3fa18 MCJSObjectGetID + 60824
25  LiveCode-Community                  0x0000000108d3aca2 MCJSObjectGetID + 40994
26  LiveCode-Community                  0x0000000108d3b36e MCJSObjectGetID + 42734
27  LiveCode-Community                  0x0000000108d4d2c5 MCJSObjectGetID + 116293
28  Foundation                          0x00007ff81be8aae2 __NSFireDelayedPerform + 440
29  CoreFoundation                      0x00007ff81b024e99 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
30  CoreFoundation                      0x00007ff81b024988 __CFRunLoopDoTimer + 923
31  CoreFoundation                      0x00007ff81b0244f8 __CFRunLoopDoTimers + 307
32  CoreFoundation                      0x00007ff81b00ac06 __CFRunLoopRun + 2010
33  CoreFoundation                      0x00007ff81b009d6c CFRunLoopRunSpecific + 562
34  HIToolbox                           0x00007ff823cbc5e6 RunCurrentEventLoopInMode + 292
35  HIToolbox                           0x00007ff823cbc213 ReceiveNextEventCommon + 283
36  HIToolbox                           0x00007ff823cbc0e5 _BlockUntilNextEventMatchingListInModeWithFilter + 70
37  AppKit                              0x00007ff81da48f6d _DPSNextEvent + 927
38  AppKit                              0x00007ff81da4762a -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1394
39  AppKit                              0x00007ff81da39cd9 -[NSApplication run] + 586
40  LiveCode-Community                  0x0000000108d502eb MCJSObjectGetID + 128619
41  dyld                                0x000000010d22952e start + 462

[tperry2x]

Probably a bit of both. The way the menu is coded, and probably Mac OS itself. Which version of MacOS is that on please?

I want to finish compiling the last source uploaded by LC, to see if the menu is any more responsive / stable, and I want to do a fresh compile without any hacks.

However, I'm missing files:
https://www.openxtalk.org/forum/viewtop ... 6237#p6237