Comments on OXT Lite 1.05

[richmond62]

Being daft I deleted 1.04 before I installed 1.05: 1.04 WORKS with MacOS Snowman, so I would be grateful if you could let me have a link to re-download 1.04.

[tperry2x]

Being daft I deleted 1.04 before I installed 1.05: 1.04 WORKS with MacOS Snowman, so I would be grateful if you could let me have a link to re-download 1.04.

Yes, I've not deleted it. It was in my 'to be deleted area of mega'
(link to original v1.04 of OXT Lite).

If that indeed works on Sonoma, I'll see if it can be patched via the auto updater to make it into 1.05 - but that'll require a bit of tinkering here. You'll also need to replace the updater stack (attached)

[richmond62]

Thanks.

We shall see.

OK: installed, replaced the updates stack, ran the updates: now the 'About OpenXTalk' is greyed out.
-

SShot 2024-05-27 at 15.44.41.png (25.33 KiB) Viewed 591 times

[tperry2x]

That makes no sense why it'd be greyed out, but that's only 1 update of many:

Screenshot 2024-05-27 at 13.54.14.png (16.28 KiB) Viewed 580 times

Before I disappear down a rabbit hole of trying to troubleshoot a 1.04 'hybrid' remotely from afar, can you try importing this certificate into your keychain as attached:

Screenshot 2024-05-27 at 13.46.10.png (162.56 KiB) Viewed 588 times

Then log out and log in again.
I'd want to get 1.05 working, especially since it works here with no hiccups.

As I say, thought I had a handle on the codesigning because I can verify 1.05 is indeed codesigned with this certificate:

Screenshot 2024-05-27 at 13.59.44.png (100.16 KiB) Viewed 573 times

I'll get the chance to try this on a completely vanilla (freshly-installed unmodified MacOS) tomorrow, and will see what it does.


Tested, today (Tuesday 28th of May, 2024)
Edit: Tested today (fresh install of Monterey 12.7 - as that's as far as the mac I had available would update to).
Also tested in Windows 11 for good measure.
(Screenshots in the normal place)

No messing about with certificates needed. Just opened, no stress, no fuss. (Like it does on other OSs).

[richmond62]

SShot 2024-05-27 at 16.59.08.png (68.52 KiB) Viewed 560 times

-
Um.

AND then 1.05 launched . . . I hope you know what went on.
-

bonkers.jpg (384.35 KiB) Viewed 559 times

[tperry2x]

...then 1.05 launched . . . I hope you know what went on.

Not really, but I have a guess.
I think for whatever reason, MacOS on that machine isn't reading keychains properly, or at least not refreshing them when it should.
Tinkering around with importing keychains (even though it looks to have failed) seems to possibly have been enough to kick the keychain update process into action. It would have then realised that OXT Lite is self-signed, rather than unsigned, and allowed it to open (albeit normally with a warning about it being from an 'unsigned developer'). That's my take on it.
It is bonkers. The whole codesigning thing is bonkers. It would have been better for Apple to provide an off-switch to the entire codesigning checking requirement, but they didn't - so what we have is what we have.

Ultimately, I'm glad it's working for you and I don't have to create some franken-oxt version from 1.04 bits spliced in.
(I do keep copies of all my previous releases btw), just in case for whatever obscure reason might transpire.

previous.png (1.14 KiB) Viewed 552 times

(This is only stored on my local network, not on an outward-facing external one).

[richmond62]

There's a case of 'Pinky and Perky' round these parts (err: MacOS 14.5 'Snore Wars'):
-

P&P.jpg (9.69 KiB) Viewed 449 times

-
OK, OK, I know, before your time. We didn't have a telly (Mother was a snob), but her Mum (Granny) did, and when I went down to Granny (about once a month) I was able to watch all those subsequently cringeworthy things on her black and white, 13 inch telly (sheer bliss!).

Anyway; to cut to the chase: dragging OXT Lite 1.05 with its orangey icon to the Mac dock results in a pinky-purpley icon in the docK:
-

SShot 2024-05-30 at 11.53.42.png (60.11 KiB) Viewed 449 times

-
It doesn't matter that much unless you are some aesthetic freekoid.

[tperry2x]

This is a MacOS issue with apps of the same name and the info.plist approach (as mentioned previously about having multiple versions installed). (MacOS be easily confoosed)
Try renaming Oxt lite to 105 at the end, like you've done with the 104 in that screenshot.
You may have to restart, drag the old one out of the dock, and perhaps wait for the launchservices database to update (or update it yourself).

As mentioned here:

Code: Select all

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain u -domain s -domain l -v

Expect a period of unresponsiveness as each newly opened Finder window will need to rebuild its icons.
Back up your Mac prior to making any changes to its file system: Use Time Machine to back up or restore your Mac - Apple Support.

Or use a tool like Onyx:
Maintenance>Rebuilding>Launch Services

[OpenXTalkPaul]

I just drag drop OXT Lite on a little utility I have that ad-hoc code signs and clears the quarantine bit, then it opens up fine.

Did my DMG builds not have any of this issue on other people's computers? All I can tell you is I only stripped all code signing/extended attributes and then re-signs it using the 'deep' / recursive switch to get the code in IDE subdirectories too. Later I stripped code-signing off all together because it was causing problem with for the old merg sound Recorder external.

I haven't had a chance to really test OXT Lite 1.05 yet, but it started up fast. It didn't look too good in darkmode because button labels come out white-on-white. To get around this issue I changed default values of a coupe of objects so like button labels on new buttons are readable, and also manually edited the pre-existing IDE stacks. Of course these aren't what darkMode buttons should look like on new macOS, but that's really an engine level problem (as has been discussed).

[OpenXTalkPaul]

I'm a bit torn, in many ways I like the uncluttered-ness of OXT Lite having the property inspector only ever be single instance window rather than allowing for multiple transient instances, but on the flip size how can user inspect the properties of two different objects to compare their properties settings? EDIT: in most cases I think user can click back and forth between the objects manually to compare, but I imagine some edge cases where the objects user wants to check are cards or some sort of intangible it could be a problem?

I had never noticed this before just now, but double-clicking on card surface toggles a props inspector window between 'card' and 'stack'.

[richmond62]

I'm a bit torn

I suppose the 'perfect' solution would be to have a set-up like the script editor, where it initially appears as a paged single thing, but individual scripts can be 'sent off' into separate windows so they can be seen side by side.

[OpenXTalkPaul]

I'm a bit torn

I suppose the 'perfect' solution would be to have a set-up like the script editor, where it initially appears as a paged single thing, but individual scripts can be 'sent off' into separate windows so they can be seen side by side.

That's not a bad idea, it might be as simple as implementing a new menu choice to "inspect in new property inspector window" to continue to allow the option of a adding transient inspector windows... or there might be some additional 'back end' work involved I don't know.
Right now I'm still focusing on Tools palette redo fully working with no display glitches.

[tperry2x]

I'm a bit torn, in many ways I like the uncluttered-ness of OXT Lite having the property inspector only ever be single instance window rather than allowing for multiple transient instances

Yes, I very much prefer this uncluttered approach. The IDE can easily get confused and can spawn multiple inspectors anyway (!), but that's a behaviour I'm correcting by deleting the original inspector eventually.

...but on the flip size how can user inspect the properties of two different objects to compare their properties settings? EDIT: in most cases I think user can click back and forth between the objects manually to compare, but I imagine some edge cases where the objects user wants to check are cards or some sort of intangible it could be a problem?

I think that's exactly it. It's an edge case / niche case. I'm concentrating on making it work reliably in OXT lite first. (Without any glitches, focus stealing, windowmanager CPU race conditions, multiple instances or any weird sliding animations (list)).
I'm not saying that I won't have a mode eventually where you can compare two (or more) objects, and I'd also like to be able to orientate the inspector horizontally instead of vertically. I'll get the basics done first, then can always go back and add bits in.

I had never noticed this before just now, but double-clicking on card surface toggles a props inspector window between 'card' and 'stack'.

Yes, except on mine I've set this to be single clicks. As you single-click any object to inspect it with the inspector open. To keep the behaviour uniform - if the card is clicked, it displays the card inspector. If the card is clicked again and the card inspector is active, it toggles to the stack inspector. Simple.

(currently working on the arrays / 'custom properties' part of my new inspector) - demo

edit (monday evening):
Done that - now doing the colour swatches (and patterns to follow). Thought about having a colour selector embedded in the window, so you don't have to go hunting for popups.

untitled.gif (655.63 KiB) Viewed 205 times

[tperry2x]

Right now I'm still focusing on Tools palette redo fully working with no display glitches.

Which display glitches are those? Are these ones that exist in OXT Lite? - if not, I may have already fixed something and you are more than welcome to use anything from my tools palette. Just checking to see if I can save you any headaches

Happy to help out where (or if) I can.

[OpenXTalkPaul]

Right now I'm still focusing on Tools palette redo fully working with no display glitches.

Which display glitches are those? Are these ones that exist in OXT Lite? - if not, I may have already fixed something and you are more than welcome to use anything from my tools palette. Just checking to see if I can save you any headaches

Happy to help out where (or if) I can.

Thanks, I certainly am looking at revTools in OXT Lite, I'm looking to incorporate some of your fixes or additions.

The glitches I was referring to only applied to my rewrite, I had variations in the layout scripts for each section and user could see a lot of shifting around when going from tool-section to tool-section (cards). That's resolved, now I need to add back in the rest of the Tools 'controllers' (brushSelector, colors, etc.).

One thing I could use help understanding is the way you guys resolved the problem of the paint tools 'auto-created' bitmapped images not being saved in stacks. I copied in all the additional handlers like hCreateSuitableImage, tNewCmd etc. but it's unclear how they work together (since I'm re-writing completely, I can't just copy it in line-for-line). I was thinking maybe this would be better in one of the IDE libraries, where the check/fix could me inserted on IDE global level, so that any other stack using the paint tools would get the fix too? Of course any stack can subscribe to IDE messages like 'ideMouseDown' (the IDE then sees stack as an 'IDE stack' and it doesn't appear in the 'windows' menu thereafter).

Would this be a problem for standalones that use paint tools too? I ask this because then it may be best to have a fix in a library that could be (auto-)included with standalones? I wouldn't mind having such a library for any general fixes and any commonly used routines (what I mean by commonly-used is handlers for things like getting the 'leafName' from a filePath or URL for use in 'Save As..." handlers).

[tperry2x]

One thing I could use help understanding is the way you guys resolved the problem of the paint tools 'auto-created' bitmapped images not being saved in stacks.

Code: Select all

on ideToolChanged
   local tTool
   put the tool into tTool
   set the itemdelimiter to "\n"
   if tTool is among the items of kPolygonMenu then
      put "paint polygon shape tool" into tTool
      put hCreateSuitableImage (tTool) into tImgCmd
      send tDoImgCmd to me in 1 ticks
   end if
   

If you look at the hCreateSuitableImage, you'll see it's a handler that creates a suitable paint image.

Code: Select all

function hCreateSuitableImage tTool
   -- bug found (tperry, richmond62, & micmac 22-4-24)
   --put "the tool is: " & tTool -- debug (tperry 22-4-24)
   put the short name of the topStack into tTheCurrentStackName
   put the last word of the currentcard of stack tTheCurrentStackName into tCardID
   put the number of images of card id tCardID of stack tTheCurrentStackName into tImgCount
   put "suitable-paintimage" into tNewPaintName
   --
   if there is an image (tNewPaintName) of card id tCardID of stack tTheCurrentStackName then
      set the tNewImgCmd of stack "revTools" to ""
      return true
      exit hCreateSuitableImage
   else
      -- no suitable images on the card
      put "create image " & QUOTE & (tNewPaintName) & QUOTE & " in card id " & tCardID & " of stack " & QUOTE & tTheCurrentStackName & QUOTE into tSuitableImageSetup
      set the tNewImgCmd of stack "revTools" to tSuitableImageSetup
      return false
   end if
end hCreateSuitableImage

on tDoImgCmd -- handler to actually create the paint image we are missing (tperry 22-4-24)
   if tImgCmd is true then exit tDoImgCmd
   if the tNewImgCmd of stack "revTools" is "" then exit tDoImgCmd
   put the tNewImgCmd of stack "revTools" into tImgCmd
   do tImgCmd
   replace QUOTE with return in tImgCmd
   delete line 1 of tImgCmd
   put word 4 of line 2 of tImgCmd into line 2 of tImgCmd
   -- 
   put line 1 of tImgCmd into tImgName
   put line 2 of tImgCmd into tImgID
   put line 3 of tImgCmd into tImgStack
   --
   set the rect of image tImgName of card id tImgID of stack tImgStack to 0,0,the width of stack tImgStack, the height of stack tImgStack
   set the layer of image tImgName of card id tImgID of stack tImgStack to bottom -- just to make sure it doesn't obscure any buttons (tperry 23-4-24)
end tDoImgCmd

Something about the way the LCC versions created their initial paint image, meant that it was being missed out the save when written as a stack. The engine does this when it detects an invalid object. I don't know what made it invalid, but I did notice that you can manually create a new blank image and that is valid. So this script handler just does that instantly when a suitable paint image doesn't exist.

Would this be a problem for standalones that use paint tools too? I ask this because then it may be best to have a fix in a library that could be (auto-)included with standalones?

It would probably be best to have a library that fixes this, but I fixed it directly in the tools livecodescript stack as that's where the immediate issue was. I don't think it would be a problem if you were creating paint objects in a standalone (because changes aren't saved in standalones), so if you had a painting app for example, you'd need some way to export that data (either as a flattened bitmap copy, or some form of dynamically created markup).

[richmond62]

When I want to export something drawn with the paint tools I generally use EXPORT SNAPSHOT.

[OpenXTalkPaul]

One thing I could use help understanding is the way you guys resolved the problem of the paint tools 'auto-created' bitmapped images not being saved in stacks.

Code: Select all

on ideToolChanged
...
 

If you look at the hCreateSuitableImage, you'll see it's a handler that creates a suitable paint image.

Right, I did copy over ALL of the OXT Lite additional handlers and changed the lines with 'revTools' to 'OXT Tools'.
I'm trying to understand the root of this problem, I'm not even sure if my re-write would exhibit the same behavior, is it an 'engine' problem? Because when I click with a brush, pencil, etc. paint tool it does auto-create a new image, and if you 'put the last image' it will spit out PNG file data, and if you put the name of 'the last image' you'll get something like 'image id 1003'...so what specifically is NOT-suitable about this image that it doesn't get saved?
You can use 'long name' to find out if the image is on a stack that has already been saved to disk or is a new stack, so I'm thinking that there would be a check for that involved in the solution.
Reading through these handlers it appears this would create a new 'suitable-image' every time a paint tool is selected and there isn't already an image object on the currentCard?
I was thinking I would tap 'ideMouseDown' message to check if 'the mouseControl' is already an image or not, and then create an image if it's not.

Code: Select all

function hCreateSuitableImage tTool
...

on tDoImgCmd -- handler to actually create the paint image we are missing (tperry 22-4-24)
...
end tDoImgCmd

Would this be a problem for standalones that use paint tools too? I ask this because then it may be best to have a fix in a library that could be (auto-)included with standalones?

It would probably be best to have a library that fixes this, but I fixed it directly in the tools livecodescript stack as that's where the immediate issue was. I don't think it would be a problem if you were creating paint objects in a standalone (because changes aren't saved in standalones), so if you had a painting app for example, you'd need some way to export that data (either as a flattened bitmap copy, or some form of dynamically created markup).

Good point, but what if I'm making a 'standalone' that is a version of the IDE running in a webbrowser? OK, I know that's really an edge-case

[OpenXTalkPaul]

Reading through these handlers it appears this would create a new 'suitable-image' every time a paint tool is selected and there isn't already an image object on the currentCard?

I just checked this in OXT Lite and that is the result, I get a new image named 'suitable-image' on the currentCard just from clicking a paint tool in revTools, even if I don't actually paint anything. So that is the reason I'd like to move the fix so it's triggered by ideMouseDown or ideMouseMove message handler.

[tperry2x]

Yes, it creates a paintimage if you select the paint tools. It doesn't create new ones if one already exists (it exits if one is already on the target card).

Yes, I don't know what was 'unsuitable' about the LCC created one. I don't think it's an engine problem, as otherwise we'd probably not be able to create a new paint image at all.

My thinking it's some property that is not being applied, but I couldn't track down how the original is supposed to be creating the image. A lot of that I did a complete rewrite on anyway, so it made sense.